| UI or UX | UI + UX - Anti-pattern where repeated low-value confirmations train users to dismiss real risk prompts automatically | UI + UX - Consequential alert decision | UI + UX - Final destructive commit review | UX - Post-action recovery behavior | UI + UX - Severe-consequence warning copy before an action | UI + UX - Pre-execution review of high-impact actions that may affect money, access, production systems, legal status, customers, external recipients, or safety |
| UI guidance | Make the UI distinguish routine action feedback from genuine risk: use inline status, undo, warning text, disabled prevention, review, or clearer command placement instead of another generic Are you sure dialog. | Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope. | Render a destructive confirmation after the user invokes a destructive command, with a title and final action button that repeat the destructive verb and target, such as Delete workspace or Cancel subscription. | Show a named recovery affordance after the completed action, such as Undo delete for a specific task, near the result or in a consistent status region. | 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. | Render dangerous-action review as a pre-execution checkpoint that names the armed action, actor, target, scope, affected systems, external effects, risk reason, evidence, freshness, permissions, alternatives, and exact outcome of Run, Cancel, Edit, or Escalate. |
| UX guidance | Help the person reach a clear task outcome. | Help the person reach a clear task outcome. | Make the safe path explicit and easy, keep the destructive action unavailable until required review is satisfied, and report whether the object was kept, blocked, or permanently committed. | Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result. | 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. | Help users decide whether to run, revise, cancel, defer, or escalate the action by making the action payload inspectable, comparing it with safer alternatives, revalidating stale state, and recording what the reviewer saw before execution. |
| Good UI | Archiving a message completes immediately with Message archived and Undo, while permanently deleting a workspace opens a specific destructive confirmation. | Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive. | Delete Payments project? lists 4 dashboards, 12 saved views, 3 webhooks, and 8 shared links, offers Keep project, and labels the danger action Delete Payments project. | Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button. | Before Submit declaration, a warning with an exclamation icon says the user may be fined if they provide false information. | A production console shows Restart payment workers, affected region, open incidents, customer impact, rollback owner, evidence links, change window, dry-run result, and Run restart only after the reviewer checks the risk inventory. |
| Bad UI | Every Save, Dismiss, Filter, Archive, and Close action opens the same Are you sure? modal with OK and Cancel. | The red destructive action is enabled immediately and sits where users expect the routine primary button. | A soft archive action opens the same severe deletion confirmation used for permanent account closure. | Undo action disappears before users can activate it. | A red sentence says Important below the submit button after the user has already acted. | A warning says This may be risky but hides the target, policy trigger, evidence, and whether the action can be undone. |
| Good UX | A user archives ten low-risk notifications quickly, can undo the last archive, and still pauses when the only modal names permanent account deletion. | Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive. | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | Undo restores the deleted task to the list and reports Quarterly report restored. | Users see the fine or eligibility consequence before checking the declaration and can pause to verify their answer. | A release manager sees that a deploy action affects production EU, has a stale smoke test, cancels execution, refreshes checks, and then runs the action with an audit record. |
| Bad UX | A user clicks OK through a production delete prompt because the last 30 prompts all looked identical and protected harmless actions. | Every archive, filter, and dismiss action opens the same confirmation until users click through automatically. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | The UI promises undo for a side effect that has already notified external recipients. | Users incur a penalty because the warning looked like ordinary hint text. | A user approves a notification from email after the underlying payload changed, and the system executes against a different customer. |
| Best fit | Use this anti-pattern entry to audit products that ask for confirmation on many routine actions or use identical prompts for different levels of risk. | The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible. | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | The action is common and mistakes are likely. | A user must understand a serious consequence before taking or skipping an action. | A user, agent, automation, or admin tool is about to execute a high-impact action that can affect money, access, production systems, legal/compliance state, customers, external recipients, sensitive data, or safety. |
| Avoid when | Choose another interaction when the task calls for a different route. | The action is routine and easily reversible. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | Recovery would restore only part of the user's lost work. | The message is a dynamic task status that must be announced when it appears. | The risk is narrowly permanent deletion or loss of a named object; use destructive action confirmation. |
| Required state | Prompt inventory state showing which actions are confirmed, how often they occur, and what consequence each confirmation prevents. | Pre-action state with an explicit consequential trigger. | Review state that names the destructive verb, target object, and affected scope. | Normal state before the user action. | Before-action warning state placed immediately before the related control or declaration. | Armed action state with verb, target, payload, actor, source, and exact execution boundary. |
| Accessibility burden | Reducing unnecessary dialogs reduces focus disruption, but replacement feedback and undo controls must remain keyboard reachable and programmatically identifiable. | Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response. | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Make the undo control keyboard reachable and programmatically identifiable. | Keep the warning in reading order before the control, declaration, or instruction it qualifies. | Use headings and labels that name the action and target before risk details. |
| Common misuse | Using one generic confirmation component for every action from closing a panel to deleting a workspace. | Asking users to confirm every routine action until they stop reading. | Labelling the destructive commit OK, Yes, Continue, or Confirm. | Restoring only part of the prior state while implying full recovery. | Using warning text for routine hints, explanations, or mild reminders. | Showing a risk warning but hiding the action payload, target, recipients, amount, command, environment, or external effect. |