The user experience development process is all about ensuring that no aspect of the user’s experience with your site happens without your conscious, explicit intent. This means taking into account every possibility of every action the user is likely to take and understanding the user’s expectations at every step of the way through that process. It sounds like a big job, and in some ways it is. But by breaking the job of crafting the user experience down into its component elements, we can better understand the problem as a whole.

The Five Planes

Most people, at one time or another, have purchased a book over the Web. The experience is pretty much the same every time—you go to the site, you find the book you want (maybe using a search engine or maybe by browsing a catalog), you give the site your credit card number and your address, and the site confirms that the book will be shipped to you.

That neat, tidy experience actually results from a whole set of decisions—some small, some large—about how the site looks, how it behaves, and what it allows you to do. These decisions build upon each other, informing and influencing all aspects of the user experience. If we peel away the layers of that experience, we can begin to understand how those decisions are made.

• The Surface Plane

  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 book cover or the logo of the site itself.

• The Skeleton Plane

  Beneath that surface is the skeleton of the site: the placement of buttons, tabs, 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 Structure Plane

  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 items allowing the users to browse categories of books; the structure would define what those categories actually were.

• The Scope Plane

  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. Some sites that sell books offer a feature that enables users to save previously used addresses so they can be used again. The question of whether that feature—or any feature—is included on a site is a question of scope.

• The Strategy Plane

  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 bookstore example, some of the strategic objectives are pretty obvious: users want to buy books, and we want to sell them. Other objectives might not be so easy to articulate.

Building from Bottom to Top

These five planes—strategy, scope, structure, skeleton, and surface—provide a conceptual framework for talking about user experience problems and the tools we use to solve them.

On each plane, the issues we must deal with become a little less abstract and a little more concrete. On the lowest plane, we are not concerned with the final shape of the site at all—we only care about how the site will fit into our strategy (while meeting the needs of our users). On the highest plane, we are only concerned with the most concrete details of the appearance of the site. Plane by plane, the decisions we have to make become a little more specific and involve finer levels of detail.

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 often detail, deadlines are missed, and costs begin to skyrocket as the development team tries to piece together components that don’t naturally fit. Even worse, when the site finally does launch, the users will hate it. 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 the lower plane must be made before the upper plane 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 decisions on lower planes. At each level, we make decisions according to what the competition is doing, industry best practices, 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 at the very least—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 not to build the roof of the house before we know the shape of its foundation.