The Marathon and the Sprint

Just as you shouldn’t leave any aspect of the user experience to chance, you shouldn’t leave your own development process to chance either. Too many development teams operate in a state of permanent emergency. Each project is conceived as the response to some perceived crisis, and as a result, every project is behind sched- ule before it even begins.

Here’s a metaphor for the user experience development process that I often use when describing problems to clients: A marathon is not a sprint. Know which kind of race you’re in and run accordingly.

A sprint is a short race. Sprinters have to call upon vast reserves of energy at the instant the starting gun is fired—and they expend all of that energy in the space of a few minutes. Right off the starting line, the sprinter has to run as fast as he can and keep running as fast as he can until he reaches the finish line.

A marathon is a long race. Marathon runners need just as much energy as sprinters do, but they expend it very differently. Suc- cess in the marathon depends on how effectively the runners pace themselves. All other factors being equal, the runner who knows when to speed up and when to slow down is far more likely to win—or even to finish the race at all.

The sprint strategy—run as fast as you can from beginning to end—can appear to be the only sensible approach to a race. It seems like you ought to be able to run a marathon as if it were a series of sprints—but it doesn’t work that way. Part of the reason it doesn’t work that way is the simple physical limit of human endur- ance. There’s another factor here, too: To accommodate that limit, marathon runners constantly monitor their performance, watch for what’s working and what isn’t working, and adjust their approach accordingly.

Product development is rarely a sprint. More often, there will be times when you push forward, building prototypes and generating ideas, followed by times when you pull back, testing what you’ve built, seeing how the pieces fit together, and refining the big picture for the project. Some tasks are best undertaken with an emphasis on speed; others require a more deliberate approach. Good mara- thon runners know which is which—so should you.

Thoughtful, deliberate design decisions will cost you time in the short term, but they will save you much more time in the long term. Designers and developers often lament the lack of attention to strategy, scope, and structure in the projects they work on. I have been involved in more than one project in which these activities were constantly under threat of being eliminated. Some people get

impatient with tasks that don’t involve the production of an actual site component like a graphic or a piece of code. These tasks are often the first line items cut from a project that’s behind schedule or over budget.

product as functionality product as information

structure

strategy

scope

skeleton

surface

Sensory Design

User Needs

Product Objectives

Functional

Specifications

RequirementsContent

Information Design

Interface Design

Navigation Design

ation

Design

ctionality

Interaction

Design

tion

ArchitectureInformation

onal

ons

User Ne

t Obj

en

nt

n D

ati

re

But these tasks were included in the project scope in the first place because they served as essential preparation for later deliverables to come. (That’s why the five planes build from bottom to top, each serving as the foundation for those above it.) When these tasks are eliminated, the tasks and deliverables left in the project schedule feel uninformed by the larger context of the project and discon- nected from one another.

When you get to the end, you’ve got a product that falls short of everyone’s expectations. Not only have you failed to solve your original problem, you’ve actually created new problems for your- self because now the next big project on the horizon is to attempt to address the shortcomings of the last project. And so the cycle repeats.

Looking at a product from the outside—or coming into the develop- ment process for the first time—it’s easy to focus on the more obvi- ous elements near the top of the five-plane model at the expense of those closer to the bottom. The irony, however, is that the elements that are hardest to see—the strategy, scope, and structure of the product—play the most important role in the overall success or failure of the user experience.

In many cases, failures on upper planes can obscure successes on lower planes. Problems with visual design—layouts that seem clut- tered or busy, or colors that are inconsistent or clashing—can turn users off so quickly that they never discover all the smart choices you made with navigation or interaction design. Poorly conceived navigation design approaches can make all your work to create a sound, flexible information architecture seem like a waste of time.

Similarly, making all the right decisions on the upper planes means nothing if those decisions are founded on bad choices made on the lower planes. The history of the Web is strewn with sites that failed because, although they were beautiful, they were utterly unusable. Focusing on visual design to the exclusion of the other elements of user experience drove more than one start-up into bankruptcy and led other companies to wonder why they were bothering with the Web at all.

It doesn’t have to be that way. If you approach your product devel- opment process with the complete user experience in mind, you can come out of it with a product that’s an asset, not a liability. By making everything the user experiences with your product the result of a conscious, explicit decision, you can ensure that the product works to fulfill both your strategic goals and the needs of your users.

C