Design Undo Around What Can Actually Be Reversed

Trust, Privacy & Ethics · undo, trust, destructive actions

Updated 2026-08-04

Ask what the system records before promising to reverse anything. A product that stores only the current value cannot restore the previous one, and a product built on event sourcing records each change and can replay its way back.
Never offer undo for something that has already left the building. A sent email, a published post, a charged card, and a triggered notification have all reached somewhere you no longer control.
Separate the three honestly, because users read them as one:

Say which one this is at the moment of the action. Undo on something merely compensable sets an expectation the product will break.
Use a short delay before acting for anything final. A few seconds of Sending, undo costs nothing and prevents the most regretted actions in any product.
Record enough to reconstruct, not just to display. Who changed what, from what, to what, and when is what makes both undo and an audit trail possible, and neither can be added later to data that was never kept.
Show history where the change happened. A version list on the record is used, and the same information in a separate admin log is not.
Say what undo will affect when the action had side effects. Reversing a status change that already sent three emails needs to state that the emails were sent.

Undo is a promise about the past, and it can only be as good as what the system chose to remember.