On the surface you see a series of Web pages, made up of images and text. Some of these images are things you can click on, performing some sort of function such as taking you to a shopping cart. Some of these images are just illustrations, such as a photograph of a product for sale or the logo of the site itself.
Beneath that surface is the skeleton of the site: the placement of buttons, controls, photos, and blocks of text. The skeleton is designed to optimize the arrangement of these elements for maximum effect and efficiency—so that you remember the logo and can find that shopping cart button when you need it.
The skeleton is a concrete expression of the more abstract structure of the site. The skeleton might define the placement of the interface elements on our checkout page; the structure would define how users got to that page and where they could go when they were finished there. The skeleton might define the arrangement of navigational elements allowing the users to browse categories of products; the structure would define what those categories were.
The structure defines the way in which the various features and functions of the site fit together. Just what those features and functions are constitutes the scope of the site. For example, some commerce sites offer a feature that enables users to save previously used shipping addresses so they can be used again. Whether that feature—or any feature—is included on a site is a question of scope.
The scope is fundamentally determined by the strategy of the site. This strategy incorporates not only what the people running the site want to get out of it but what the users want to get out of the site as well. In the case of our store example, some of the strategic objectives are pretty obvious: Users want to buy products, and we want to sell them. Other objectives-such as the role that advertising or content produced by our users plays in our business model, for example-might not be so easy to articulate.
Each plane is dependent on the planes below it. So, the surface depends on the skeleton, which depends on the structure, which depends on the scope, which depends on the strategy. When the choices we make don't align with those above and below, projects derail, deadlines are missed, costs begin to skyrocket, product doesn't deliver a satisfying experience.
This dependence means that decisions on the strategy plane will have a sort of "ripple effect" all the way up the chain. Conversely, the choices available to us on each plane are constrained by the decisions we make about issues on the planes below it.
That does not mean, however, that every decision about a lower plane must be made before the plane above it can be addressed. Dependencies run in both directions, with decisions made on upper planes sometimes forcing a reevaluation (or an evaluation made for the first time!) of issues on lower planes. At each level, we make decisions according to what the competition is doing, industry best practices, what we know about our users, and plain old common sense. These decisions can have a ripple effect in both directions.
If you consider your decisions on lower planes to be set in stone before you take on your decisions on higher planes, you will almost certainly be throwing your project schedule—and possibly the success of your final product—into jeopardy.
Instead, you should plan your project so that work on any plane cannot finish before work on lower planes has finished. The important consideration here is to not build the roof of the house before you know the shape of its foundation.