Use a multi-step form when a transaction needs several saved pages or sections before a final review and submission.
Use a multi-step form when a transaction needs several saved pages or sections before a final review and submission.
Practice the judgment: Imagine this situation: Back or browser refresh clears answers from earlier steps. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Multi-step form | Single-page form | Single-question page | Step navigation / step indicator |
|---|---|---|---|---|
| UI or UX | UI + UX - Multi-page transaction with saved step state | UI + UX - Short related multi-field submission page | UI + UX - Focused form page for one answer or decision | UI + UX - Linear multistep task progress indicator |
| 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. | Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit. | Render one clear question as the page heading, optional explanatory text before the answer, one answer area, a primary Continue action, and a Back link or equivalent return path. | Show a compact ordered list of named steps near the task heading, with visually distinct completed, current, upcoming, optional, and error states. |
| 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. | Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission. | Use a single-question page when users need to focus on one decision, understand one piece of information, or answer one conceptual question before moving on. | Use step navigation to reduce uncertainty in long linear tasks by showing where users are, what is done, and what remains. |
| Good UI | 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. | A contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end. | A date question uses three related fields on the same page because day, month, and year answer one question. | A five-step application shows Eligibility complete, Contact details current, Documents upcoming, Review upcoming, and Submit upcoming, with the current step emphasized and a matching page heading. |
| Bad UI | A five-screen flow shows all steps as complete after users only viewed them. | A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page. | One page asks for name, address, evidence status, and payment method under a vague Details heading. | All future steps look clickable and complete even though required earlier fields are blank. |
| Good UX | 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 reviews all contact details before submitting because the fields are short, related, and visible in one scan. | A user chooses Yes, sees a follow-up detail field on the same question page, goes Back, returns, and the answer is still selected. | After a user enters valid contact details and continues, Contact details becomes complete and Documents becomes current. |
| Bad UX | A browser refresh on step 3 clears steps 1 and 2, forcing the user to start again. | A validation failure clears completed fields, forcing the user to re-enter unrelated information. | A user goes Back to check the previous step and the question page clears the answer they already gave. | The indicator says Step 4 of 5 while the page content and route still show Step 2. |
| Best fit | A transaction spans several ordered pages or sections. | A compact set of related fields should be reviewed together before one submit. | A sequential service flow needs reliable answers before deciding the next page. | A linear form, application, checkout, or setup flow has three or more meaningful steps. |
| Avoid when | The fields are short, related, and easier to scan together on one page. | The form is long, high-stakes, branched, or too hard to recover from on one page. | Users need to compare or edit several fields together before submitting. | The journey has only one or two screens. |
| Required state | Current step state with heading, saved context, local answer controls, Back, and Continue. | Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action. | Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action. | Default state with completed, current, and upcoming steps. |
| Accessibility burden | Use a clear page heading on every step and keep it synchronized with route and progress context. | Keep field order in the DOM the same as the visible order. | Use a single visible h1 that states the question users are answering. | Use aria-current on the current labeled step and include hidden or visible status text for completed, current, upcoming, optional, and error states. |
| Common misuse | Using a multi-step form to hide a short related form that users should review on one page. | Using one page for a long complex application just to avoid designing steps. | Putting several unrelated questions on one page and still calling it one thing per page. | Using a step indicator as breadcrumbs, tabs, side navigation, or pagination. |