UX Patterns Guide
Back to compare picker

Validation that clears user input vs Inline validation vs Error summary vs Single-page form vs Autosave recovery vs Error state

Flag validation that clears input when failed validation or recovery destroys safe user-entered values; use inline validation for local correction, error summary for submit recovery, single-page form for preserving related fields, autosave recovery for failed background saves, and error state for broader system failures.

Validation that clears user input live exampleInline validation live exampleError summary live exampleSingle-page form live exampleAutosave recovery live exampleError state live example
Learn the decision

Match the interaction to the person's task

Flag validation that clears input when failed validation or recovery destroys safe user-entered values; use inline validation for local correction, error summary for submit recovery, single-page form for preserving related fields, autosave recovery for failed background saves, and error state for broader system failures.

Validation that clears user input

Use it when: Use this anti-pattern entry to audit forms, editors, imports, checkouts, onboarding flows, and configuration screens where validation can erase recoverable user work.

Make this state clear: Initial typed state with values entered across multiple fields.

Observe the result: A user corrects one mistyped character in a preserved phone number after validation instead of re-entering the full number.

Study the full pattern →

Inline validation

Use it when: A single field has a specific correctable problem.

Make this state clear: Invalid field with preserved user value and adjacent correction text.

Observe the result: Validation appears after blur or submit when it helps correction.

Study the full pattern →

Error summary

Use it when: Form submission can produce one or more errors.

Make this state clear: Failed-submit state with summary visible near the form heading.

Observe the result: After failed submit, focus or reading order makes the summary discoverable before users scan the form.

Study the full pattern →

Single-page form

Use it when: A compact set of related fields should be reviewed together before one submit.

Make this state clear: Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.

Observe the result: A user reviews all contact details before submitting because the fields are short, related, and visible in one scan.

Study the full pattern →

Autosave recovery

Use it when: Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work.

Make this state clear: Clean saved state with current server timestamp.

Observe the result: A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates.

Study the full pattern →

Error state

Use it when: A system or task failure blocks expected content or action.

Make this state clear: Normal expected state before failure.

Observe the result: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.

Study the full pattern →

Practice the judgment: Imagine this situation: A server-side address validation response rebuilds the form from blank defaults. 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 →

Decision dimensions

Dimension Validation that clears user inputInline validationError summarySingle-page formAutosave recoveryError state
UI or UX UI + UX - Anti-pattern where validation or failed submission destroys recoverable user-entered valuesUI + UX - Field-level validation feedbackUI + UX - Form recovery summaryUI + UX - Short related multi-field submission pageUI + UX - Recovery surface for failed or uncertain background savesUI + UX - Recoverable failure surface
UI guidance Keep the failing value visible and editable beside a precise field error, and preserve valid sibling fields, uploaded file names, selected options, text area drafts, and formatted/raw values unless policy explicitly requires clearing a sensitive secret.Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.Render a top-of-form summary block with heading, linked error list, and matching field-level error messages.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.Keep the user's latest local value visible or copyable until recovery succeeds, and distinguish Retry save, Keep local copy, Restore last saved, Compare versions, Download copy, and Continue after recovery.Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance Treat value preservation as part of validation: every client rule, server rule, formatter, retry, reload, session return, and masked input path must either preserve the value or explain a narrow, policy-backed exception.Help the person reach a clear task outcome.Move users from the summary to the exact field, group, or first invalid control that needs correction.Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy.Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI.
Good UI A failed email validation keeps maya@@example visible, shows Enter an email address in the correct format, and leaves the phone and message fields intact.Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.Top-of-form summary with a clear heading, linked error list, and matching inline field messages.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 claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved.A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation.
Bad UI A checkout form fails cardholder-name validation and reloads with every shipping field blank.Error message appears far from the field it describes.Summary and field messages visually disconnected or contradictory.A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.The app clears the field after a failed autosave and offers only Reload page.Tiny transient toast for a blocking failure.
Good UX A user corrects one mistyped character in a preserved phone number after validation instead of re-entering the full number.Validation appears after blur or submit when it helps correction.After failed submit, focus or reading order makes the summary discoverable before users scan the form.A user reviews all contact details before submitting because the fields are short, related, and visible in one scan.A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates.User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX A user uploads evidence, enters long notes, hits Submit, and loses the notes because one date was invalid.Showing errors before users type.Only showing errors below the fold.A validation failure clears completed fields, forcing the user to re-enter unrelated information.A stale saved timestamp hides that the latest answer failed after the timestamp.Clearing work after save failure.
Best fit Use this anti-pattern entry to audit forms, editors, imports, checkouts, onboarding flows, and configuration screens where validation can erase recoverable user work.A single field has a specific correctable problem.Form submission can produce one or more errors.A compact set of related fields should be reviewed together before one submit.Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work.A system or task failure blocks expected content or action.
Avoid when Choose another interaction when the task calls for a different route.The main recovery task is finding several errors across a submitted page.The message is a system failure, permission problem, or outage rather than a validation issue.The form is long, high-stakes, branched, or too hard to recover from on one page.The work is a durable draft object with list-level resume, publish, and discard lifecycle.Nothing exists yet and the state is expected.
Required state Initial typed state with values entered across multiple fields.Invalid field with preserved user value and adjacent correction text.Failed-submit state with summary visible near the form heading.Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.Clean saved state with current server timestamp.Normal expected state before failure.
Accessibility burden Preserved values must remain in their controls so screen reader and keyboard users can edit them in place.Expose invalid state on the input and connect error text to the field description where possible.Use a heading and alert behavior that makes the summary discoverable.Keep field order in the DOM the same as the visible order.Place recovery controls in reading order near the affected field, section, or submit action.Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse Calling form reset after submit regardless of success or failure.Showing field errors before users have interacted with the control.Replacing field-level messages with only a top-level summary.Using one page for a long complex application just to avoid designing steps.Leaving a green Saved label visible after a failed or stale autosave.Using a transient toast for critical errors.

Validation that clears user input

UI or UX
UI + UX - Anti-pattern where validation or failed submission destroys recoverable user-entered values
UI guidance
Keep the failing value visible and editable beside a precise field error, and preserve valid sibling fields, uploaded file names, selected options, text area drafts, and formatted/raw values unless policy explicitly requires clearing a sensitive secret.
UX guidance
Treat value preservation as part of validation: every client rule, server rule, formatter, retry, reload, session return, and masked input path must either preserve the value or explain a narrow, policy-backed exception.
Good UI
A failed email validation keeps maya@@example visible, shows Enter an email address in the correct format, and leaves the phone and message fields intact.
Bad UI
A checkout form fails cardholder-name validation and reloads with every shipping field blank.
Good UX
A user corrects one mistyped character in a preserved phone number after validation instead of re-entering the full number.
Bad UX
A user uploads evidence, enters long notes, hits Submit, and loses the notes because one date was invalid.
Best fit
Use this anti-pattern entry to audit forms, editors, imports, checkouts, onboarding flows, and configuration screens where validation can erase recoverable user work.
Avoid when
Choose another interaction when the task calls for a different route.
Required state
Initial typed state with values entered across multiple fields.
Accessibility burden
Preserved values must remain in their controls so screen reader and keyboard users can edit them in place.
Common misuse
Calling form reset after submit regardless of success or failure.

Inline validation

UI or UX
UI + UX - Field-level validation feedback
UI guidance
Render a labeled field with hint text, field-adjacent error text, invalid styling, preserved value, and corrected state.
UX guidance
Help the person reach a clear task outcome.
Good UI
Error text appears next to the field with readable spacing, persistent label, hint text, and the invalid value still visible.
Bad UI
Error message appears far from the field it describes.
Good UX
Validation appears after blur or submit when it helps correction.
Bad UX
Showing errors before users type.
Best fit
A single field has a specific correctable problem.
Avoid when
The main recovery task is finding several errors across a submitted page.
Required state
Invalid field with preserved user value and adjacent correction text.
Accessibility burden
Expose invalid state on the input and connect error text to the field description where possible.
Common misuse
Showing field errors before users have interacted with the control.

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
Move users from the summary to the exact field, group, or first invalid control that needs correction.
Good UI
Top-of-form summary with a clear heading, linked error list, and matching inline field messages.
Bad UI
Summary and field messages visually disconnected or contradictory.
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
The message is a system failure, permission problem, or outage rather than a validation issue.
Required state
Failed-submit state with summary visible near the form heading.
Accessibility burden
Use a heading and alert behavior that makes the summary discoverable.
Common misuse
Replacing field-level messages with only a top-level summary.

Single-page form

UI or UX
UI + UX - Short related multi-field submission page
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.
UX guidance
Use a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission.
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.
Bad UI
A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page.
Good UX
A user reviews all contact details before submitting because the fields are short, related, and visible in one scan.
Bad UX
A validation failure clears completed fields, forcing the user to re-enter unrelated information.
Best fit
A compact set of related fields should be reviewed together before one submit.
Avoid when
The form is long, high-stakes, branched, or too hard to recover from on one page.
Required state
Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action.
Accessibility burden
Keep field order in the DOM the same as the visible order.
Common misuse
Using one page for a long complex application just to avoid designing steps.

Autosave recovery

UI or UX
UI + UX - Recovery surface for failed or uncertain background saves
UI guidance
Keep the user's latest local value visible or copyable until recovery succeeds, and distinguish Retry save, Keep local copy, Restore last saved, Compare versions, Download copy, and Continue after recovery.
UX guidance
Use autosave recovery when users need to preserve effort after background saving fails, stalls, conflicts, expires, or only stores a local copy.
Good UI
A claim form says Household income answer failed to autosave at 10:42, keeps the typed answer visible, and offers Retry save, Copy answer, Restore last saved, and Continue after saved.
Bad UI
The app clears the field after a failed autosave and offers only Reload page.
Good UX
A user loses network while writing a long answer, sees it is saved on this device only, reconnects, retries the same value, and continues after the timestamp updates.
Bad UX
A stale saved timestamp hides that the latest answer failed after the timestamp.
Best fit
Autosave failed, stalled, expired, or became uncertain while users still have meaningful local work.
Avoid when
The work is a durable draft object with list-level resume, publish, and discard lifecycle.
Required state
Clean saved state with current server timestamp.
Accessibility burden
Place recovery controls in reading order near the affected field, section, or submit action.
Common misuse
Leaving a green Saved label visible after a failed or stale autosave.

Error state

UI or UX
UI + UX - Recoverable failure surface
UI guidance
Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance
Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI.
Good UI
A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation.
Bad UI
Tiny transient toast for a blocking failure.
Good UX
User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX
Clearing work after save failure.
Best fit
A system or task failure blocks expected content or action.
Avoid when
Nothing exists yet and the state is expected.
Required state
Normal expected state before failure.
Accessibility burden
Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse
Using a transient toast for critical errors.
Decision rules
  • Choose the validation-clears-input anti-pattern when client validation, server validation, failed submit, formatter rejection, retry, reload, or reauthentication erases safe user-entered values.
  • Choose the validation-clears-input anti-pattern when a failed field clears valid sibling fields, long text, uploaded file names, selected options, pasted raw values, or local draft state.
  • Choose inline validation when one field has a correctable problem and the typed value remains visible and editable beside the field message.
  • Choose error summary when users need a linked overview after submit; the summary should route to preserved field values, not blank rebuilt controls.
  • Choose single-page form when several related values are submitted together and validation must preserve all safe values across the page.
  • Choose autosave recovery when background save failure or ambiguity means the newest local value needs retry, copy, restore, or compare controls before it can be trusted.
  • Choose error state when a system, network, save, sync, or load failure blocks progress and users need persistent recovery while their context is preserved.
  • Use password-input or payment-field security rules only for narrow sensitive values; do not generalize those rules to ordinary text, address, date, phone, textarea, or selection fields.
  • Do not silently normalize by deleting user input; preserve raw input, show the interpreted value, or ask for correction.
  • Reset, Clear form, Cancel, Discard, and Start over are deliberate actions and must not be triggered as a side effect of validation.
  • After server validation, rehydrate submitted values before focusing the error summary or first invalid field; do not rebuild the page from blank defaults.
  • If policy clears a sensitive value, keep non-sensitive values intact and explain which field was cleared and why.
Inspect live examples
Validation that clears user inputInline validationError summarySingle-page formAutosave recoveryError state
Failure modes
  • A failed email check clears the email field, so the user cannot correct one mistyped character.
  • A server-side address validation response rebuilds the form from blank defaults.
  • A formatter rejects a pasted phone number and deletes the raw pasted value.
  • A textarea length error removes the entire long answer.
  • One invalid uploaded file clears every selected valid file.
  • Session expiry returns users to a blank form after reauthentication.
  • A retry action sends empty values because the failed local payload was discarded.
  • Password-clearing behavior is applied to non-secret profile, checkout, or application fields.

Saved items