Use a single-page form when a short related set of fields should be scanned, edited, validated, and submitted together on one route.
Use a single-page form when a short related set of fields should be scanned, edited, validated, and submitted together on one route.
Practice the judgment: Imagine this situation: A long complex application is dumped on one page, causing scrolling, hidden errors, and abandoned work. 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 | Single-page form | Single-question page | Error summary | Text input |
|---|---|---|---|---|
| UI or UX | UI + UX - Short related multi-field submission page | UI + UX - Focused form page for one answer or decision | UI + UX - Form recovery summary | UI + UX - Single-line freeform data-entry control |
| UI guidance | 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. | Render a top-of-form summary block with heading, linked error list, and matching field-level error messages. | Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field. |
| UX guidance | 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. | Move users from the summary to the exact field, group, or first invalid control that needs correction. | Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text. |
| Good UI | 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. | Top-of-form summary with a clear heading, linked error list, and matching inline field messages. | A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty. |
| Bad UI | 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. | Summary and field messages visually disconnected or contradictory. | The only instruction is placeholder text that disappears when the user starts typing. |
| Good UX | 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 failed submit, focus or reading order makes the summary discoverable before users scan the form. | A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error. |
| Bad UX | 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. | Only showing errors below the fold. | Validation fires on the first focus event and blocks typing before the user has had a chance to answer. |
| Best fit | 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. | Form submission can produce one or more errors. | The answer is short and user-authored. |
| Avoid when | 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 message is a system failure, permission problem, or outage rather than a validation issue. | The answer is a paragraph, comment, address block, or explanation requiring multiple lines. |
| Required state | 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. | Failed-submit state with summary visible near the form heading. | Empty untouched state with persistent label and optional hint. |
| Accessibility burden | 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 a heading and alert behavior that makes the summary discoverable. | Associate every text input with a visible label or equivalent accessible name that matches the visible question. |
| Common misuse | 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. | Replacing field-level messages with only a top-level summary. | Using placeholder text as the only label or instruction. |