Permit easy reversal of actions

What it is

Permitting easy reversal means reversible actions get low-friction undo, redo, cancel, reset to default, or return to the previous state; irreversible actions must be clearly flagged and de-risked with preview, delay, confirmation, and compensation. What gets reversed is state and consequence, not just what is drawn on screen.

Why it happens

Reversibility lowers the psychological cost of trying something, letting users explore instead of over-confirming every step — but this only holds if the system actually has an internal state model that can be cleanly rolled back. Once an action has externalised its consequence — an email has reached the recipient's server, a payment has cleared, a webhook has already notified a third-party system — "undo" is no longer rewinding state, it becomes issuing a compensating operation: a fundamentally different engineering problem, since compensation can fail, can only partially succeed, or can race against subsequent actions. In other words, two undo buttons that look identical on screen can sit on top of two mechanisms of a completely different nature, and users cannot tell which one they are pressing from its appearance.

Where it stops holding

A delay-based "send undo" (a buffer of a few seconds after clicking) only works within that window and only while the external effect has not actually propagated yet — once the recipient's server has accepted an email, a "recall" request will most likely fail because the other system has already completed delivery and is now outside one's control. Giving a visible undo affordance to an action that is genuinely irreversible past a certain point is more dangerous than offering no undo at all: it creates false confidence, which pushes users toward riskier decisions, and when the compensation then fails the loss is larger than if they had known upfront it could not be undone. Long histories, large objects, and multi-user collaborative editing add performance and ownership limits too — a bulk undo may collide with changes someone else made in the meantime, and whose version wins needs to be defined at design time, not left for the undo logic to improvise.

Applying it

• Label each action's real reversibility tier — a clean state rollback versus an externally compensated effect — and reserve the word "undo" for the former only.
• Provide an undo toast and a history panel; support bulk undo with an object count for batch operations; for compensation-based actions use "request recall" instead, and state plainly that success is not guaranteed.
• Give irreversible actions a preview, dry run, delayed execution, notification, and recovery window, with a clear countdown before the buffer closes rather than letting users assume it can always be undone.
• Test action-undo-redo-refresh sequences and state consistency under concurrent edits, especially what happens when an undo request crosses the buffer's boundary.

Related

• Same group: B3.11.1 Strive for consistency · B3.11.2 Provide universal usability · B3.11.3 Offer informative feedback · B3.11.4 Design dialogs to yield closure · B3.11.5 Prevent errors · B3.11.7 Keep users in control · B3.11.8 Reduce short-term memory load
• Nearby: B3.03 User Control and Freedom · B3.09 Error Recognition, Diagnosis, and Recovery
• Search terms: undo redo · reversibility · golden rules