Use destructive action confirmation for a named destructive commit with loss inventory and safe cancellation; use confirmation dialog for other high-consequence decisions, undo for recoverable routine actions, and warning text for consequence copy before the user starts the action.
Use destructive action confirmation for a named destructive commit with loss inventory and safe cancellation; use confirmation dialog for other high-consequence decisions, undo for recoverable routine actions, and warning text for consequence copy before the user starts the action.
Practice the judgment: Imagine this situation: A destructive confirmation appears for every archive or dismiss action, making users click through automatically when a real deletion appears. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Destructive action confirmation | Confirmation dialog | Undo | Warning text |
|---|---|---|---|---|
| UI or UX | UI + UX - Final destructive commit review | UI + UX - Consequential alert decision | UX - Post-action recovery behavior | UI + UX - Severe-consequence warning copy before an action |
| UI guidance | 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 an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope. | 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. |
| UX guidance | 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. | Help the person reach a clear task outcome. | 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. |
| Good UI | 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 Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive. | 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. |
| Bad UI | A soft archive action opens the same severe deletion confirmation used for permanent account closure. | The red destructive action is enabled immediately and sits where users expect the routine primary button. | Undo action disappears before users can activate it. | A red sentence says Important below the submit button after the user has already acted. |
| Good UX | A user opens Delete workspace, reviews the object count and webhooks, cancels, and returns to the same workspace with nothing changed. | Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive. | 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. |
| Bad UX | A user confirms deletion because OK looks like the primary next step, then discovers shared links and child reports were lost. | Every archive, filter, and dismiss action opens the same confirmation until users click through automatically. | 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. |
| Best fit | A user has initiated a destructive command that can permanently remove, revoke, reset, deactivate, or cancel something valuable. | The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible. | The action is common and mistakes are likely. | A user must understand a serious consequence before taking or skipping an action. |
| Avoid when | The action is a routine reversible archive, hide, dismiss, move, reorder, or trash move. | The action is routine and easily reversible. | 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. |
| Required state | Review state that names the destructive verb, target object, and affected scope. | Pre-action state with an explicit consequential trigger. | Normal state before the user action. | Before-action warning state placed immediately before the related control or declaration. |
| Accessibility burden | Use alertdialog semantics or platform equivalent when the destructive decision requires an immediate response. | Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response. | Make the undo control keyboard reachable and programmatically identifiable. | Keep the warning in reading order before the control, declaration, or instruction it qualifies. |
| Common misuse | Labelling the destructive commit OK, Yes, Continue, or Confirm. | Asking users to confirm every routine action until they stop reading. | Restoring only part of the prior state while implying full recovery. | Using warning text for routine hints, explanations, or mild reminders. |