Somebody clicked delete. A dialog appeared asking whether they were sure. They clicked yes, in about 200 milliseconds, without reading it, because they have answered that question several thousand times and it has never once been the thing standing between them and a mistake.
Then the data was gone, and the support conversation began, and somewhere in it a sentence appeared that should worry any product team: “but you confirmed it.”
The dialog is doing a different job than you think
Confirmation dialogs are usually added with a stated intent of preventing mistakes. What they reliably do is relocate responsibility. After the dialog exists, a destroyed record is the user’s error rather than the product’s design, and that reframing is comfortable enough that it stops anyone asking the harder question.
The mechanism that defeats them is not carelessness, it is learning. A prompt that appears on every deletion, including the thousands of intentional ones, teaches the user that the correct response is always yes. By the time the one accidental deletion arrives, dismissing the dialog is muscle memory. The prompt has trained the exact behaviour it was meant to interrupt.
This is worth stating plainly because it inverts the usual intuition: the more often a confirmation appears, the less protection it provides. A dialog that fires rarely might work. One that fires constantly is decoration.
Are you sure is not a safety mechanism. It is a receipt, collected in advance, for a failure you have decided to allow.
Undo wins on every axis that matters
Compare the two designs honestly. A confirmation costs every user a step, on every action, forever, and protects nobody who has become habituated. An undo costs nothing on the happy path, and rescues the person who made the mistake at the moment they realise it.
It is also better epistemically. A confirmation asks the user to predict whether they are about to make a mistake, which is precisely the thing they cannot do. Undo asks them to react to a mistake they can now see, which they are extremely good at.
Implementing it is usually less work than teams assume, because most deletions do not need to be deletions:
-- instead of DELETE
UPDATE records
SET deleted_at = now(),
deleted_by = :actor
WHERE id = :id;
-- every read path already needs this predicate
WHERE deleted_at IS NULL
-- and a scheduled job does the real removal later,
-- after the window in which anyone would want it back
DELETE FROM records
WHERE deleted_at < now() - interval '30 days';The cost is a predicate on your queries and a cleanup job. The gain is that the destructive action stops being destructive, which removes the reason the dialog existed.
Design the undo so it is actually reachable
A soft delete with no visible affordance is not an undo, it is a support ticket with extra steps. Three properties separate the two.
It appears where the action happened, immediately, as part of the confirmation that the action succeeded. “Deleted. Undo.” in the same place the user was already looking.
It survives longer than the toast. Five seconds is enough for a misclick and useless for the mistake somebody notices two minutes later, which is the more common case. The toast is the fast path; a trash or recently deleted view is the real one, and it needs to be findable without knowing the word your team chose for it.
It restores the thing, not a copy of the thing. If undoing a deletion produces a new record with a new identifier, every reference to the old one is still broken and the user has not recovered, they have re-created. Restoring in place is the whole point.
Three cases where you genuinely cannot undo
Some actions leave your system and cannot be recalled. These are the only places a confirmation earns its keep, and being strict about the list is what keeps the remaining dialogs meaningful.
It was sent to other people. An email, a message to a channel, an invitation. You can delete your copy; you cannot delete theirs. For these, the better design is usually a delay rather than a dialog: a short window during which the send can be cancelled, which converts an irreversible action into a reversible one for the period when regret actually occurs.
It moved money or made a legal commitment. A charge, a payout, an accepted contract. Reversal exists but as a separate compensating transaction with its own cost and its own record, which is not undo and should not be presented as undo.
It destroyed something with no recoverable representation. Rotating a key you do not escrow. Purging data on a deletion request you are legally obliged to honour. Here irreversibility is the feature, and the interface should say so rather than hedge.
If you must confirm, confirm the object
For the small number of genuinely irreversible actions, the dialog should be built to defeat habituation rather than to satisfy a checklist. That means it has to be specific, and it has to state consequence rather than action.
Weak: Are you sure you want to delete this? This action cannot be undone. [Cancel] [OK]
Stronger: Deleting the workspace “Northwind Migration” will permanently remove 1,204 documents and revoke access for 8 people. This cannot be undone. Type the workspace name to continue.
Four things changed. The object is named, so the user can catch the case where they selected the wrong one. The scope is quantified, which is what makes people stop. The consequence is stated in terms of what happens to the world rather than what happens in the database. And the response requires reading, so it cannot be answered from memory.
Type-the-name is deliberately annoying and that is correct. It should only be used where the annoyance is proportionate, which is exactly why the list of irreversible actions needs to stay short.
The audit worth doing
List every confirmation dialog in the product. For each one, answer a single question: is the action it guards genuinely irreversible?
Most will not be. Those dialogs are a tax on every user forever, paid to avoid building an undo once, and each one is quietly training your users to dismiss the few prompts that actually matter. Removing them is not a reduction in safety. It is the precondition for having any.