| UI or UX | UI + UX - Destructive copy anti-pattern | UI + UX - Final destructive commit review | UI + UX - Exact target phrase gate before severe commit | UI + UX - Pre-execution review of high-impact actions that may affect money, access, production systems, legal status, customers, external recipients, or safety | UI + UX - Anti-pattern where repeated low-value confirmations train users to dismiss real risk prompts automatically | UI + UX - Severe-consequence warning copy before an action |
| UI guidance | Replace vague destructive controls with labels that name the verb, target, count, and outcome, such as Delete workspace, Keep workspace, Revoke Maya's access, or Cancel subscription. | 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. | Render a visible non-secret text field inside a destructive or high-consequence confirmation, labelled with the exact target phrase the user must type before the final action enables. | 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. | Do not present the same modal confirmation for routine, reversible, low-risk, or high-frequency actions; reserve interruptive confirmation for consequences that can reasonably change a user's decision. | 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. |
| UX guidance | Make the copy carry the decision boundary: users should know which choice destroys, which preserves, which closes the surface, and which continues review. | Use destructive action confirmation to create one informed stop before permanent or externally visible loss, not to slow every routine cleanup action. | Use typed confirmation only when reproducing the target phrase meaningfully reduces severe wrong-object or wrong-scope mistakes, such as deleting a repository, project, account, workspace, production dataset, or root credential. | Use dangerous-action review when an action is not necessarily destructive but can create high-impact consequences such as sending money, changing access, executing production commands, contacting customers, publishing content, filing a legal response, or letting an agent use a privileged tool. | Confirmation should reduce a specific mistake, not create a reflexive second click after every command. | 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. |
| Good UI | A dialog title says Delete Payments project?, the safe action says Keep project, and the final action says Delete Payments project. | 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. | Delete repository acme/payments-api? requires typing acme/payments-api, shows a mismatch until the exact path matches, and then enables Delete repository. | 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. | Archiving a message completes immediately with Message archived and Undo, while permanently deleting a workspace opens a specific destructive confirmation. | Before Submit declaration, a warning with an exclamation icon says the user may be fined if they provide false information. |
| Bad UI | A destructive prompt says Are you sure? with OK and Cancel. | A modal says Are you sure? with OK and Cancel after the user clicks Delete, without naming the project or what disappears. | A dialog asks users to type YES before deleting a workspace, so the text does not verify the target object. | A privileged tool button says Continue and immediately sends a customer email, changes access, and updates billing without showing the payload or external recipients. | Every Save, Dismiss, Filter, Archive, and Close action opens the same Are you sure? modal with OK and Cancel. | A red sentence says Important below the submit button after the user has already acted. |
| Good UX | A user reads Keep subscription and Cancel subscription and correctly chooses the path that preserves billing. | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | A user starts deleting acme/payments-api, mistypes the repository path, sees the mismatch, and cancels before deleting the wrong repository. | 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. | A user archives ten low-risk notifications quickly, can undo the last archive, and still pauses when the only modal names permanent account deletion. | Users see the fine or eligibility consequence before checking the declaration and can pause to verify their answer. |
| Bad UX | A user presses OK because it looks like a neutral acknowledgement and accidentally deletes the workspace. | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | A user types DELETE by habit and passes the gate without checking which workspace will be removed. | A user approves a notification from email after the underlying payload changed, and the system executes against a different customer. | A user clicks OK through a production delete prompt because the last 30 prompts all looked identical and protected harmless actions. | A benefit-loss warning appears only after submission, so users cannot change the decision it warns about. |
| Best fit | Auditing destructive dialogs, action sheets, menu items, command palette actions, delete receipts, account cancellation flows, permission revocation, bulk actions, and high-impact execution reviews. | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | A severe action affects repository, project, workspace, account, production, security, billing, or organization-wide scope. | 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. | 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. | A user must understand a serious consequence before taking or skipping an action. |
| Avoid when | The issue is not copy ambiguity but missing loss inventory, dependency blocking, or acknowledgement; use destructive action confirmation. | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The action is routine, reversible, local, or recoverable through undo or trash restore. | The risk is narrowly permanent deletion or loss of a named object; use destructive action confirmation. | Do not use this entry to remove confirmation from permanent deletion, broad permission changes, external side effects, legal commitments, payments, production commands, or account closure without adding an equally strong safeguard. | The message is a dynamic task status that must be announced when it appears. |
| Required state | Clear destructive title state with verb, target, and consequence. | Idle state where the destructive command is visible but not committed. | No-typed-gate state for actions that do not need target-text escalation. | Armed action state with verb, target, payload, actor, source, and exact execution boundary. | Prompt inventory state showing which actions are confirmed, how often they occur, and what consequence each confirmation prevents. | No-warning state where the action has no severe consequence. |
| Accessibility burden | Accessible names for destructive and safe controls must include the outcome, not only visible adjacent text. | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Associate the input with a label that includes or references the required phrase. | Use headings and labels that name the action and target before risk details. | Reducing unnecessary dialogs reduces focus disruption, but replacement feedback and undo controls must remain keyboard reachable and programmatically identifiable. | Do not rely on color alone; include visible or programmatic warning wording and a non-color cue such as an icon. |
| Common misuse | A delete prompt uses OK and Cancel without naming what OK will delete. | Using a vague Are you sure prompt that does not name the object, count, or consequence. | Requiring users to type yes, confirm, or delete instead of the target name. | Using vague Are you sure, Continue, or Proceed copy without naming the dangerous operation. | Adding a confirmation after every user mistake without asking whether the mistake was reversible. | Using warning text for routine hints, explanations, or mild reminders. |