How to Design a Form Wizard
And when not to
The form wizard is a user interface design pattern that enables untrained users to achieve a goal through a series of steps. The user enters data in each view and proceeds to the next step until completion.
Wizards are best employed for long and unfamiliar tasks that the user needs to complete once or rarely. Wizards are shown to reduce errors by making the user follow sequential steps. Wizards are often used for onboarding flows, where the user needs to enter a set of information to get started in an application.
For example, a personal finance application may ask new users to connect their bank account, verify their identity, and set financial goals. The information entered in this flow is needed to make the app useful.
Wizards are best used:
- For a fixed sequence of data entry that occurs infrequently.
- For untrained users who need to be guided through a stepped process.
- For a series of dependable and branched data input flows.
- When users need to accomplish a goal that relies on complex task and sub-task completion.
Wizards are a poor choice for expert users who commit actions frequently because it reduces their locus of control. Trained users often find wizards to be patronizing because of their inflexibility. Basic and sectioned forms are better alternatives for power users.
Designing a Wizard
1. Determine requirements and conduct research
The need for the incorporation of a wizard is determined after requirements of the system and user goals are understood. If the information needs occur more than once, entered by experienced users, or are limited, consider using other methods of data collection.
After system requirements are known, designers often employ task analysis to inform the wizard’s information architecture. It is important to allow the user’s needs to guide the process, instead relying on the creator’s biases. The goal is to bridge the gap between a user’s mental model, and the system’s data requirements.
Let’s pretend we are creating a personal finance application. We learn from research that our target users want to see all their transactions categorized and accounted for, and have a desire to set financial goals. Based on this insight, we determine some general startup tasks.
From there, we determine the information requirements based on these general tasks.
And start to think of logical groupings.
2. Create a task flow
Once the information requirements have been determined, it’s time to start thinking of the interaction flow. Information needs are categorized and batched into a dependable sequence of tasks and sub-tasks (and even sub-sub tasks). Grouping related actions and ordering steps sequentially reduce cognitive load by reducing the dexterity of data entry and providing a clear path to completion.
Often, the user flow will branch into different paths, dependent on previous inputs. A user may be prompted with a question that determines a new information need or sequence. This information is then either presented in another view, or on the current view. Populating additional inputs in a view is known as responsive disclosure.
For example, our personal finance on-boarding flow could incorporate different flows for connecting a user’s bank information. Perhaps a user doesn’t know their credentials, or they have set up security measures that make it hard to connect. This could be mitigated with a conditional flow, where the user is presented an alternative way to connect their bank account or information on how to attain the proper credentials.
3. Create a prototype and conduct usability tests
Continuing with the personal finance app, below is the first view of the prototype. A prototype doesn’t have to be this put together. It can be anything from a basic paper prototype to a HTML/CSS prototype. Different apps and contexts will require different levels of fidelity. What matters is your ability to collect qualitative feedback from your target users.
Usability tests are a good way to collect qualitative feedback from a prototype. During the usability tests, ask the user to perform tasks, and describe what they are seeing and thinking. This will provide insights that will drive further design iterations.
4. Iterate and implement
Make design iterations based on the results of the usability tests, and then work with engineers to implement the wizard in the app. It is important to conduct further usability tests after it launches to ensure it accomplishes the goal, meets user needs, and is bug-free. From there, consider implementing quantitative analysis like A/B testing to further validate the design through data.