The task of inputting data into the system is parted into multiple steps. Each step is presented to the user one at a time.
The user should be presented with information about the steps that exist and which are completed.
The Wizard pattern is very similar to the Steps Left pattern. The difference between the two is the focus. Where Steps Left is focused only on explaining the steps of a process, the Wizard pattern is about parting dependable sub-tasks needed to perform a complex goal into separate steps.
The Wizard pattern is also different from the Steps Left pattern in that the steps needed to perform a goal can vary depending on the information inputted in earlier stages. In this way, the Wizard pattern separates itself from being merely an visible aid for the user.
Basically, a wizard is a series of screens or dialogue boxes walking users through the completion of a task. Each screen asks the user to input information by either making selections or filling in fields. After inputting data, users navigate through the wizard by clicking navigation options like “Previous” and “Next”. At the final step users click “Finish” instead of “Next”, which thus indicates the completion of the wizard.
It is also practice to include a “Cancel” button on all screens that will lead the user back to where he or she came from. Typically, a “Cancel” button is located near other navigation buttons, but in a position that clearly separates the button from the “Previous” and “Next” buttons. Furthermore, it is also good practice to provide a warning if data inputted up to that point will be lost clicking the “Cancel” button. It is fair for to assume that the user expects that he or she can return to the wizard later and start from where they left off3. In order not to frustrate the user more than necessary, the consequences of exiting the wizard should be communicated.
Wizards are meant to be fast and easy. For this reason, it is a good idea to keep the content of a screen as well as its navigation above the fold.
Keep the wizard’s purpose clear on every screen by placing a clear and concise label on every screen. Optionally accompany the label with a brief explanation of the wizard’s purpose on the first screen. This will help users remember why they entered the wizard in the first place and how they will benefit from finishing the wizard.
Users of a wizard aren’t necessarily experts, why you should refrain from using technical jargon to prompt users. The language used should fit in to the user’s frame of reference5.
It is good practice to present a summary of choices made throughout the wizard to the user near the end of the wizard. This will allow the user to review and double-check inputted data before the final “Finish” button is clicked. In the case the user wishes to change the data entered, he or she should be able to navigate back to the given page where the date was entered. If the amount of steps in the wizard is greater than 8-10, it is a good idea to provide links directly to the screen of the data input.
A wizard is a perfect place for using Good defaults. Most wizard users are not familiar with the task they are performing and is thus likely as unfamiliar with good values for the choices they are asked to make.
By separating complex tasks needed to achieve a goal into several steps, the process of inputting data can take several different directions depending on what input is entered.
The complex task of inputting large amounts of dependable data can be adjusted and streamlined to fit the decisions of a user throughout a process. In the context of decisions the user makes in each step, unnecessary steps can be cut out and important steps can enter into the focus.
In a system with many variables, a user can reach many goals manipulating these variables in different ways. The Wizard pattern can be used to group such variables into separate goals. This will convert the task of completing a complex goal from requiring multiple actions from the user into being a coherent process.
When users are forced to follow a set of pre-defined steps they are less likely to miss important aspects of a process and will thus commit fewer errors.
Wizards are often made for the untrained user. For this reason, make sure your wizard can be completed without training. A rationale behind using a wizard is to avoid training for rare or intimidating tasks – not to develop expertise5.
Using the Wizard pattern helps the user perform a complex task, but can at the same time effect the performance time of the task.
An effective wizard breaks down a complex tasks into sub-tasks and possibly sub-sub-tasks. Sub-tasks are through task analysis broken down and sequenced in a way that feels familiar and comfortable for the user. Such task analysis is conducted before screen design begins and is best done observing real users performing the task in their own work environment. The output of the task analysis is an outline and information architecture for the wizard.
By breaking a task up into many screens, there is a chance to loose the user. If the process of finishing the wizard feels too long, the user often gets annoyed and possibly abandons the wizard before finishing it.
While the amount of screens should be limited, you should not always keep the amount of screens to a minimum. When a screen of a step in your wizard grows to a height that does not fit into a regular screen solution, there is a risk of annoying the user and making the wizard tiresome to finish as it forces the user to scroll to enter data and navigate back and forth. Consider breaking such steps up into two or more screens.
To find out whether you have hit the right balance between a low number of screens and short screen heights, put your wizard through a usability test. It is hard to define other means of checking when a good balance between the two has been found.
A wizard support users performing a task by lowering the learning curve. It can seemingly bring a user to a achieve a higher performance in less time than without the wizard. It however comes with the cost of dumbing down the task as users perform tasks without understanding them and being aware of the underlying decisions5. The result is users not being able to perform a task if the wizard is not available as well as not being able to fine tune decisions made by manipulating other parts of the system.
A wizard should not be the only way for users to complete a task, but merely an alternative to another more complicated method of completing the same task. Use a wizard for allowing the untrained user to get started quick and let the more experienced users, who prefer more flexibility than the wizard allows, use the more complicated method.
1 Wizard design pattern by Jenifer Tidwell.
2 Wizard design pattern by Martijn van Welie.
3 Crafting a wizard by Jodi Bollaert.
4 More Web-based wizard tips and tricks by Jodi Bollaert.
5 Designing wizards by Saul Carliner
6 Wizards and guides by Bob Baxley at Boxes and arrows.
The wizard for uploading images for printing is a common process to split up in a wizard. Before you can order your prints, you must first upload the images you want printed, so that quality, sizes, etc. can be chosen based on the file you uploaded.
Before you can set permissions, you first need to create a repository - this sequence dictates the wizard.
You can't set permissions and create users on a repository unless it has been created first. This is why this process of creating a new repository dictates the wizard format. Notice how well the process is communicated with the steps-graphics in the top of the page as well as with the next button.
Wizard for launching a live stream video channel.