The Undo Checklist
Most teams design the first, forget the second, and never name the third. The window is where the trust lives. An action that is technically reversible but whose reversal window closed while the us...
The template
The Undo Checklist
Undo used to mean the last thing you did. It now has to mean the thing the system did on your behalf while you were asleep. Three parts: the reversal, the notification, and the window between them. Run this checklist on every autonomous action before it ships.
The three parts
Reversal. Can it be undone, by whom, and at what cost. Notification. How the person finds out it happened. The window. How long they have, and what happens when it closes.
Most teams design the first, forget the second, and never name the third. The window is where the trust lives. An action that is technically reversible but whose reversal window closed while the user slept is not reversible in any way that matters to them.
Classify the action first
The checklist changes by class. Sort every autonomous action into one of these four before anything else.
| Class | Definition | Example shape |
|---|---|---|
| Reversible, private | Undoing restores the previous state, nobody outside saw it | Drafted, sorted, tagged, organized |
| Reversible, witnessed | State restores, but somebody already saw the original | Message edited after delivery, a status somebody read |
| Irreversible, contained | Cannot be undone, effect stays inside the account | Data permanently deleted, a credit consumed |
| Irreversible, external | Cannot be undone, effect left the building | Payment sent, email delivered, external API write, permission granted |
The rule that follows from the table: irreversible external actions do not run autonomously. Ever. If the product needs to send money, send a message outside the account, delete something permanently, or change who can access what, a human confirms in-session. That is not a preference, it is the one place where "the agent handled it" costs more than it saves.
The checklist
Run every autonomous action through this. A no in the first section means it does not ship.
Reversal
- Class assigned, and it is not "irreversible, external."
- Reversal costs no more actions than the original action did.
- Reversal is available from the same place the notification appears, not buried in settings.
- Partial reversal is possible when the action was a batch. Undoing forty changes because one was wrong is a punishment.
- Reversing restores state fully, including anything downstream that fired. If it cannot, the interface says exactly what will not come back.
- Reversal is possible by someone other than the original user when the account is shared or managed. Admins need it, and they will need it on a bad day.
Notification
- The user is told the action happened, without having to go looking.
- The notification contains what changed, not just that something changed.
- The notification carries the undo control itself.
- The timing matches the class. Private and reversible can wait for the next session. Witnessed or irreversible cannot.
- Batched sensibly. Forty separate notifications for forty small actions trains people to ignore all of them, and the one that mattered goes with them.
- There is a single place listing everything done on the user's behalf, reachable at any time. This is the one people ask for after the first incident.
The window
- The window has a stated length, in the interface, before the action runs.
- The window is stated again in the notification, with the deadline in the user's own terms ("until Friday morning," not a timestamp).
- The window survives the user being away. A window that expires overnight for an action taken overnight is a window in name only.
- Something happens when it closes: a summary, a final confirmation, or a state change the user can see. Silence at the close is how people discover the window existed only after it mattered.
- Extending the window is possible for the classes where it is cheap.
Setting window length
There is no universal number, and any table claiming one is guessing. Set it from two things you can actually observe:
How often the user is present. A window shorter than the gap between their sessions is decorative. If people open the product on weekday mornings, a four-hour window is a fiction.
What the reversal costs you. Holding an action reversible has a real cost: storage, complexity, external systems that will not wait. Where that cost is near zero, the window should be generous enough that nobody has to think about it.
Write both down for each action, then pick. Record the number in the decision record so the next person does not have to re-derive it.
| Action | Typical gap between sessions | Cost of holding it reversible | Window |
|---|---|---|---|
The copy
Three sentences you have to write for every autonomous action. Write them now, not in the last week before launch.
Before: what the product will do, and how long it can be taken back. After: what it did, and the control to take it back. At close: that the window has closed, and what the state is now.
If you cannot write the third sentence without it sounding alarming, the action probably belonged in a class that requires confirmation.
The one thing to do this week
List every action your product takes without a human in the loop. Assign each one a class from the table. Any that land in "irreversible, external" are the conversation to have this week, and the list itself is usually longer than anybody on the team expects.
From "Undo Is a Design Primitive", chapter 7 of The Design Operating Model. falkster.com/design/undo-is-a-design-primitive