Confirmation fatigue

Problem Context

• A product uses modal confirmations, alert dialogs, browser confirms, action sheets, or extra OK prompts for many commands in the same workflow.
• Many confirmed actions are frequent, reversible, local, low-risk, or already clear from the command label.
• The same prompt style is used for harmless actions and severe actions, so users cannot tell which prompt deserves attention.
• Teams may have added confirmations after incidents without checking whether undo, prevention, command placement, warning text, or review would target the real error better.

Selection Rules

• Flag this anti-pattern when low-risk, reversible, or high-frequency actions repeatedly open modal confirmations.
• Flag it when confirmation copy is identical across different consequences, such as Are you sure? or Continue? for both routine dismiss and permanent deletion.
• Flag it when users see a second prompt after a stronger safeguard already proved intent, such as typed confirmation, high-impact review, or explicit destructive command wording.
• Use confirmation dialog only when the dialog adds object, scope, consequence, or recovery-limit information that could reasonably make the user cancel.
• Use destructive action confirmation when the action is a named destructive final commit with meaningful loss inventory.
• Use typed confirmation only for severe wrong-target risk, not as an extra ritual after every delete.
• Use undo when the action is frequent and the exact prior state can be restored before external effects occur.
• Use warning text when users only need consequence copy before they start the risky action.
• Use dangerous-action review when the issue is inspectable high-impact payload, evidence, side effects, or stale state rather than a yes-or-no confirmation.
• Prefer prevention by better placement, disabled-state explanation, previews, dependency blocking, permissions, or safer defaults when those remove the mistake without a prompt.

Required States

• Prompt inventory state showing which actions are confirmed, how often they occur, and what consequence each confirmation prevents.
• Routine reversible action state using status and undo instead of modal confirmation.
• Meaningful confirmation state reserved for uncommon destructive, costly, external, permission, or security-sensitive actions.
• Prompt suppression state where repeated low-risk confirmations are removed or replaced with less interruptive feedback.
• Escalation state where severe deletion, broad scope, or wrong-target risk routes to destructive or typed confirmation.
• Copy specificity state where remaining prompts name object, scope, consequence, and safe outcome.
• Habit signal state using telemetry or research such as very fast OK clicks, high dismissal rate, or repeated prompt chains.
• Bad spam state where every Save, Close, Filter, Archive, Dismiss, or Navigate command asks Are you sure.
• Bad double-protection state where confirmation, typed phrase, and undo all stack on the same low-risk action.
• Bad false-safety state where prompts remain but the system cannot undo, prevent, or describe the real consequence.

Interaction Contract

• Each confirmation must have a documented risk, consequence, and reason it is better than undo, prevention, warning text, review, or clearer command placement.
• The same user path should not show repeated confirmations for the same consequence unless the second step adds materially new information.
• Routine recoverable actions should complete with clear feedback and recovery instead of blocking the action first.
• Remaining confirmations must differ visually and textually by consequence, target, and final action label rather than using generic OK or Continue.
• Suppression rules should consider action frequency, reversibility, role, environment, object scope, and whether the user has already reviewed the consequence.
• When a prompt is removed, the replacement recovery or prevention path must be visible, keyboard reachable, and honest about what can be restored.
• Analytics, usability testing, support reports, and incident reviews should be used to check whether confirmations are read or merely dismissed.

Implementation Checklist

• Inventory all confirmation prompts in the workflow and tag each by action, frequency, reversibility, external effects, consequence severity, and existing recovery.
• Remove modal confirmation from routine save, close, filter, dismiss, archive, hide, reorder, and delete-to-trash actions when undo or status feedback is sufficient.
• Replace low-risk confirmations with object-specific feedback, undo, restore, inline validation, disabled explanation, preview, or better command grouping.
• Keep or add confirmation only where object, count, scope, cost, permission, external recipient, recovery limit, or legal consequence can be shown before commitment.
• Use destructive action confirmation, typed confirmation, dangerous-action review, or human approval gate only when their stronger contract matches the consequence.
• Write remaining prompt copy with the affected object, consequence, safe action, and final action; avoid OK, Yes, No, Continue, and repeated Are you sure wording.
• Measure fast dismissals, prompt chains, repeated confirmations per task, cancellation rate, undo use, support incidents, and whether users can recall what they confirmed.
• Test keyboard and screen-reader flow for both removed prompts and remaining prompts so fewer dialogs do not hide recovery from non-pointer users.

Common Generated-UI Mistakes

• Adding a confirmation after every user mistake without asking whether the mistake was reversible.
• Using one generic confirmation component for every action from closing a panel to deleting a workspace.
• Stacking warning text, confirmation dialog, typed confirmation, and undo for a low-risk action.
• Keeping prompts because they feel safer even though users dismiss them unread.
• Removing prompts without adding the undo, restore, status, or prevention path that made removal safe.
• Treating cancellation rate alone as proof that a prompt is useful without checking task interruption and habituation.

Critique Questions

• What specific mistake does this confirmation prevent?
• How often will a user see this prompt in one normal task?
• Can the exact prior state be restored with undo instead of blocking the action?
• Does the prompt add new consequence information beyond the trigger label?
• Are severe prompts visually and textually distinguishable from routine prompts?
• Are users clicking through so fast that they probably are not reading?
• Can the risk be reduced by command placement, disabled explanations, previews, or safer defaults instead of confirmation?