Skip to content
UX Atlas
Plate PAT·009 · PatternGrid F2 · Rev. 2026-09-14

Destructive Actions

Actions that remove or destroy, which need separation in space, distinct styling and a recovery path.

PatternExpert heuristicFoundational

Definition

A destructive action removes data or causes an effect the user cannot easily reverse. The design obligations are to make it hard to trigger accidentally, obvious in consequence, and recoverable wherever technically possible.

Expert heuristic. A review criterion developed by practitioners. Useful and widely taught, but evaluated by judgement rather than measurement.

On this plate
  1. 1Definition
  2. 2Layered protection, cheapest first
  3. 3Designing deletion
  4. 4Choosing how permanent to be
  5. 5Deleting an account, in order
  6. 6In practice
  7. 7Local chart
  8. 8Continue from here

Reach for this when

  • Any action that removes data.
  • Bulk operations.
  • Account and workspace deletion.
  • An action removes something the reader could not recreate.

Common mistakes

  • Delete adjacent to a frequent action.
  • No recovery path.
  • Undo that expires too quickly.

Layered protection, cheapest first

  1. 1.Separate it in space from frequently used actions, which removes most accidental triggers at zero cost.
  2. 2.Style it distinctly, using the danger colour plus text, never colour alone.
  3. 3.Make it recoverable: soft delete with a restore window is almost always achievable.
  4. 4.Offer undo immediately after, in a persistent inline message rather than a vanishing toast.
  5. 5.Confirm, only if it is genuinely irreversible.
  6. 6.Require typed confirmation, only if it is catastrophic.

Designing deletion

Do

  • Prefer archive or soft delete, with a stated restore window.
  • Show what will be destroyed, including anything that goes with it.
  • Separate the destructive control from the ones beside it.
  • Say what has happened afterwards, and where it went.

Do not

  • Put delete next to the most-used action in a row menu.
  • Delete children silently along with the parent.
  • Use red styling as the only protection.
  • Offer undo for something that cannot actually be undone.

Choosing how permanent to be

ApproachUse whenAlso required
ArchiveThe item has value as a record and is unlikely to be wanted in the listA route back to archived items that people can actually find.
Soft delete with a windowThe default for almost everything a person deletesThe window stated at the moment of deletion, and a trash that empties predictably.
Hard deleteThe reader asked for erasure, or retention rules require itA statement of what else goes with it, and what is kept for legal reasons.
AnonymiseActivity must survive but the person must not be identifiableSaying what remains visible to others afterwards.
Export, then deleteAccounts, workspaces, anything a person spent months buildingThe export finished and downloaded before the deletion runs.

Deleting an account, in order

The highest-stakes destructive flow in most products, and the one most often designed as a single red button.

  1. 1

    Say what will be destroyed

    Data, shared content, other people's access to it, and anything that belongs to a team rather than to this person.

  2. 2

    Offer the lesser action

    Pause, downgrade or leave the team. A large share of deletion attempts are actually one of these, and offering them is help rather than obstruction.

  3. 3

    Offer the export first

    Deleting an account without a way to take the data out makes the decision irreversible in a way the reader may not have understood.

  4. 4

    Confirm deliberately

    Typing the account name, or re-entering the password, proportional to what is being lost.

  5. 5

    Soft delete, then erase

    A stated recovery window, then permanent erasure, with a message confirming it happened and what was retained for legal reasons.

In practice

  1. i.

    Delete in the overflow menu

    Lists

    Moving delete out of the row and into an overflow menu removes the most common accidental deletion without meaningfully reducing discoverability.

  2. ii.

    And everything inside it

    Cascade

    Deleting a project removed forty documents nobody had mentioned in the dialogue. Stating the count, and listing what goes with it, is the difference between a decision and an accident.

Local chart

PAT·009 · Region III · Grid F2

This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.

Error PreventionHEUR·005 · PRINCIPLES BEHIND THISUser Control and FreedomHEUR·003 · PRINCIPLES BEHIND THISFitts's LawLAW·002 · PRINCIPLES BEHIND THISForgivenessPRIN·006 · PRINCIPLES BEHIND THISEmphasisFND·018 · PRINCIPLES BEHIND THISButtonCMP·001 · OFTEN USED WITHMenuCMP·018 · OFTEN USED WITHToastCMP·014 · OFTEN USED WITHBulk ActionsPAT·017 · OFTEN USED WITHConfirmationPAT·008 · OFTEN USED WITHSettings and PreferencesPAT·025 · OFTEN USED WITHUndoPAT·022 · OFTEN USED WITH

Continue from here

Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.

Applies when you are designing

Settings

Principles behind this

The reasoning this solution is an application of.

Often used with

These usually appear in the same screen or the same decision.

Related concept

Connected closely enough to change how you apply this.