UX Patterns Guide
UI + UX Feedback, Status, And System State standard

Warning text

Place concise warning text immediately before the related action or instruction, include warning wording and a non-color cue, state the specific consequence in plain language, and escalate only when the consequence requires a stronger interaction contract.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A user must understand a serious consequence before taking or skipping an action.
  • The warning can be stated as one concise consequence sentence near the relevant control.
  • The consequence is known before the user acts and should shape the user's decision.

Avoid when

  • The message is a dynamic task status that must be announced when it appears.
  • The message is local feedback for a visible object or section.
  • The user has already submitted invalid data and needs links to corrections.
  • The whole product, service, site, or account is affected.
  • The action cannot proceed until the user explicitly confirms a high-consequence decision.

Problem it prevents

Users may continue through a form, declaration, or risky action without noticing a severe consequence, especially when the consequence is written as ordinary hint text, a vague severity label, or a message that appears only after the decision.

Pattern anatomy

What a strong implementation has to make clear

User need

A user action or lack of action can cause a fine, legal obligation, eligibility change, permanent data loss, missed deadline, security exposure, or similar high consequence.

Pattern promise

Place concise warning text immediately before the related action or instruction, include warning wording and a non-color cue, state the specific consequence in plain language, and escalate only when the consequence requires a stronger interaction contract.

Required state

No-warning state where the action has no severe consequence.

Recovery path

Users incur a penalty because the warning looked like ordinary hint text.

Access contract

Do not rely on color alone; include visible or programmatic warning wording and a non-color cue such as an icon.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Before Submit declaration, a warning with an exclamation icon says the user may be fined if they provide false information.
  • Before deleting an export archive, warning text says the files cannot be recovered after deletion and links to retention rules.
  • Users see the fine or eligibility consequence before checking the declaration and can pause to verify their answer.
  • An irreversible delete warning escalates to confirmation only when the user starts the destructive action.
Weak implementation

Vague, hidden, hard to recover from

  • A red sentence says Important below the submit button after the user has already acted.
  • A warning icon appears beside every hint on the page, making the real legal warning indistinguishable.
  • A benefit-loss warning appears only after submission, so users cannot change the decision it warns about.
  • A validation error is written as warning text with no link to the field that needs correction.
UI guidance
  • Render warning text as a short high-emphasis statement with a warning icon, visible or hidden warning label, and explicit consequence copy placed before the relevant action, declaration, or instruction.
  • Keep warning text compact and rare; if the message needs actions, live updates, field links, or long recovery detail, move it to alert, inline message, error summary, confirmation dialog, or a dedicated help surface.
UX guidance
  • Use warning text when users must understand a serious consequence before acting or failing to act, such as a fine, loss of access, permanent deletion, eligibility impact, or legal responsibility.
  • Phrase the warning around the user's decision and consequence, not the system's severity label, so users can change course before the risky outcome happens.
Implementation contract

What the implementation must handle

States

  • No-warning state where the action has no severe consequence.
  • Before-action warning state placed immediately before the related control or declaration.
  • Legal, financial, eligibility, deletion, or security consequence variant with specific consequence copy.
  • Accessible icon state where warning meaning survives color loss and assistive technology output.

Interaction

  • The warning appears in the reading order before the action or answer it qualifies.
  • The first word or accessible label identifies the content as a warning before the consequence sentence.
  • The warning names the consequence and the condition that triggers it, not only a severity word.
  • The warning does not steal focus, open a modal, or interrupt typing by itself.

Accessibility

  • Do not rely on color alone; include visible or programmatic warning wording and a non-color cue such as an icon.
  • Keep the warning in reading order before the control, declaration, or instruction it qualifies.
  • Mark decorative warning icons as hidden and provide warning fallback text in the text stream or accessible label.
  • Avoid assertive live-region semantics for static page-load warning text; use alert only when the warning appears dynamically and urgency requires announcement.

Review

  • What exact action or omission triggers the consequence?
  • Can users see the warning before they reach the related action?
  • Does the sentence say what happens to the user if they continue or fail to continue?
  • Would the message be more honest as an alert, inline message, error summary, notification banner, or confirmation dialog?
Interactive lab

Inspect the states before you copy the pattern

Warn before a severe consequence

Switch warning consequence, place it before the risky action, reveal accessible warning wording, try irreversible deletion, and compare color-only or after-action misuse.

Warning text
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

No-warning state where the action has no severe consequence.

Keyboard / Access

Static warning text is read before keyboard users reach the related action in normal tab and reading order.

Avoid Generating

Using warning text for routine hints, explanations, or mild reminders.
Evidence trail

Source-backed claims behind this guidance

Full agent/debug reference

Problem Context

  • A user action or lack of action can cause a fine, legal obligation, eligibility change, permanent data loss, missed deadline, security exposure, or similar high consequence.
  • The warning is known before the user acts and should shape the user's decision rather than report a system status after the fact.
  • The message can be understood in one short statement without needing a recovery workflow, list of field links, live update, or modal answer.
  • The interface already has a nearby action, declaration, checkbox, instruction, or task step that the warning qualifies.

Selection Rules

  • Choose warning text when one severe consequence needs to be noticed before the user acts or fails to act.
  • Place the warning before the related button, declaration, checkbox, instruction, or risky form section, not after the action.
  • Use explicit consequence wording such as may be fined, cannot be recovered, application will be cancelled, or access will be removed.
  • Use an icon and warning label or fallback wording so the warning is not communicated by color alone.
  • Use alert instead when a dynamic current-task condition appears and must be announced immediately.
  • Use inline message instead when the warning belongs to one visible row, card, field group, or section condition that may resolve locally.
  • Use error summary instead when the warning is really a submitted-form validation failure that needs links to invalid answers.
  • Use confirmation dialog instead when policy or risk requires the user to explicitly choose before the high-consequence action proceeds.

Required States

  • No-warning state where the action has no severe consequence.
  • Before-action warning state placed immediately before the related control or declaration.
  • Legal, financial, eligibility, deletion, or security consequence variant with specific consequence copy.
  • Accessible icon state where warning meaning survives color loss and assistive technology output.
  • Resolved or reduced-risk state where the warning disappears or downgrades when the consequence no longer applies.
  • Escalated state where irreversible action moves from warning text into a confirmation dialog.
  • Misuse state where validation, dynamic status, or broad service messaging is routed to a more appropriate pattern.

Interaction Contract

  • The warning appears in the reading order before the action or answer it qualifies.
  • The first word or accessible label identifies the content as a warning before the consequence sentence.
  • The warning names the consequence and the condition that triggers it, not only a severity word.
  • The warning does not steal focus, open a modal, or interrupt typing by itself.
  • If the user changes the answer so the consequence no longer applies, the warning updates or is removed.
  • If the user proceeds toward an irreversible action, the next step may be a confirmation dialog with the same consequence restated.
  • The warning is not used as the only route to recover from errors after submit.

Implementation Checklist

  • Identify the exact action or omission that creates the severe consequence before choosing warning text.
  • Write one sentence that names the user-facing consequence and triggering condition in plain language.
  • Place the warning directly before the relevant control, declaration, checkbox, instruction, or task step.
  • Include a warning icon and warning label or fallback text; do not rely on red or yellow styling alone.
  • Limit the page to the warnings that genuinely change user risk; avoid decorating ordinary help or hints as warnings.
  • Route dynamic status changes to alert or status semantics and submitted-form failures to error summary with field messages.
  • Escalate irreversible or high-cost actions to confirmation when users must actively consent before proceeding.
  • Test warning placement, zoom, screen-reader reading order, icon fallback wording, color-independent meaning, and resolved-state behavior.

Common Generated-UI Mistakes

  • Using warning text for routine hints, explanations, or mild reminders.
  • Placing the warning after the action it is supposed to qualify.
  • Writing only Warning or Important without a specific consequence.
  • Using red or yellow text as the only warning signal.
  • Replacing an error summary or field error with warning text after submit.
  • Using warning text for live outage, session, or connection status that needs alert semantics.
  • Showing so many warnings that users cannot tell which consequence matters.

Critique Questions

  • What exact action or omission triggers the consequence?
  • Can users see the warning before they reach the related action?
  • Does the sentence say what happens to the user if they continue or fail to continue?
  • Would the message be more honest as an alert, inline message, error summary, notification banner, or confirmation dialog?
  • Is warning meaning available without color, and does assistive technology hear the warning label before the consequence?
  • What event removes, downgrades, or escalates this warning?
Accessibility
  • Do not rely on color alone; include visible or programmatic warning wording and a non-color cue such as an icon.
  • Keep the warning in reading order before the control, declaration, or instruction it qualifies.
  • Mark decorative warning icons as hidden and provide warning fallback text in the text stream or accessible label.
  • Avoid assertive live-region semantics for static page-load warning text; use alert only when the warning appears dynamically and urgency requires announcement.
  • Use plain language and avoid legal jargon unless the legal term itself is required.
  • Ensure text wraps without separating the warning label, icon, consequence, and related action.
Keyboard Behavior
  • Static warning text is read before keyboard users reach the related action in normal tab and reading order.
  • The warning itself does not receive focus unless it contains a link or disclosure control.
  • Any link inside the warning has a specific label such as View retention rules rather than Learn more.
  • If the warning escalates to confirmation, focus follows the confirmation dialog's opening and return-focus contract.
  • Removing the warning after a safer option is selected does not move focus unexpectedly.
Variants
  • Legal consequence warning
  • Financial penalty warning
  • Eligibility warning
  • Permanent deletion warning
  • Declaration warning
  • Security exposure warning
  • Deadline consequence warning

Verification

Last verified: