Use a wizard when:

• users want to accomplish a goal that has many steps
• users must complete steps in a specific sequence

Wizard don'ts

Unclear purpose
provide a clear, concise wizard label on every screen and a brief explanation of purpose on the first screen

Too many screens
Don't break your wizard into too many screens. Recommended is no more than 10 (the fewer the better).

Long wizard screens
In a wizard, users should be able to enter data and select a navigation option without scrolling.

No alternatives
If feasible, the wizard should not be the only option to complete a task. It should be an alternative method (sometimes more experienced users need a more flexible method than a wizard).

Technical jargon
When writing wizard content, avoid technical jargon and always write for the layperson.

Confusing language
Don't use double negatives. Confusion can also result when two words used in the same context cancel each other out. For instance, a confirmation that read "Are you sure you want to cancel this wizard? with possible responses "OK" and "Cancel" resulted in some users clicking "Cancel" to confirm that they wanted to cancel the wizard.

No "Cancel" option
Provide users with a way out (they might have entered the wizard by mistake).

No exit warnings
When a user clicks a "Cancel" button or other navigation option that is not part of the wizard, provide a warning (especially if data entered will be lost).

External tasks
Wizards are best applied to tasks that can be completed in an integrated, sequential fashion. When users enter a wizard, they should not have to leave the wizard to complete a task (e.g having to retrieve information from another location within the site).

Auto-tabbing
Don't use auto-tabbing. Creates more problems than it solves.

Crowded data displays
Don't overcrowd screens in an effort to reduce vertical scrolling. This usually results in diminished readability.

Wizard dos

Minimize download time
Screen file sizes should be 30KB or less

Provide additional help
Provide easy access to additional help such as context-sensitive instructions on each screen.

Break tasks down logically
An effective wizard breaks down a task into sub-tasks and sub-sub-tasks and sequences them in a way that is familiar and comfortable to users (use task analysis).

Inform users of progress
A wizards boundaries should include a distinct beginning and ending point. Users appreciate knowing where they are relative to these points. Include a progress meter of some sort in the interface.

Indicate required fields
As with online forms, be sure to indicate which items are required.

Limit external navigation options
When users are working with a wizard, it's good to keep them focused on the task at hand and avoid data loss due to inadvertently exiting the wizard. Minimize navigation options that are available outside of the wizard. At a minimum include a link back to the home page.

Design flexible wizard navigation
Users must be able to return easily to any previous screen. For the most flexible approach, consider a clickable map of the wizard process to return users to any previous screen instantly. It's essential that all previously entered data is maintained.

Summarise wizard data
Near the end of the process, users should be able to review a summary of the data they entered on previous screens. If the summary accurately reflects the information users want to submit, a "Finish" button should allow final completion. Before clicking finish, users should be able to go back to previous screens, make changes and easily go navigate back to the summary screen.

Write clear and concise error messages
A good error message should clearly and succinctly identify the problem and tell users what to do to correct it.

Minimize verbiage
Write help text and other information as tight as possible. Use active verb/noun statements such as "Select one option".

Provide shortcuts
Repeat users will be looking for ways to speed up the process. Make forward/next button active by default so that Enter key can be used, automatically place cursor in first editable field, pre-fill known information.