Fake undo

Problem Context

• A product shows Undo in a toast, snackbar, activity row, command bar, keyboard shortcut, history stack, or recovery panel after a completed action.
• The action may affect object identity, list order, filters, permissions, relationships, notifications, background jobs, external recipients, payments, webhooks, or audit state.
• The product may capture only part of the prior state or let the recovery window expire while the control still looks available.
• Users may perform multiple actions quickly, change filters, leave the route, reload, go offline, or lose permission before trying to undo.

Selection Rules

• Flag this anti-pattern when an Undo control does not restore the exact object, value, order, relationship, permission, selection, and visible status it claims to reverse.
• Flag it when undo appears after an external side effect such as email, payment, webhook, permission notification, customer message, or production command has already left the system boundary.
• Flag it when several actions overwrite one recovery target without showing which action Undo will reverse.
• Flag it when undo expires silently or remains visible after the recovery window is gone.
• Use undo when the product captures prior state before the action and can restore it faithfully before irreversible side effects occur.
• Use restore from trash when recovery happens later from a durable deleted-items location with retention and restore metadata.
• Use destructive action confirmation when exact recovery is impossible and users need to decide before commitment.
• Use toast notification for disposable feedback only; a toast may carry Undo only when the recovery action remains reachable long enough and works truthfully.
• Use autosave recovery when the recovery target is unsaved or uncertain local work rather than a completed reversible command.
• Use confirmation fatigue to audit overuse of confirmations, but do not replace a broken undo with another prompt unless pre-action review is the right safeguard.

Required States

• Pre-action state with enough identity, relationship, order, permission, and context captured for reversal.
• Completed recoverable state that names the affected action and exact target.
• Undo available state with a visible, keyboard-reachable recovery control.
• Restored state showing the object, values, relationships, counts, selection, and focus context returned.
• Undo expired state that removes or disables the control and explains the final commitment.
• Undo failed state that reports what was not restored and why.
• Partial restore state that is not labelled as full undo.
• External side-effect state where undo is unavailable or truthfully labelled as request, revoke, restore, or follow-up.
• Multiple-action queue state that shows which action each undo reverses.
• Bad fake undo state where the control appears but restoration is absent, partial, stale, overwritten, or misleading.

Interaction Contract

• The system captures reversible state before applying the action, not after users request undo.
• The undo label names the action or object when ambiguity is possible.
• Activating Undo restores enough state for the user to trust that the action was reversed.
• If restoration is partial, the UI says partial restore, restore available, request recovery, or open trash instead of Undo.
• Undo remains reachable long enough for pointer, keyboard, screen reader, and distracted users, or the action is routed to durable recovery.
• When the undo window expires, the UI removes or re-labels the control and reports final commitment.
• External effects are called out honestly; undo must not imply recalled email, payment, webhook, or notification unless that recall is actually implemented.
• Multiple recoverable actions are queued, grouped, or scoped so one Undo cannot accidentally refer to a different action.

Implementation Checklist

• Define what exact prior state must be restored for each action: ID, parent, order, labels, ownership, permissions, relationships, counts, draft values, and focus target.
• Capture the restore payload before mutating local, server, and external systems.
• Make undo idempotent and scoped to a stable action ID so duplicate clicks or retries do not corrupt recovery.
• Block or re-label undo for actions with irreversible external effects, or delay those effects until the recovery window closes.
• Keep recovery controls visible, keyboard reachable, and stable while focused; do not auto-remove a focused Undo button.
• Handle multiple actions with an undo stack, per-item undo, grouped undo, or explicit commit boundary.
• Report restored, expired, failed, partial, final, and unavailable states in text, not only by removing the toast.
• Test reload, route changes, filters, pagination, selection, offline, duplicate actions, permissions, external notifications, and screen reader status before claiming undo.

Common Generated-UI Mistakes

• Showing Undo after an action that has already sent email, money, permissions, or webhooks outside the product.
• Restoring only a visible row while losing comments, labels, sharing, order, or ownership.
• Letting a second action overwrite the first action's undo payload.
• Using a disappearing toast as the only recovery path for an important object.
• Keeping Undo visible after the server has already committed a permanent delete.
• Treating rollback failure as success because the item name reappeared.
• Saying Undo when the real action is open trash, recreate from template, request admin restore, or retry save.

Critique Questions

• What exact state is captured before the action, and what proof shows it can be restored?
• Can any external recipient, payment, webhook, permission change, or audit event still observe the action after Undo?
• Does Undo restore identity, order, relationships, labels, permissions, counts, selection, and focus context?
• What happens if the user performs another action before clicking Undo?
• When does the recovery window expire, and how does the UI show final commitment?
• Is this actually trash restore, autosave recovery, retry, confirmation, or support recovery rather than undo?