Member-only story
Wizards may be an ancient design pattern, but they still have some uses
Designing for important but infrequent tasks often requires a wizard
Sometimes, you might design for important but infrequent tasks, such as installing new software.
In those cases, you might want to rely on a design pattern that you and I might have grown up with: the wizard.
Wizards are decades-old design patterns that have fallen out of favor in place of dynamic forms. Still, that doesn’t mean there aren’t modern use cases where they’re often the right design pattern.
However, we’ve learned a lot since the pattern was implemented in the early 1990s: we’ve learned how to design well-implemented wizards by asking ourselves a few questions.
But before we get into that, we need to first understand how wizards differ from other similar design patterns.
Wizards, Onboarding, and Dynamic Forms (Oh my!)
Two common design patterns are often used today instead of wizards:
- Onboarding, which can often consist of tutorials or overlays
- Dynamic Forms, which can now show interactions like in-line errors
Both design patterns are often used in similar situations where you might use a wizard, but there are two critical differences between them and wizards: user input and discrete steps.
Onboarding is a method of walking your users through different features, aspects, or steps of a website that usually occurs the first time you launch an app or website.
However, this is often a 'feature preview': the user can't input anything other than to either move forward or skip the tutorial.
This is where another pattern, Dynamic forms, comes into play. These forms can show feedback like error messages in real-time, such…
