Wizard

Task flows refer to the steps users progress through when interacting with patterns. They’re based on specific scenarios and demonstrate how users can successfully perform tasks within each pattern layout. To find prototypes for the task flow examples shown on this page, visit our Task flows (internal only).

Task flow types

There are two types of wizard task flows: fixed and branching. Fixed wizards have a predetermined number of steps, while branching wizards add or remove steps dynamically based on user input. Both task flows can be implemented with any of the patterns outlined in the usage guidelines.

Note: For both flow types, the multi-page example is shown using the “wizard with horizontal stepper” pattern. To create these flows with a vertical multi-page pattern, check out wizard with vertical stepper. In addition, the mobile pattern is only shown with the fixed flow, but can be implemented with branching logic as needed.

Fixed wizard

Fixed wizards have a predetermined structure. All users encounter the same fields regardless of their input and may return to previous steps and change their input without affecting their progression through the form.

Fixed wizard with multi-page pattern

Fixed wizard with single-page pattern

Fixed wizard mobile pattern

Branching wizard

Branching wizards update dynamically based on the user input. As fields are completed, branching logic determines if additional fields are relevant moving forward.

Note: Multi-page patterns are the preferred pattern for branching wizards, as it’s easier for users to tell when an additional step has been added. The single-page pattern is only recommended for shorter forms with minimal branching logic.

Branching wizard with multi-page pattern

Branching wizard with single-page pattern

Feedback flows and status updates

Feedback typically occurs after the user takes an action to help them correct mistakes or guide next steps. Status refers to updates that typically don’t require user action. Both communicate important information to users such as errors and success.

Feedback and status updates can be communicated during the wizard flow, either in the middle of a step or when the user transitions between steps.

• Reference Forms to learn more about form validation, as forms are a key part of a wizard flow.
• Reference Feedback and status to learn more about communicating feedback and status.
• Reference Messaging for guidance on crafting content within alert messages.

Feedback within steps

Feedback within steps refers to error feedback that’s provided as soon as the user removes focus from a field. This can help catch simple mistakes as soon as they happen.

Removing focus from a field

In this flow, the user removes focus from a field, either leaving it blank or inputting data in the wrong format. Feedback should be provided immediately in the form of an error.

• Use an inline error message to call attention to the error and help the user correct it quickly.
• Use clear language to explain the error and how to fix it. For example, ensure the message highlights if the field was left blank or provides the correct format so the user can correct it quickly.

Feedback between steps

Feedback between steps occurs when errors are caught as the user tries to move from one step to the next. This type of feedback calls attention to errors that weren’t caught earlier and notifies users that they can’t proceed without making corrections.

Trying to proceed with errors

In this flow, the user tries to move past their current step with errors. This can happen if errors weren’t caught as soon as they occurred or if they’re more difficult to catch, such as an invalid credit card number.

• Use inline error messages to call attention to fields with errors.
• Use a Section message to notify users that they can’t proceed past their current step without correcting errors.
• Use clear language to tell the user what went wrong and how to fix it.

Editing previous steps in branching flows

In this flow, the user edits a previously completed step in a branching flow. Their new input affects step logic and causes an additional step to be added.

• Use a Section message to inform users that a step has been added as soon as branching logic determines one is necessary. This prevents confusion by calling attention to the change in the user’s workflow.

Addressing network errors

In this flow, network or connectivity errors prevent submission. This can happen due to network or server failures when users try to move from one step to the next or submit the form at the end of the flow.

• Use a Banner to notify users that there’s a network error preventing form submission.

Communicating success

Success confirmations give users confidence that they’ve successfully completed a wizard. There are two methods for communicating success: using a flag or navigating to a separate page. Whichever method you select, use it consistently across your experiences.

• Use either a success flag or a success page, not both.
• Include calls to action when applicable, such as a tracking link or button to print responses.
• Reference Feedback and status to learn more about communicating success.
• Reference Messaging for guidance on crafting content within success messages.

Success message

Success messages appear on the page that the user is directed to after exiting a wizard. Use a success flag instead of a success page when there are no follow-up actions required from the user.

• Use a Flag to communicate system- or section-level success messages.

Success page

A success page is a landing page the user is directed to after submission. Use this method to encourage further engagement, such as visiting additional resources or starting a new task.

• Provide a summary within the main content area of the page to communicate what the user completed.
• Use clear calls to action to ensure users can easily navigate to the main site or relevant resources.