UX Patterns Guide
UI + UX Input And Data Entry standard

Multi-step form

Split the transaction into ordered saved steps with focused pages, clear progress context, validation before advancement, answer preservation, review and change behavior, and explicit handling for conditional or stale downstream answers.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A transaction spans several ordered pages or sections.
  • Users need saved progress and manageable recovery across a longer task.
  • Later questions, documents, payment, or routing depend on earlier answers.
  • A review step is needed before final submission.

Avoid when

  • The fields are short, related, and easier to scan together on one page.
  • The task can be completed in any order and needs a task list rather than a linear form.
  • The number of steps changes so much that progress indicators become misleading.
  • The system cannot preserve answers across Back, refresh, validation, or server errors.

Problem it prevents

Long or conditional transactions become overwhelming, fragile, and error-prone when all fields are shown at once or when page-by-page flows fail to save progress, validate prerequisites, or let users review changes before final submission.

Pattern anatomy

What a strong implementation has to make clear

User need

The task has enough questions, sections, dependencies, or risk that one page would be hard to scan or recover from.

Pattern promise

Split the transaction into ordered saved steps with focused pages, clear progress context, validation before advancement, answer preservation, review and change behavior, and explicit handling for conditional or stale downstream answers.

Required state

Not-started state with clear start point and expectation of the steps or sections ahead.

Recovery path

Saved progress is local-only and disappears after refresh or server validation.

Access contract

Use a clear page heading on every step and keep it synchronized with route and progress context.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A benefit application has Eligibility, Contact details, Documents, Review, and Submit pages, with the current step named in the heading and completed steps shown from saved data.
  • The review page groups captured answers with Change links that return to the right step and then back to review.
  • A user completes eligibility and contact details, goes Back from documents, sees contact details still filled, continues, and returns to the same documents step.
  • A user changes an eligibility answer on review, the documents step is marked needs review, and final submit is blocked until stale evidence is checked.
Weak implementation

Vague, hidden, hard to recover from

  • A five-screen flow shows all steps as complete after users only viewed them.
  • A stepper strip is shown without page headings, Back behavior, saved answers, or a final review before submission.
  • A user changes an early answer and the form silently submits later answers that no longer apply.
  • A browser refresh on step 3 clears steps 1 and 2, forcing the user to start again.
UI guidance
  • Render each step as a focused page with a clear heading, progress context when useful, Back and Continue controls, local validation, and a final review page before submission.
  • Show step status honestly: current, complete, locked, optional, stale, error, and review states must match saved form data rather than page visits.
UX guidance
  • Use a multi-step form when a transaction is too long, conditional, high-stakes, or hard to recover from as one page, and users need manageable saved progress.
  • Persist answers at each step, let users return and change them without repeating the whole transaction, and recompute later steps when earlier answers alter eligibility or required evidence.
Implementation contract

What the implementation must handle

States

  • Not-started state with clear start point and expectation of the steps or sections ahead.
  • Current step state with heading, saved context, local answer controls, Back, and Continue.
  • Completed step state based on saved valid data.
  • Locked future step state before prerequisites are complete.

Interaction

  • Continue validates and saves the current step before unlocking the next required step.
  • Back returns to the previous step without clearing the current or previous answers.
  • Browser refresh, browser Back, service Back, and review Change links restore the correct page with pre-populated data.
  • Completed status means the step's required answers are saved and still compatible with upstream answers.

Accessibility

  • Use a clear page heading on every step and keep it synchronized with route and progress context.
  • Move focus to the step heading, error summary, or first invalid field after navigation and validation.
  • Use aria-current or equivalent only for the current progress item when a step indicator is present.
  • Provide text status for completed, current, locked, optional, error, and stale steps without relying on color alone.

Review

  • What makes each step complete, and is that based on saved valid data?
  • Can users go Back, refresh, and return from review without losing answers?
  • Are the steps stable enough for visible progress, or does conditional logic need another representation?
  • Which downstream steps become stale when each upstream answer changes?
Interactive lab

Inspect the states before you copy the pattern

Complete a saved multi-step form

Move through steps, validate prerequisites, go Back, review answers, change an earlier answer, and inspect stale downstream state.

Multi-step form
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Not-started state with clear start point and expectation of the steps or sections ahead.

Keyboard / Access

Tab order starts at the step page content and reaches answer controls, Back, Continue, and any progress links in a predictable order.

Avoid Generating

Using a multi-step form to hide a short related form that users should review on one page.
Evidence trail

Source-backed claims behind this guidance

GOV.UK Service Manual: Structuring forms

Government Digital Service - checked

GOV.UK form-structure guidance supports splitting forms across pages, one thing per page, saving as users go, and branching or loops.

USWDS Step indicator

U.S. Web Design System - checked

USWDS step-indicator guidance supports progress display for linear multi-page forms with three or more high-level steps.

Full agent/debug reference

Problem Context

  • The task has enough questions, sections, dependencies, or risk that one page would be hard to scan or recover from.
  • Users may need to complete the transaction on mobile, leave and return, or change earlier answers after seeing a review page.
  • Later steps may depend on earlier answers, such as eligibility, document requirements, payment amount, or routing.

Selection Rules

  • Choose a multi-step form when the transaction has several ordered pages or sections that need saved progress.
  • Prefer single-page form when fields are compact, related, low branching, and best reviewed together before one submit.
  • Use single-question pages as individual steps when one answer deserves a focused page inside the larger transaction.
  • Use a step indicator only when three or more stable high-level steps benefit from progress visibility.
  • Include a review step when users need to confirm captured answers before final submission.
  • Persist each step before moving forward and preserve values when users go Back, refresh, or return from review.
  • Validate prerequisites before unlocking later steps or explain why a future step is unavailable.
  • When earlier answers change, mark affected later steps stale or incomplete before final submission.

Required States

  • Not-started state with clear start point and expectation of the steps or sections ahead.
  • Current step state with heading, saved context, local answer controls, Back, and Continue.
  • Completed step state based on saved valid data.
  • Locked future step state before prerequisites are complete.
  • Validation error state that keeps the user on the current step with answers preserved.
  • Back-return state that restores previous answers and the correct step route.
  • Review state with sectioned answers and Change links.
  • Stale downstream state when an earlier answer changes what later steps require.
  • Final submitted state only after review and required steps are complete.

Interaction Contract

  • Continue validates and saves the current step before unlocking the next required step.
  • Back returns to the previous step without clearing the current or previous answers.
  • Browser refresh, browser Back, service Back, and review Change links restore the correct page with pre-populated data.
  • Completed status means the step's required answers are saved and still compatible with upstream answers.
  • Changing an upstream answer recomputes downstream requirements and marks affected steps incomplete or stale.
  • Review Change links return users to the changed step and then back to review without forcing them through unrelated steps.

Implementation Checklist

  • Define stable step IDs, route ownership, prerequisites, completion rules, optionality, and downstream dependencies before designing screens.
  • Keep each step focused on one question or one coherent group of related fields.
  • Save step data before route transitions and restore it after Back, refresh, validation, and server errors.
  • Use a visible step indicator only when there are at least three stable high-level steps and progress visibility reduces uncertainty.
  • Add a check-answers or review step before final submission for medium or high-risk transactions.
  • Implement Change links that return to the exact step with pre-populated values and route users back to review when appropriate.
  • Invalidate or revalidate downstream steps when earlier answers change requirements.
  • Test keyboard flow, focus on route changes, screen reader step announcements, mobile Back behavior, refresh recovery, server validation, and stale-answer paths.

Common Generated-UI Mistakes

  • Using a multi-step form to hide a short related form that users should review on one page.
  • Treating a step indicator as the form lifecycle instead of modelling saved step data.
  • Marking a step complete after visit rather than after validation and save.
  • Letting users skip required future steps with no prerequisite check.
  • Changing the number of visible steps in a way that makes progress counts dishonest.
  • Clearing previous answers when users go Back or refresh.
  • Review Change links that force users through every later step again.
  • Submitting stale downstream answers after an earlier answer changes.

Critique Questions

  • What makes each step complete, and is that based on saved valid data?
  • Can users go Back, refresh, and return from review without losing answers?
  • Are the steps stable enough for visible progress, or does conditional logic need another representation?
  • Which downstream steps become stale when each upstream answer changes?
  • Does the review step let users change answers without repeating unrelated steps?
  • Would this be simpler and safer as one single-page form?
Accessibility
  • Use a clear page heading on every step and keep it synchronized with route and progress context.
  • Move focus to the step heading, error summary, or first invalid field after navigation and validation.
  • Use aria-current or equivalent only for the current progress item when a step indicator is present.
  • Provide text status for completed, current, locked, optional, error, and stale steps without relying on color alone.
  • Keep Back, Continue, review Change links, and final submit in predictable keyboard order.
  • Pre-populate returned steps so screen reader and keyboard users do not have to reconstruct prior answers.
Keyboard Behavior
  • Tab order starts at the step page content and reaches answer controls, Back, Continue, and any progress links in a predictable order.
  • Back and Continue are explicit buttons or links and do not depend on hidden keyboard shortcuts.
  • After Continue, focus moves to the next step heading or to validation errors on the current step.
  • Review Change links move to the selected step and preserve route context for returning to review.
  • Interactive progress items, if offered, only focus completed or available steps and explain locked future steps.
  • Browser Back restores the expected previous step without duplicate submit or data loss.
Variants
  • Linear multi-step form
  • Question-page sequence
  • Sectioned application form
  • Checkout flow
  • Multi-step form with review page
  • Multi-step form with optional steps
  • Multi-step form with conditional branches
  • Multi-step form with save and return
  • Multi-step form with stale downstream answers

Verification

Last verified: