Chunking the task:
Break up the operations constituting the task into a series of
chunks, or groups of operations. You may need to present these
groups in a strict sequence, or not; there is value in breaking
up a task into Steps 1, 2, 3, and 4 just for convenience.
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.
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
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
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:
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 he's also
willing to let you pick reasonable defaults for choices they may not
care much about, such as the location of a software installation.
- 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
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.)