Task pattern

Destructive actions

Match warning, confirmation, and recovery to the consequence and reversibility of an action.

Pattern model

Parts that must work together

TriggerConsequenceScopeConfirmationProgressResult or undo
Why this matters

A pattern is not a screenshot. It is a reusable decision model that must preserve intent, state, recovery, and accessibility as layouts change.

Decision framework

Questions to answer before choosing UI

Can the action be reversed?

Prefer immediate action with undo when reversal is reliable. Confirmation becomes more important as consequence, scope, or irreversibility increases.

What exactly is affected?

Name the object, amount, collaborators, permissions, and downstream effects. Do not rely on a generic danger color.

What proof is proportionate?

A normal confirmation may need only a specific button label. High-impact actions may justify reauthentication, typed confirmation, or a delay.

Cross-system baseline

End-to-end accessibility

  • Move focus into confirmations and return it intentionally
  • Use action-specific labels
  • Do not make color the only danger cue
  • Announce completion, failure, and undo availability
  • Keep destructive and cancel actions distinguishable at zoom and high contrast
Common mistakes

Failure patterns to test

01

Confirming every harmless action

02

Using Yes and No labels

03

Making the destructive action the safest-looking choice

04

Claiming an action is reversible when undo can fail

05

Hiding scope until after confirmation