Back to compare picker

Single-question page vs Text input vs Textarea vs Error summary

Prefer a single-question page when one answer or decision deserves a focused screen with heading, hint, answer control, validation, Continue, and Back behavior.

Decision dimensions

Dimension Single-question pageText inputTextareaError summary
UI or UX UI + UX - Focused form page for one answer or decisionUI + UX - Single-line freeform data-entry controlUI + UX - Multi-line freeform writing fieldUI + 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.Use text input for short freeform answers that users can type or paste and that cannot be accurately represented as a fixed option choice.Use textarea when users need to write or paste sentences, paragraphs, explanations, notes, or comments that may wrap across lines.Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI 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 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.Red banner saying fix errors with no links.
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 types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.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 answers three unrelated questions on one screen and submits, but the error only says fix details without naming the question.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 One answer or decision should be read and completed without competing form questions.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.A single local field issue can be corrected before submit without page-level orientation.
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.Neutral form before submit with no summary.
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.Showing a red banner or toast with no links to the invalid answers.

Single-question page

UI or UX
UI + UX - Focused form page for one answer or decision
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.
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.
Good UI
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.
Bad UI
One page asks for name, address, evidence status, and payment method under a vague Details heading.
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.
Bad UX
A user answers three unrelated questions on one screen and submits, but the error only says fix details without naming the question.
Best fit
One answer or decision should be read and completed without competing form questions.
Avoid when
Users need to compare or edit several fields together before submitting.
Required state
Initial unanswered state with question heading, optional explanation, answer control, Back link, and Continue action.
Accessibility burden
Use a single visible h1 that states the question users are answering.
Common misuse
Putting several unrelated questions on one page and still calling it one thing per page.

Text input

UI or UX
UI + UX - Single-line freeform data-entry control
UI guidance
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 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 reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty.
Bad UI
The only instruction is placeholder text that disappears when the user starts typing.
Good UX
A user types or pastes a short reference, submits it, and the interface confirms the stored value without changing their wording.
Bad UX
Validation fires on the first focus event and blocks typing before the user has had a chance to answer.
Best fit
The answer is short and user-authored.
Avoid when
The answer is a paragraph, comment, address block, or explanation requiring multiple lines.
Required state
Empty untouched state with persistent label and optional hint.
Accessibility burden
Associate every text input with a visible label or equivalent accessible name that matches the visible question.
Common misuse
Using placeholder text as the only label or instruction.

Textarea

UI or UX
UI + UX - Multi-line freeform writing field
UI guidance
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.
UX guidance
Use textarea when users need to write or paste sentences, paragraphs, explanations, notes, or comments that may wrap across lines.
Good UI
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.
Bad UI
A paragraph question is squeezed into a single-line input that hides most of the answer.
Good UX
A user writes two paragraphs, sees remaining characters update, submits, and the exact line breaks and wording are preserved.
Bad UX
A user writes a long explanation, hits submit, and the product clears the entire draft after a length error.
Best fit
Users need to write sentences, paragraphs, comments, explanations, notes, or descriptions.
Avoid when
The answer is a short one-line value.
Required state
Empty untouched state with visible label and optional hint.
Accessibility burden
Associate the textarea with a visible label that states the writing prompt.
Common misuse
Using a single-line input for paragraph answers.

Error summary

UI or UX
UI + UX - Form recovery summary
UI guidance
Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.
UX guidance
Help users recover from one or more submitted-form errors without scanning the entire page.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Red banner saying fix errors with no links.
Good UX
After failed submit, focus or reading order makes the summary discoverable before users scan the form.
Bad UX
Only showing errors below the fold.
Best fit
Form submission can produce one or more errors.
Avoid when
A single local field issue can be corrected before submit without page-level orientation.
Required state
Neutral form before submit with no summary.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Showing a red banner or toast with no links to the invalid answers.
Decision rules
  • Prefer a single-question page when one answer or decision deserves a focused screen with heading, hint, answer control, validation, Continue, and Back behavior.
  • Use text input within a single-question page when the answer is short, freeform, and fits on one line.
  • Use textarea within a single-question page when the same focused page asks for a paragraph, explanation, comment, or other multi-line answer.
  • Use an error summary when a submitted question page has one or more errors that need page-level announcement and links back to the invalid control.
  • Do not call every text field a single-question page; the pattern is the page structure, route, heading, progress position, and navigation contract around the answer.
  • Do not split tightly related fields onto separate pages when they answer one conceptual question, such as a date with day, month, and year fields.
  • Prefer a single-page form when users benefit from scanning and editing a short set of low-risk fields together before submitting.
  • Prefer a multi-step form when the journey has sections or tasks, and use single-question pages as individual steps inside that broader flow.
  • Prefer a wizard when the sequence is highly guided, stateful, or branching with strict next-step dependency; do not use wizard chrome for a simple isolated question.
  • Keep Back and Continue behavior predictable: returning to the question restores the answer, while Continue validates only this page's question before moving on.
Inspect live examples
Failure modes
  • A page asks several unrelated questions, so the heading does not tell users what answer is expected.
  • A single text input is mistaken for the pattern while the page has no focused heading, hint, Back, Continue, or recovery state.
  • A simple standalone question is wrapped in wizard navigation that suggests unnecessary progress and future commitments.
  • A question page loses the saved answer after Back, validation, or route changes.
  • Related controls that belong to one answer are split across pages, forcing users to remember context.
  • A submitted error appears only beside the control without any page-level recovery when focus lands at the top.