UI Patterns and Techniques

Step-by-Step Instructions

From the installation of Netscape 7
Use when:	You are designing a UI for a task that is long or complicated, and that will usually be novel for the user -- not something that they do often or want much fine-grained control over, such as the installation of a software package. You're reasonably certain that those of you who design the UI will know more than the user does about how best to get the task done. Tasks that seem well-suited for this approach tend to be either very long and fiddly, or branched -- they consist of a series of user-made decisions that affect downstream choices. The catch is that the user must be willing to surrender control over what happens when. In many contexts, that works out fine, since making decisions is an unwelcome burden for people doing certain things: "don't make me think, just tell me what to do next." (Think about moving through an unfamiliar airport -- it's often easier to follow a series of signs than it is to figure out the airport's overall structure.) But in other contexts, it backfires. Expert users often find Step-by-Step Instructions (especially in wizard form) to be frustratingly rigid and limiting. This is particularly true for software that supports creative processes -- writing, art, etc. Know your users well!
Why:	"Divide and conquer." By splitting up the task into a sequence of chunks, each of which can be dealt with in a discrete "mental space" by the user, you effectively simplify the task. You have put together a preplanned road map through the task, thus sparing the user the effort of figuring out the task's structure -- all they need to do is address each step in turn, trusting that if they follow the instructions, things will turn out OK.
How:	Break up the operations constituting the task into a series of chunks, or groups. These groups may be thematic, such as payment information, billing addresses, etc. for an online purchase -- it doesn't much matter in which order they are presented, because later choices don't depend much on earlier choices. It helps the user to put related choices together. Alternatively, you may decide to split up the task at decision points, so that choices made by the user can change the "downstream" steps dynamically. In a software installation wizard, for example, the user may choose to install optional packages that require yet more choices; if they choose not to do a custom installation, the following steps are simpler. Dynamic UIs are good at presenting branched tasks such as this, because the user never has to see stuff that's irrelevant to the choices they made. In either case, the harder part of designing this kind of UI is striking a balance between the sizes of the chunks and the number of them. It's stupid to have a two-step wizard, and fifteen steps is more than users can easily fit in their heads at once (plus, it's tedious). On the other hand, each chunk shouldn't be overwhelmingly large, or you've lost some of the benefit of this pattern. Wizards are the most obvious and well-known implementation of Step-by-Step Instructions. They're not always the right choice, though, because wizards (as traditionally implemented) put each step into its own window or page, an isolated UI space that shows no context -- the user can't see what went before or what comes next. Correspondingly, an advantage of wizards is that each page can be completely devoted to that step, including illustrations and explanations. If you use a wizard, allow the user to move back and forth through the task sequence. There's nothing more frustrating than having to start a task over again just because the software wouldn't let you change your mind about a previous decision! Back and Next buttons are, of course, standard on wizards. Additionally, many UIs show a selectable map or overview of all the steps, getting some of of the benefits of Overview Plus Detail. (In contrast to that pattern, this one implies a prescribed order -- even if it's merely suggested -- as opposed to completely random access.) If you choose to keep it all on one page, you could use several patterns: Titled Sections, with prominent numbers in the titles. This is most useful for tasks that aren't heavily branched, since all steps might be visible at once. Progressive Enabling, in which all the steps are present on the page, but remain disabled until the user has finished the previous step. Progressive Disclosure, in which you wait to show a step on the UI until the user finishes the previous one. Good Defaults are useful no matter how you arrange the steps. If the user is willing to turn over control of the process to you, then odds are good they're also willing to let you pick reasonable defaults for choices they may not care much about (such as the location of a software installation). (The Design of Sites discusses this concept under the pattern name "Process Funnel." Their pattern is aimed more at Web sites, for tasks such as Web shopping, but the concepts generalize well.)
Examples:
From MS Money An example of showing steps all on one page. In this page, the user is free to move randomly through the steps, as none of the input fields depend on any others -- the numbers are there as a suggestion only.