The first time I ever saw a Wizard dialog used in a software product, I thought it was a pretty good idea. If memory serves, this was right around the introduction of Windows 95, and Paula Abdul was still a singer. Software designers were still coming to grips with the graphical user interface, and let's face it - the toolbox wasn't too extensive at this point. You could build any interface you wanted as long as it was gray and consisted of text boxes, radio buttons and check boxes.
Users were also still learning Windows, so as forms grew in size and complexity, their eyes began to glaze over. The wizard appeared in this barren land, and it offered hope. Bite-sized chunks of user interface, punctuated by "Next" buttons (perhaps inspired by the rash of "to be continued..." TV episodes that also seemed popular at this time). The best wizards also featured colorful graphics to decorate the panels - all very slick.
Wizards, of course, became a victim of their own success. They multiplied until they reached critical mass. Wizards were everywhere -- especially, it seemed, where they weren't really needed.
Time and technology, of course, continued to march inevitably forward. Our tools improved. Our toolboxes grew new UI widgets. Al Gore invented the Internet.
Slowly, designers moved on to embrace these new tools and take up the banner of Usability. Alan Cooper taught us about affordances. Wizards were so Windows 95.
Appropriate Wizard Use
So has the Wizard been forevermore wiped from our pallet?
No - in fact, there are still places where a Wizard UI makes sense. They're still quite common for setup or configuration changes where you may want to go back to where you started if you screw up along the way. They're also used for editing business objects where a "valid" state requires a lot of data entry, and you don't permit "invalid" data to be saved. I'll talk more about this case later.
What factors tell you you've got a candidate for a Wizards?
- Complex operations. Your app needs to collect a lot of information. Maybe the data from one field affects the options available for another field.
- Transactional operations. There are distinct sections or steps in an operation, but they all should occur together in order for the operation to be considered complete.
- Ordered operations. It matters which things are entered first, second, and so on - again, perhaps because the answers on page one affect options on page three. Generally, wizards let you go backward to edit prior answers, but they won't let you skip forward.
Generally, at least one of two of these should be true before you use a wizard. The wizard features some UI elements and characteristics that uniquely satisfy these needs:
- Segmented UI. Complexity is managed by separating a big ol' hunk of data entry into bite-sized panels.
- Contextual "Next", "Back", "Cancel", and "Finish" buttons. These buttons appear only where they make sense ("Finish" won't appear until all required information is gathered, for instance).
- "Cancel" and "Finish" make the wizard transactional. The whole wizard either succeeds, leaving you in a "good" state, or it rolls back to where you were prior to starting the wizard. There's no such thing as bailing out in the middle with half your data set up.
Wizard Misuse
So, where do wizards not work?
The biggest problem I've seen with wizards are using them as a general data entry strategy. I'm trying to unravel a UI right now that had been designed to feature very prominent use of wizards. Add and edit screens, for instance, were designed as multi-page wizards -- and this was done for all of the objects in the system.
How does this violate the usability principles above? In most of these cases, there's a lot of data to enter, but the relationships really aren't very complex. There's no order; in fact, the wizard allows the user to skip to whatever step she wants. News flash: this isn't a wizard anymore; it's a funny-looking tab control.
To make matters worse, this UI is on web application, which forces the web app to incur a ton of extra overhead to accommodate the transactional expectation of the wizard. In one case, the UI even calls for a nested wizard, where you start one wizard from the middle of another one.
This would be awkward in a Windows app, where you've got real modal dialogs, and the rest of the rich UI tools needed to make this work technically.
In a web app, though, you've got the competing expectations that when you move from page to page, your work is saved; yet, when you hit "cancel" on the last wizard step, you're supposed to roll back your changes. What a nightmare!
Wizards for "Must-be-valid" objects
Earlier, I pointed out that one of the places where wizards are commonly used was to make sure that a complex object has been properly entered and validated before saving it.
If this is really a legitimate requirement, then a wizard control might be a good choice for you. I believe in most cases, however, you're really doing your users a disservice by "protecting" them this way.
I've seen these dialogs really frustrate users who get 3/4 through setting something up, only to find that they're missing a piece of information. They then have to abandon their work to go figure out how to get past that hurdle. In most cases, the system is much more usable if it allows the user to save whatever they've typed, and simply tracks the fact that this object isn't valid in its current state. Let the user come back and fix the broken bits later.
What are your wizard nightmares?
test
Nice summary of wizard history, do’s and don’ts. Well done.
Thanks. As more mainstream development happens in web apps vs. native apps, I don’t see nearly as many true “wizard” UI’s anymore, but I think the modal ideas in the interface still apply to other environments. Thanks for stopping by.
Nice summary of wizard history, do’s and don’ts. Well done.
Thanks. As more mainstream development happens in web apps vs. native apps, I don’t see nearly as many true “wizard” UI’s anymore, but I think the modal ideas in the interface still apply to other environments. Thanks for stopping by.
Another point for your “appropriate section” is frequency. In the software I work on we use wizards for complex operations that end users only run a few times a year. There’s no opportunity for the user to become expert at using a more efficient (but tougher to learn) interface. By the time they run the function again, they’re forgotten all the details, and they need the hand holding and step-by-step explanations that the wizard interface offers.
Excellent point. In fact, once people become familiar with the functions that are typically wrapped up in a wizard interface, the wizard just gets in the way.
Another point for your “appropriate section” is frequency. In the software I work on we use wizards for complex operations that end users only run a few times a year. There’s no opportunity for the user to become expert at using a more efficient (but tougher to learn) interface. By the time they run the function again, they’re forgotten all the details, and they need the hand holding and step-by-step explanations that the wizard interface offers.
Excellent point. In fact, once people become familiar with the functions that are typically wrapped up in a wizard interface, the wizard just gets in the way.