Wizard

Tasks that seem well-suited for this approach tend to be either branched or very long and tedious -- 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. You don't get to learn much about how the airport is designed, bu you don't care about that.

But in other contexts, it backfires. Expert users often find Wizards frustratingly rigid and limiting. This is particularly true for software that supports creative processes -- writing, art, or coding. It's also true for users who actually do want to learn the software; wizards don't show users what their actions really do, nor what application state is changed as choices are made. That can be infuriating to some people. Know your users well!

A thematic breakdown for an online purchase may include screens for product selection, payment information, a billing address, and a shipping address. The presentation order doesn't much matter, because later choices don't depend on earlier choices. Putting related choices together just simplifies things for people filling out those forms.

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, those steps are skipped. Dynamic UIs are good at presenting branched tasks such as this, because the user never has to see what is 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 silly to have a two-step wizard, and a fifteen-step wizard is tedious. On the other hand, each chunk shouldn't be overwhelmingly large, or you've lost some benefits of this pattern.

Physical structure: Wizards that present each step in a separate page, navigated with Back and Next buttons, are the most obvious and well-known implementation of this pattern. They're not always the right choice, though, because now each step is an isolated UI space that shows no context -- the user can't see what went before or what comes next. But an advantage of such wizards is that they can devote an entire page to each step, including illustrations and explanations.

If you do this, allow the user to move back and forth at will through the task sequence. There's nothing more frustrating than having to start a task over just because the software won't let you change your mind about a previous decision. Back buttons are, of course, standard equipment on separate-page wizards; use them, and make sure the underlying software supports stepping backwards. Additionally, many UIs show a selectable map or overview of all the steps, getting some of the benefits Two-Panel Selector. (In contrast to that pattern, Wizard implies a prescribed order -- even if it's merely suggested -- as opposed to completely random access.)

If you choose to keep all the steps on one page, you could use one of several patterns from Chapter 4:

• Titled Sections, with prominent numbers in the titles. This is most useful for tasks that aren't heavily branched, since all steps can be visible at once.
• Responsive Enabling, in which all the steps are present on the page, but each remains disabled until the user has finished the previous step.
• Responsive Disclosure, in which you wait to show a step on the UI until the user finishes the previous one. Personally, I think this is the most elegant way to implement a short Wizard. It's dynamic, compact, and easy to use.

(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.)

TurboTax is a web application that presents several steps in a wizard-like fashion. Each major step is on a separate page, and the pages have "Back" and "Continue" (or "Done") links at the ends of the pages, as traditional wizards do. (They're not visible on these screenshots, but trust me, they're there.) A Sequence Map at the top shows where you are in the steps at all times. Good Defaults generally aren't used here. That may be because sensitive information -- personal financial data -- is involved, but many users will find themselves entering "0" for a lot of fields.

The Expedia example (top of page) showed a wizard structured with Titled Sections (Chapter 4); the TurboTax example uses a paged model, replacing the contents of the browser window with each successive step. This example uses a Card Stack (also Chapter 4) to fit all steps into a very limited space. When a user selects a date from this calendar and clicks "Next Step," panel 2 opens up. When that step is done, the user moves on to Panel 3. The user can go back to previous steps anytime by clicking on the yellow titlebars.

Also note the use of a Preview (Chapter 5) on the righthand pane of the window, entitled "Your Itinerary." This tracks the user's choices (no pun intended) and shows a summary of those choices. This is convenient because only one wizard page is visible at a time; the user can't see all his choices at once.