Warning text

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?