Destructive Actions

Last updated:

Practical patterns for delete, irreversible change, and confirmation that matches severity.

01 — Foundation

Destructive actions earn extra care

Deletion, irreversible changes, and financial commits need clarity before execution.

Destructive actions remove data, close accounts, or commit money. Users need to understand what will happen, whether recovery exists, and how to back out until they confirm deliberately.

02 — Confirm

Confirmation before, not after

Specific copy beats generic “Are you sure?” every time.

  • name the object and consequence — “Delete invoice #1042 permanently?”
  • state whether undo or restore exists — or that it does not
  • use native dialog for focused confirmation — see Modal / Dialog
  • primary destructive button styled distinctly; safe action remains obvious 
'Delete this project and all its files? This cannot be undone.'

03 — Friction

Match friction to severity

Low-risk deletes may need one step; account closure may need typed confirmation.

  • prefer undo for reversible actions instead of modal fatigue on every edit
  • type-to-confirm for rare, catastrophic actions — not for deleting a draft tag
  • avoid destructive styling on ambiguous controls — “Remove” vs “Delete forever”
  • do not hide destructive actions in overflow menus without clear labels

04 — After

After the action runs

Success should be calm; failure must not leave users unsure whether data was lost.

  • confirm completion inline — “Invoice deleted” — not only a disappearing toast
  • on failure, explain what still exists and offer retry or support path
  • return focus to a sensible place — often the list or parent view

05 — Review

Before you approve

A short checklist for destructive actions in code review.

  • users understand scope and permanence before confirming
  • friction matches severity; undo used where appropriate
  • outcomes are visible; errors are specific — see Confirmation and Error States