Multi-Step Forms

Last updated:

Practical patterns for wizards and staged flows that preserve data and validate early.

01 — Foundation

Split forms only when it helps

Multiple steps reduce cognitive load for long flows — or add friction when one page would do.

Multi-step forms break complex tasks into stages — checkout, onboarding, applications. They work when each step has a clear goal. They fail when users lose context, cannot go back safely, or validation hides errors until the end.

GOV.UK services usually use one question per page for long flows, with a task list when users complete several related tasks — see complete multiple tasks. Match that clarity even if your UI uses a different visual pattern.

02 — Structure

One purpose per step

Progress should be honest — users need to know where they are and what is left.

  • label steps plainly — “Shipping”, “Payment”, “Review” — not “Step 2 of 7” alone
  • show progress with text and visual indicator; mark completed steps
  • keep related fields together — do not split one decision across steps for layout
  • prefer a single long form on mobile when steps are trivial 
<nav aria-label="Checkout progress">
    <ol>
        <li aria-current="step">Delivery</li>
        <li>Payment</li>
        <li>Confirm</li>
    </ol>
</nav>

03 — Navigation

Back, next, and save

Users must move forward and backward without losing answers.

  • preserve entered data when going back — server or client persistence
  • validate per step before advancing; show errors next to fields and in an error summary — see accessible forms and GOV.UK validation
  • final step summarises choices before irreversible submit
  • allow save and resume for long applications — see Save States

04 — Accessibility

Accessible multi-step flows

Focus management and step announcements matter more than wizard chrome.

  • move focus to the step heading or error summary on step change — same recovery model as single-page GOV.UK forms
  • do not trap multi-step forms inside small modals — see Modal / Dialog
  • real form elements, labels, and error linking — see Accessible Forms
  • URL or session state so refresh does not wipe progress where possible

05 — Review

Before you approve

A short checklist for multi-step forms in code review.

  • each step has a clear purpose; progress is understandable
  • back/next work; validation is early and specific
  • review step before commit; save/resume for long flows