Use a single-question page to structure one decision or answer per screen, text input or textarea for the field itself, and error summary for recovery after submission errors.
Use a single-question page to structure one decision or answer per screen, text input or textarea for the field itself, and error summary for recovery after submission errors.
Practice the judgment: Imagine this situation: A simple standalone question is wrapped in wizard navigation that suggests unnecessary progress and future commitments. 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-question page | Text input | Textarea | Error summary |
|---|---|---|---|---|
| UI or UX | UI + UX - Focused form page for one answer or decision | UI + UX - Single-line freeform data-entry control | UI + UX - Multi-line freeform writing field | UI + UX - Form recovery summary |
| UI guidance | 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 persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field. | Render a persistent label, enough visible rows for the expected answer, optional hint, readable multiline text, visible focus state, and nearby error or count text associated with the textarea. | Render a top-of-form summary block with heading, linked error list, and matching field-level error messages. |
| UX guidance | 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. | 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. | Use textarea when users need to write or paste sentences, paragraphs, explanations, notes, or comments that may wrap across lines. | Move users from the summary to the exact field, group, or first invalid control that needs correction. |
| Good UI | A date question uses three related fields on the same page because day, month, and year answer one question. | A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty. | A more-detail field has a visible question, sensitive-data hint, five visible rows, wrapping text, remaining-character count, and an error directly above the textarea when needed. | Top-of-form summary with a clear heading, linked error list, and matching inline field messages. |
| Bad UI | One page asks for name, address, evidence status, and payment method under a vague Details heading. | The only instruction is placeholder text that disappears when the user starts typing. | A paragraph question is squeezed into a single-line input that hides most of the answer. | Summary and field messages visually disconnected or contradictory. |
| Good UX | A user chooses Yes, sees a follow-up detail field on the same question page, goes Back, returns, and the answer is still selected. | 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. | A user writes two paragraphs, sees remaining characters update, submits, and the exact line breaks and wording are preserved. | After failed submit, focus or reading order makes the summary discoverable before users scan the form. |
| Bad UX | A user goes Back to check the previous step and the question page clears the answer they already gave. | Validation fires on the first focus event and blocks typing before the user has had a chance to answer. | A user writes a long explanation, hits submit, and the product clears the entire draft after a length error. | Only showing errors below the fold. |
| Best fit | A sequential service flow needs reliable answers before deciding the next page. | The answer is short and user-authored. | Users need to write sentences, paragraphs, comments, explanations, notes, or descriptions. | Form submission can produce one or more errors. |
| Avoid when | Users need to compare or edit several fields together before submitting. | The answer is a paragraph, comment, address block, or explanation requiring multiple lines. | The answer is a short one-line value. | The message is a system failure, permission problem, or outage rather than a validation issue. |
| Required state | Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action. | Empty untouched state with persistent label and optional hint. | Empty untouched state with visible label and optional hint. | Failed-submit state with summary visible near the form heading. |
| Accessibility burden | Use a single visible h1 that states the question users are answering. | Associate every text input with a visible label or equivalent accessible name that matches the visible question. | Associate the textarea with a visible label that states the writing prompt. | Use a heading and alert behavior that makes the summary discoverable. |
| Common misuse | Putting several unrelated questions on one page and still calling it one thing per page. | Using placeholder text as the only label or instruction. | Using a single-line input for paragraph answers. | Replacing field-level messages with only a top-level summary. |