| 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 page heading asks Do you have evidence to upload?, explanatory text sits above a yes/no radio group, Continue follows the answer, and Back returns to the previous service step. | 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. | A two-page form adds a large stepper that consumes space without explaining meaningful progress. |
| 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 edits email and phone together, submits, sees two linked errors, fixes both without losing the preference selection, and saves the whole form once. | 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 user changes an early answer and the form silently submits later answers that no longer apply. | A user submits a mixed form, sees a generic red banner, scrolls through many unrelated fields, and cannot find which answers failed. | A user answers three unrelated questions on one screen and submits, but the error only says fix details without naming the question. | Clicking Review skips Documents, clears the contact form, and then blocks final submission without explaining the skipped prerequisite. |
| Best fit | A transaction spans several ordered pages or sections. | A compact set of related fields should be reviewed together before one submit. | One answer or decision should be read and completed without competing form questions. | 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 | Not-started state with clear start point and expectation of the steps or sections ahead. | 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. |