I often talk about onboarding as having a few jobs: Building trust; familiarizing users with a product’s offerings; setting up logistics; and guiding users toward next steps, until they achieve a steady state.
That third item in the list, setting up logistics, sometimes becomes the responsibility of setup wizards. I’ve worked on and encountered a fair number of setup wizards in my time working on apps, devices, and operating systems. In this post, I’ll give you an overview of what goes into designing one.
The basics
As computer software started rolling out to the every-person in the late 20th century, companies realized they needed to make software more approachable. Among a variety of new experiences, like the GUI, built to reduce the technical know-how needed to use a computer was the wizard, a type of flow that “magically” transformed complex commands into a simplified process.
Today we can find many ancestors of the original wizard flows. They might guide you through creating a new project or ask your preferences for glasses styles in order to recommend the right frames. But perhaps one of the most common use cases for a wizard is for setup, taking the essential (and often, technically complex) configurations necessary to get something digital up and running by putting those configurations into easy-to-follow stepped flows. One of the first setup wizards I designed was for setting up the drivers of a multifunction printer-copier. Since then, I’ve helped create setup wizards that range from setting up a smartwatch to setting up accounts and services.
Setup wizards (sometimes also called “quickstart wizards”) are typically constructed as a modal, standalone flow that presents a sequence of screens, with each screen representing a step that needs to be taken to complete setup. The completion of one step will progress a user to the next in the sequence. After all requisite steps have been completed, the setup flow will exit and the user will be able to use (or continue using) a product.
An important distinction between a setup wizard and something like an introductory tour or a clickable feature walkthrough is that a setup wizard is built around actions. A setup flow is not about presenting passive information. They’re there so users can do the basic things they need to, to get on with using the product they’ve just unboxed or downloaded.
Setup actions might include:
- Entering information, like selecting a WiFi network and entering a password so a device can get connected;
- Enabling functionality, like clicking a button that turns on location permission to turn on GPS or calibrating a fingerprint scanner so a device can be unlocked without a password. This may in some cases mean accepting legal or privacy terms, but take care to only include these if they are absolutely necessary.
- Setting a preference, such as choosing the font sizing on a computer.
Setup wizards can be good options for devices that can’t function out of the box without some configurations in place. They’re also useful if you have a product that absolutely requires data and verification to be set up before use, such as a dating app that needs to ensure people have a verified account with some minimal effort put into it before allowing them to access the profiles of other members which may contain sensitive information.
That said, most products shouldn’t need a setup wizard. Used unnecessarily, dedicated setup flows can make a product feel much more complex than it actually is, and lead to abandonment due to frustration or fatigue. One reason most products don’t need a setup wizard is because a number of tasks that used to require setup no longer need it. Systems have automated a lot of the configurations that users once were responsible for. For example, mobile apps don’t require an installation flow: most devices now use a predefined directory for apps, and the App Store/Play Store mediates the rest of the process. A lot is happening behind the scenes when you see app installation states in the App or Play Stores!
The second, and most salient reason that the majority of products shouldn’t need a setup wizard, is that most things can be set up ad-hoc, at runtime, as opposed to being lumped together in a modal flow all at once.
Runtime vs. front-loaded setup
Guided interaction encourages us to build experiences that move at the user’s pace by distributing work, decisions, and information in the context of use. While up-front setup wizards have a place, runtime setup is often a better solution for most products. Runtime setup is when individual steps and decisions are presented individually, in the context of use. An example of this is the runtime permissions model on Android and iOS, where users are asked to grant permissions in the moment they need them instead of peppering the user with multiple permission requests at once.
Runtime setup is, ultimately, day-to-day decision making. A social media app may allow you to browse content anonymously, but then prompt you to create a profile when you want to reply or post your own content. A shopping app might only request location permission if a user wants to search for stores near them, then separately for notification permission if a user places an order they want to track, rather than making them agree to both and potentially other permissions in a series out of context, during a front-loaded flow. You can still use a multi-step, wizard-like format for most complex runtime setup moments, but it’s just triggered at runtime, rather than required up front.
And even if you do need an up-front setup wizard, you’ll still need runtime ways for the user to change the decisions they made and preferences they set, later. If a user selected a wifi network during the setup of a mobile phone, they still need a place to switch to another network later. If they uploaded profile photos while setting up a dating profile, they need a way to adjust those later. And so forth.
The design of setup wizards
OK, so you’ve decided you truly do need a setup wizard for your product or service. How to best design it so that it’s simple and clear? The setup flow represents both a broad action (for example, “set up a device”) and consists of individual, more granular actions in service of it (such as “connect to bluetooth”). To design a coherent experience, I like to apply the same 3-part structure to both the design of the broad setup and individual step levels. This structure is about breaking each down into a prompt, the work, and a follow-up (and this happens to be my general recommendation for designing onboarding actions across the board).
At the flow level
The setup flow represents one broad actions, such as “set up a device.” At the flow level, the prompt is what invites the user to begin setup, the work comprises all the steps of setup, and the follow-up confirms that setup is finished and points users to next steps.
The prompt: it’s all about setting expectations
The prompt is the element that invites the user into the setup flow. This might be the first screen shown on a device if setup is required. Or perhaps it’s a dialog shown after a user clicks on an action that requires a setup flow to be completed.
At the setup level, the prompt needs to:
- Set expectations about what a user will be expected to do during setup. This is especially helpful if someone is going to need to spend some time on this flow. It may also include a conditional instruction, such as asking users to connect the device to a charger before continuing.
- State what the value is of proceeding with the work that setup will require: For installing software or setting up a device, it might be clear that the purpose is to get the device working. For creating an account, it might need to be anchored around the benefit of the account itself.
The work: Scope thoughtfully and signpost relentlessly
The work is the collection of individual steps that make up the bulk of setup. Steps should be limited to those required to complete its promised goal.
There’s no one size fits all way to scope the set of actions that should go in setup, but you need to find the right balance between enough steps to achieve the goal of setup itself, yet not so much that the flow becomes tedious or full of unrelated, unnecessary, or out of context decisions. Here are two of my rules of thumb. First, if most of the steps are optional, that’s a good signal you don’t require up-front setup and can rely on a runtime model. And second, all steps presented to users should have a noticeable impact on their experience as soon as setup is complete. Choosing a color theme during setup of a smartwatch, for example, will have a noticeable change on the experience users see when setup is complete; on the other hand, providing demographic information usually only benefits your team internally, or takes a long time for the user to see any benefit, so shouldn’t be included.
Now, in addition to making sure you scope the right steps for setup, those steps should then be well-signposted.
Signposting is the act of indicating where people are in the setup process. Unless setup is as short as 1-2 steps, you should always show users their progress relative to the whole of it. Designing setup wizards to be determinate — where the system can show at the start how many tasks a user needs to do to complete it — is your goal. Then you can implement all sorts of signposting that make it clear to users how close they are to finishing the wizard.
In rare cases, you may need to adjust signposting partway through a flow, or hold off on showing it until you have a bit more certainty on what’s being set up. For example, the Avada wordpress website setup wizard starts with two steps (“registration” and “setup type”) and once the user chooses their setup type, the steps expand gracefully to reveal how many additional steps that path requires.
However, if you plan in advance the kinds of common steps all devices need, you can find a way to group them so that they can be determined from the start. And you should never avoid signposting just for the purpose of having the ability for teams to slide in new steps ad-hoc later; any time you consider adding a new step, it should be considered in the context of the whole.
The last note on the work of the setup flow is that it should handle canceling and early exit. There is usually some way in the steps of setup for a user to exit, go back, or start over. Make sure these are visible to the user, and give them the option of picking up where they left off if they start again.
The follow-up: Bookending the experience
The follow-up is what happens at the end of the setup flow. It’s a confirmation and end state that reinforces what has been completed, and points users to next steps. The follow-up may be a standalone screen at the end of setup, giving the user a clear sense of completion after the work they put into it. Other times, the follow-up can be achieved simply by redirecting users to the ready state of the product after completion of the last step. This is an important part of setup and one to make sure to do well.
Designing at the per-step level
That 3-part structure of prompt, work, and follow-up can also be applied to each individual step in the setup flow.
The prompt
In the context of an individual step, will describe the benefit of completing the step, and will present any instructions the user should be aware of before proceeding.
The work
The work of a step can vary in complexity. It may show up on the same screen as the prompt and be as simple as committing the action by hitting a “next,” “agree,” or other primary action button. Or, the work might involve a few sub-tasks, like entering information or agreeing to a secondary permission prompt.
It’s important during the work of an individual setup step to also handle errors in an actionable way. One of the benefits of setup wizards is that, because they break complex flows into smaller parts, it becomes easier to resolve issues at the point they occur instead of failing an entire flow unceremoniously. Make sure that if an error is hit at some point in setup, that the user is given clear messaging and an actionable way to resolve it.
The follow-up
The follow-up on a per-step basis is often as simple as animations and transitions; showing the user that the step was completed by automatically progressing them to the next step and updating the signposting accordingly.
Having a structure that can be applied at both the broader setup flow level and the per-step level will make it easier to design good setup wizards. It will also make the steps in setup more extensible: when you need to let users revisit steps later on, at runtime, you can take the same Work part of the step, remove the signposting that implies it’s part of a larger flow, and change up the prompt and follow-up as appropriate to have it triggered in the context of use.
Summary and conclusion
Used appropriately, a setup wizard takes the essential and technical configurations necessary to get a device or service running by putting those configurations into an easy-to-follow stepped flow. Setup wizards are best used when you have multiple configurations that all relate to a clear, single, user-centered goal (such as “set up a printer” or “set up a dating profile”), and when the impact of each choice in setup can be clearly seen in the product as soon as setup is completed. Remember that most products don’t need a setup wizard and can use runtime setup instead.
Once you have decided that a setup wizard is right for you, you can break the flow, as well as its individual steps, into a prompt, work, and follow-up for ease of structuring. Finally, ensure you allow users a way to change any of the choices they made during setup somehow, later on in the product experience.
Best of luck in your setup wizard designs! If you’d like more advice on how to design various new user experiences, check out my book Better Onboarding from A Book Apart.