When to Develop a Wizard

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