Undo
Letting an action happen immediately, and letting the person take it back.
The problem it solves
Products protect against mistakes by asking permission first. Undo protects against them by making the action reversible, which is faster for the ninety-nine cases and safer for the one.
Confirmation taxes every action to catch the rare wrong one. Undo taxes none of them and catches the wrong one after the fact. Where reversal is technically possible, undo is almost always the better trade, and it produces a product that feels quick rather than nervous.
Three depths of reversal
- Immediate undo
- A toast with an Undo control, alive for five to ten seconds. Covers the slip that is noticed instantly: the wrong row deleted, the message sent to the wrong channel.
- Deferred undo
- A trash or archive that holds items for weeks. Covers the mistake noticed on Thursday about something done on Monday.
- Version history
- Named or timestamped snapshots a person can browse and restore. Covers gradual damage, where no single action was wrong but the current state is.
Most products need at least two of these. A toast alone leaves Monday's mistake unrecoverable, and a trash folder alone means every slip costs a trip to another screen.
Reversal that does not land
- Item deleted
- Are you sure you want to delete this item?
- Undo
- Changes discarded
Reversal that works
- Q3 Budget moved to Trash. Undo
- Q3 Budget deleted. Undo (shown for 10 seconds, restorable from Trash for 30 days)
- Undo move to Archive
- Reverted to the version from 14:02. Redo
Give the toast enough time. Five seconds is short for anyone reading carefully, using a screen reader, or looking away. Ten is better, and pausing the timer while the pointer is over the toast costs one line of code. Say what was affected by name, because Item deleted tells someone with twenty rows selected nothing useful.
Some actions cannot be undone: a payment captured, an email delivered to an external server, a message read by someone else. Be honest about the boundary. A send-delay window of a few seconds converts the email case from irreversible into reversible, which is why it exists in every serious mail client.
Worked example
A hypothetical swap
A team removes the confirmation dialog on archiving and replaces it with an undo toast. Archiving becomes one click instead of two, for every user, every time. The mistakes that the dialog used to catch now get caught by the toast instead, and the ones noticed later get caught by the archive itself. The dialog was charging everyone for a protection that undo provides free.
When it fits
- The action can be reversed technically, including its side effects.
- The action is frequent, so removing a confirmation saves real time across a day.
- You can name the affected object in the confirmation toast.
- A deeper recovery route exists for mistakes noticed later.
When it backfires
- The action triggers something outside your system, like a payment or an outbound email, where undo is a promise you cannot keep.
- The toast disappears in three seconds, so the safety net is theoretical.
- Undo restores the object but not its context, such as returning a file to the root instead of the folder it came from.
- Undo is offered for a genuinely catastrophic and irreversible action, which builds a false sense of safety.
Products using it
Gmail
Delays sending for a configurable window and shows an Undo control, converting an irreversible action into a reversible one.
Figma
Supports deep undo across the editing session and pairs it with version history for older states.
Slack
Allows message editing and deletion after posting rather than confirming before every send.
The psychology under it
The takeaway
Prefer undo to confirmation wherever reversal is possible, and name the object in the toast.
Finished the teardown? Bank it and the day counts toward your run.