| 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. | Help users recover from one or more submitted-form errors without scanning the entire page. | Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice. |
| 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 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. | 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. | Red banner saying fix errors with no links. | The only instruction is placeholder text that disappears when the user starts typing. |
| Good UX | 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 failed submit, focus or reading order makes the summary discoverable before users scan the form. | A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording. |
| Bad UX | 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. | 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. | One answer or decision should be read and completed without competing form questions. | 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. | A single local field issue can be corrected before submit without page-level orientation. | 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. | Neutral form before submit with no summary. | 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. | Showing a red banner or toast with no links to the invalid answers. | Using placeholder text as the only label or instruction. |