Menu

Beta — We’re reformatting our articles to work with the new site, but this is one hasn’t been done yet; it may contain formatting issues. No need to report this. We’re working on it.

When to Develop a Wizard

by Tara Scanlon
on September 1, 1997

Development teams sometimes ask us about adding a wizard to their application.
Should they use a wizard or a cue card? Isn’t a wizard just a patch for
a bad interface? We conducted a usability study of several wizards in popular
software and have some ideas about which situations can best be solved with
a wizard.

What’s a Wizard?

We define a wizard as a structured series of dialogs that ask questions and
use these answers or choices to produce a result. Wizards are different from
tutorials and on-line help because they let users accomplish their work,
not just learn about it or manipulate a canned example.

When to Consider a Wizard

We’ve found that wizards can help in three situations:

Users Want to Accomplish a Goal that Has Many Steps
Before installation wizards were common, users had to copy files themselves,
edit autoexec files, set up control directories, and check to see if hardware
was functioning. We have yet to run into a user who would abandon the wizard
to do this manually.

Users Lack the Necessary Domain Knowledge
An example of this situation is financial forecasting software that
is aimed at individuals who have lots of experience in their business area,
such as restaurants, consulting, or manufacturing, but little experience in
accounting or finance.

Wizards in this application work well: the user supplies the problem; the
wizard supplies an expert’s perspective in an area outside the user’s
area of expertise. Wizards are often useful in this type of "ring" application.

Users Must Complete Steps in a Specific Sequence
One of our clients develops human resources software that requires
users to go through a pre-defined series of steps. For example, to hire a prospective
employee, a manager must check references, secure approvals, calculate salary,
make the verbal offer, and create the written offer. This client effectively
uses a wizard to make sure all those steps are performed in the appropriate
order.

When a Wizard May Not Help

Wizards are not a panacea. They can’t fix all interface or usability
problems. We’ve even seen cases where the wizard itself caused more problems
than it solved. Furthermore, creating a wizard is not trivial. Wizards are
software, with all the associated up-front development costs. The payoffs,
in the form of reduced support and training costs, don’t come until later.

We found that a wizard is less likely to be useful in the following situations:

When the Audience Is too Advanced
It sounds obvious, but we’ve seen some wizards that try to "help" with
things users already know how to do. For example, when we tested the Table
Wizard in Microsoft Access, one user told us he knew too much for the wizard. "It
feels cumbersome," he said. "I would have had it done a lot sooner
if I hadn’t used the wizard. I was already doing what it was going to
do for me."

When it Doesn’t Solve the Problem
With the advent of Windows 95, wizards have become much more prevalent.
In fact, we’re seeing some wizards that no one we’ve tested even
needs, and they seem to be included for the convenience of developers, not
users.

The Find Setup wizard solves developers problems, but not users. Click here to see why.

The Find Setup Wizard in Windows 95 is one such example. It lets users customize
the way the help database is searched. Unfortunately, no user we’ve seen
has ever changed the defaults, and many resent the extra required click.

When You Want to Teach
The users we’ve seen tend not to read supplementary text when
they are using a wizard. They are very focused on getting their work done.
Every time we’ve seen a wizard try to present a concept, it’s failed.
Wizards do, they don’t teach.

When There Isn’t Time to Test
It’s difficult to create an effective wizard. Even with what
we’ve learned about wizard design, we’ve never gotten one right on
the first try. When we develop wizards, which we prefer to do using paper prototypes,
we typically go through several usability tests, making revisions each time,
until we learn what works.

5 Traits of Successful Wizards

In testing wizards in popular software, our analysis identified five key traits
that affect their success. Note that these are not in order of importance.

Re-Entrancy
Users benefit if they can re-run the wizard and modify their previous
work. When they can’t get back into the wizard to revise what they’ve
created (even if it’s a minor change), users often delete their work and
re-run the wizard. We saw some users do this several times in completing a
single task.

Roadmaps
Successful wizards show an overview of the functions they contain and where
they appear. Included in the concept of a roadmap is the need to clearly mark
the boundaries of the wizard, so users know when they have finished.

Gap-Bridging
A gap exists when a wizard assists with only part of a process, contains
only a subset of the functionality, or is an alternative to non-wizard methods
(such as menu options) for accomplishing the task. If a wizard actively attempts
to address such a gap, we call it gap-bridging.

Clarity of Inputs
At each step, users needs to understand clearly what the wizard is asking.
A wizard should provide enough information for users to make decisions and
act on them. If it isn’t clear, users get stuck. Clarity of inputs problems
were the most common reason users went into help.

Predictability of Outputs
Users need to understand the implications of each choice they make
in the wizard; they need to know that their choices will produce the results
they expect. If a wizard lacks predictability, users may express surprise at
the results, back up to fix "mistakes," or repeatedly re-run the
wizard to experiment with different choices. •