How to Design a Form Wizard

Best practices for designing a form wizard and when not to

Preparing audio… Please refresh page

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.

Two onboarding screens from a personal finance app displayed in a step-by-step wizard format. The first screen prompts users to connect a bank account, and the second guides them to set financial goals—each with progress indicators and clear call-to-action buttons.

Example of two screens from a personal finance app’s onboarding flow presented in a wizard.

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.

  • untrained users who need to be guided through a stepped process.

  • 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

multiple design iterations of Flexport’s onboarding flow, including wireframes, user flow diagrams, and annotated interface screens—illustrating the evolution of layout, content structure, and interaction patterns over time.

A snapshot of the iteration that went into creating Flexport’s onboarding flow

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 of 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 the 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.

A visual list of general startup tasks for a personal finance app, including adding personal information to create an account, connecting bank accounts, and setting financial goals—arranged in a simple, linear sequence.

General user startup tasks for the personal finance application: add personal info to create an account, connect banks, set financial goals.

From there, we determine the information requirements based on these general tasks.

A diagram outlining the information requirements for a personal finance application, detailing the specific data needed for account creation, bank connection, and financial goal setting—organized into labeled sections or categories.

Information requirements for the personal finance application.

And start to think of logical groupings.

A visual grouping of information requirements for a personal finance application, categorizing related data fields—such as personal details, financial account info, and goal preferences—into logical sections to support task flow design.

Information requirement groupings for the personal finance application.

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.

A diagram illustrating a branching task flow, showing multiple user paths based on different inputs or decisions—each branch leading to distinct steps or screens within a form wizard.

Example of a branching task flow

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 onboarding 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 with an alternative way to connect their bank account or information on how to attain the proper credentials.

A stepper UI illustrating the grouped onboarding tasks for a personal finance app—each step labeled with a key action like entering personal info, connecting bank accounts, and setting financial goals—showing a clear, linear progression.

Personal finance on-boarding task groupings represented in a stepper.

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 an 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.

The initial screen of a personal finance app’s wizard-style onboarding flow, prompting the user to enter personal information with clearly labeled input fields, a progress indicator, and a ‘Next’ button to continue to the following step.

The first step of the personal-finance app’s wizard onboarding flow.

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.


Form Wizard Best Practices

A form design example highlighting best practices, specifically showing a progress indicator—such as a stepper or progress bar—at the top of the interface to visually communicate how far the user is in the process.

Incorporate a progress indication affordance.

A visual example of a streamlined form wizard with fewer than 10 steps, emphasizing simplicity and user focus—designed to minimize abandonment by reducing cognitive load and friction.

Reduce the number of steps. The more steps included, the greater the chance of user abandonment and annoyance. Try to keep wizards under 10 steps.

A screenshot of a form wizard interface with limited navigation options—no sidebar, top nav, or external links—intentionally designed to keep users focused on completing the step-by-step flow without distractions.

Minimize the ability to navigate outside of the wizard. This will keep users focused on completion.

A form interface displaying clearly labeled input fields with concise helper text beneath each label, providing users with brief explanations of the purpose of each field to reduce confusion and guide accurate data entry.

Include labels and a brief explanation of purpose.

A form wizard interface featuring prominent ‘Next’ and ‘Back’ buttons, styled for visibility and ease of use—enabling users to move forward or revisit previous steps in the flow with confidence and control.

Incorporate clear action buttons and allow users to navigate back and forth.

Form wizards aren’t just a way to break up long forms—they’re a scaffolding for decision-making. When designed well, they reduce friction, build trust, and guide untrained users through unfamiliar territory with confidence. But like any tool, they require restraint. Overuse turns helpful guidance into hand-holding. The best wizards are invisible—felt through flow, not noticed through friction.

Design for clarity, not control. Guide, don’t gate.

Andrew Coyle sitting in a building overlooking downtown San Francisco.
Andrew Coyle sitting in a building overlooking downtown San Francisco.
Andrew Coyle sitting in a building overlooking downtown San Francisco.

Written by Andrew Coyle

Andrew Coyle is a Y Combinator alum, a former co-founder of Hey Healthcare (YC S19), and was Flexport's founding designer. He also worked as an interaction designer at Google and Intuit. He is currently the head of design at Distro (YC S24), an enterprise sales AI company.