Alert

Problem Context

• A system, validation, connection, security, payment, save, or submission condition affects the user's current task now.
• The message is more urgent than routine status but does not require the user to answer a modal decision.
• The affected scope is the current page, workspace, step, or task flow rather than one table row, one input value, or the whole product.
• Users can understand the situation from a short title and body, with optional detail routed elsewhere.

Selection Rules

• Choose alert when a time-sensitive warning, error, or important status change must be noticed immediately without moving focus.
• Use inline message instead when the message belongs directly beside one visible object, row, card, panel, or form section.
• Use toast notification instead when the message can expire safely and does not need to remain in the task layout.
• Use confirmation dialog instead when the user must explicitly choose before a consequential action proceeds.
• Use error state instead when an expected content region failed and needs retry, fallback, support, or preserved-task recovery.
• Use banner or site alert instead when the message applies across the product, service, account, or multiple pages.
• Use role alert only for dynamically updated urgent text, and use status or region for less urgent messages.
• Allow dismissal only when the underlying condition is resolved, recoverable elsewhere, or purely informational.

Required States

• No-alert state with the task operating normally.
• Urgent warning or error alert that appears dynamically and is announced without taking focus.
• Advisory or success state that uses calmer status semantics rather than assertive alert semantics.
• Actionable alert with one direct next step such as Save draft, Renew session, Retry sync, or Update payment.
• Detail-revealed state for a short consequence explanation without expanding into a full recovery workflow.
• Dismissed state when hiding the alert is safe.
• Resolved state where the alert updates, downgrades, or disappears when the condition changes.
• Escalated state where the condition moves to inline message, error state, banner, notification center, or confirmation dialog.

Interaction Contract

• The alert appears close to the task area whose outcome it affects and before the controls users need next.
• The alert title names the condition or affected process, not only the severity.
• The body states the consequence and the most useful next step in one or two short sentences.
• The alert does not steal focus, but its action and dismiss controls are reachable in normal tab order.
• Urgent dynamic text is announced with alert semantics; advisory updates use status or region semantics.
• Dismissal does not hide an unresolved critical condition with no alternate route.
• When the condition resolves, the alert is removed, converted to lower-urgency status, or replaced by the correct recovery surface.

Implementation Checklist

• Classify the condition by urgency, affected scope, user consequence, and whether a user response is required.
• Place the alert in the current task region, not in a detached corner or global header unless the scope truly spans the product.
• Write a title that names the issue, such as Session expires soon or Connection lost.
• Write body text that explains what will happen and what the user can do next.
• Limit actions to one direct command or one detail route; move multi-step recovery into a dedicated flow.
• Choose role alert for urgent dynamic text, role status for lower-urgency status, and alertdialog when closure or response is required.
• Do not create several assertive alerts at once; queue, merge, or prioritize them by consequence.
• Test repeated alerts, dismissal, resolved state, screen reader announcement, keyboard reachability, zoom, and narrow layouts.

Common Generated-UI Mistakes

• Using a disappearing toast for warnings users must act on before continuing.
• Using a modal dialog for a message that only needs immediate notice and one optional next step.
• Using alert semantics for routine success messages, progress ticks, or page-load content.
• Putting product-wide maintenance or outage messages inside one task alert.
• Showing several assertive alerts at the same time.
• Writing severity-only copy such as Error or Attention without consequence or action.
• Letting users dismiss a critical unresolved condition with no way to rediscover it.

Critique Questions

• Is the condition urgent enough to interrupt assistive technology output, or should it be a calmer status message?
• Can users tell which current task, process, or page condition the alert affects?
• Does the alert say what will happen if users do nothing?
• Is one direct action enough, or does this need an error state, dialog, page, or panel?
• Can the alert be dismissed safely, and how can users rediscover unresolved conditions?
• What happens when the condition resolves, repeats, or coexists with another warning?