How Should You Design Undo and Destructive Actions?

How Should You Design Undo and Destructive Actions?

Default to undo, reserve confirmation for what cannot be undone, and make truly irreversible actions rare. A confirmation dialog asks someone to predict the future. An undo lets them look at the result and change their mind, which is how people actually make decisions.

Most products get this backwards. They put a confirmation on every delete, including the ones that are trivially recoverable, and then offer no recovery at all for the one action that genuinely destroys something.

Here is a framework for deciding, plus what the research and the accessibility standards actually require.

Why Are Confirmation Dialogs Usually the Wrong Fix?

Because they stop being read. When every action raises a dialog, clicking through it becomes part of the muscle memory of doing the task. The dialog is still there, technically protecting the user, while providing no protection whatsoever.

They also interrupt at the wrong moment. Someone deleting a row has already decided. The dialog does not add information, it adds a step, and the person answering it has no more knowledge than they had a second earlier.

Worst of all, a habitual dialog hides the dangerous case. If deleting a draft and deleting a workspace both raise the same style of modal, the one that matters looks exactly like the forty that did not.

What Does Usability Research Say About This?

That prevention beats messaging, and that people need a way out. Jakob Nielsen's ten usability heuristics, first published on 24 April 1994, cover both halves. Heuristic 3, user control and freedom, and heuristic 5, error prevention, are the two that govern destructive actions.

Heuristic 3 is direct: users often perform actions by mistake, and they need a clearly marked emergency exit to leave the unwanted action without having to go through an extended process. Supporting undo and redo is named explicitly as part of that.

Heuristic 5 makes the prevention case. Good error messages are important, but the best designs carefully prevent problems from occurring in the first place, either by eliminating error-prone conditions or by checking for them and presenting a confirmation before the user commits.

What Is the Difference Between a Slip and a Mistake?

A slip is an unconscious error caused by inattention. A mistake is a conscious choice made from a wrong mental model. NN/g's heuristics draw that line, and it matters here because the two failures need completely different defences.

Slips are the wrong-row click, the double-tap that fires twice, the keyboard shortcut hit by accident. A confirmation dialog does catch some of these, but an undo catches all of them, and without taxing the people who did mean it.

Mistakes are different. Someone deletes an integration believing it is unused, and it is not. No dialog saying are you sure helps, because they are sure. What helps is telling them what depends on the thing, which is information rather than friction.

Is Recovery an Accessibility Requirement?

For consequential actions, yes. WCAG success criterion 3.3.4, Error Prevention for legal, financial and data, is a Level AA requirement, and it covers pages that modify or delete user-controllable data in data storage systems. Deleting a customer record sits squarely inside that scope.

The normative wording requires at least one of three things. Submissions are reversible. Or data entered is checked for input errors and the user is given a chance to correct them. Or a mechanism is available for reviewing, confirming, and correcting information before finalising the submission.

Read that as a menu rather than a checklist. Reversible satisfies it on its own, which means a well-built undo is not only better usability, it is also the cleanest route to conformance. W3C notes the rationale plainly: people with disabilities may be more likely to make mistakes.

What Framework Should You Use to Decide?

Two questions decide almost every case. Can the action be reversed cheaply, and how far does the damage reach if it is wrong? Reversibility tells you whether undo is available at all. Blast radius tells you how much ceremony the action deserves.

Blast radius	Reversible	Irreversible
Affects one item the user owns	Act immediately, offer undo	Soft delete instead, then undo
Affects other people's work	Act, offer undo, notify those affected	Typed confirmation naming the item
Affects billing, access or the whole account	Confirm with a summary of effects	Typed confirmation plus a delay or a second approver

The top-right cell is where most product decisions actually belong, and it is the one teams skip. Making a deletion soft, so the record is hidden rather than destroyed, converts an irreversible action into a reversible one and moves the whole problem into the easy column.

How Long Should an Undo Window Be?

Long enough to notice the mistake, which is longer than a toast usually lasts. Five seconds covers the immediate oh no. It does not cover the realisation two minutes later when someone opens the report and the data is missing.

Our default is a short inline undo for the immediate case and a recoverable trash for the delayed one. The toast handles slips. The trash handles mistakes. Neither alone is enough, and together they cost very little.

Whatever window you pick, say it out loud in the interface. Deleted items stay in trash for 30 days is a sentence that removes the entire fear from the action. An unlabelled undo leaves people guessing and clicking carefully forever. Our notes on SaaS notification design cover where those messages should live.

When Do You Actually Need a Confirmation?

When the action cannot be undone and the consequence reaches beyond the person doing it. Cancelling a subscription, removing another user's access, deleting a workspace with other people's work in it: these deserve a stop, because no recovery exists and the person harmed is not the person clicking.

When you do confirm, make the confirmation carry information rather than friction. Tell them what is about to happen in specifics: this will remove 240 records and revoke access for 6 people. That sentence does more than any number of warning colours.

Typed confirmation, where someone types the name of the thing being destroyed, is the right tool at the top end. It is deliberately annoying, and that annoyance is proportionate when the action is permanent and shared.

What Should a Destructive Confirmation Look Like?

Clear about the effect, honest about reversibility, and never designed to trick. The button should say what it does, so Delete workspace rather than OK, because a person scanning a modal reads the button before they read the sentence above it.

Do not hide the safe option or style it to be missed, and do not pre-select the destructive one. Making the dangerous path easier than the cancel path is a dark pattern even when it is accidental, and it is a common accident. Our piece on dark patterns and conversion covers where that line sits.

Say whether it can be undone, in the dialog, in plain words. This cannot be undone is one of the most useful sentences in product design, and it is only powerful if you have not used it on the things that obviously can be.

Who Should Be Able to Do the Dangerous Things?

Fewer people than can today, usually. Permissions are the cheapest destructive-action control there is, because an action a person cannot take is one they cannot take by accident. Most products give every member far more destructive reach than the team intends.

The pattern worth copying is graduated. Anyone can delete their own work, a smaller group can delete shared work, and a very small group can delete things that affect billing or access. That maps neatly onto the blast radius column in the table above.

Add an audit log while you are there, because recovery starts with knowing what happened and who did it. Our guide to roles and permissions UX covers how to present this without turning it into a configuration maze.

How Do You Roll This Out Across a Product?

Inventory first. List every destructive action in the product, mark each one reversible or not, and mark its blast radius. That list is usually shorter than the team expects, and it immediately shows which confirmations are pure ritual.

Then make the changes in one order: convert irreversible deletions to soft deletes, add undo where it was missing, and only then remove the confirmations that are no longer earning their place. Removing dialogs before adding recovery is how you end up with an incident.

If you want a second pair of eyes on that inventory, or you are arguing about a delete button right now, we are happy to help you think it through. This is regular work for us at phoenix.studio, and the audit itself usually takes an afternoon.