Undo

Problem Context

• The action is frequent enough that pre-action confirmation would slow users down or become automatic.
• Mistakes are plausible because users act quickly, work in lists, use shortcuts, or perform repeated cleanup.
• The system can restore the affected object, value, order, selection, or relationship accurately.
• The action has no irreversible external effect before the recovery window closes.

Selection Rules

• Choose undo when the product can restore the exact prior state without data loss or unrecoverable side effects.
• Use undo for frequent archive, dismiss, move, reorder, delete-to-trash, bulk cleanup, and formatting changes where users benefit from acting first.
• Use a persistent restore location instead of a short recovery notice when the consequence is important or users may need more time.
• Use confirmation before the action when money, permissions, production data, emails, webhooks, or permanent deletion cannot be recalled.
• Do not offer undo unless the system has already captured enough state to restore object identity, order, relationships, and visible counts.
• Do not hide undo in a disappearing message if assistive technology users, keyboard users, or distracted users cannot reasonably reach it.
• Use clear feedback when the undo window expires or when the action has been committed permanently.

Required States

• Normal state before the user action.
• Completed-but-recoverable state that names what changed and exposes an undo control.
• Restored state after undo returns the exact object, value, order, or selection.
• Committed final state after the recovery window expires or the user confirms finalization.
• Unavailable state when undo cannot be offered because the action has external or irreversible effects.
• Multiple-action state where each recoverable action is either queued, grouped, or clearly scoped.

Interaction Contract

• The undo affordance appears after the action completes and names what will be restored.
• Undo restores the affected state exactly enough that the user can trust it.
• The recovery control is keyboard reachable and remains available long enough for users to perceive and activate it.
• The interface reports whether the action is recoverable, restored, expired, or permanently committed.
• Focus is not unexpectedly stolen from the user's workflow when a routine recoverable action completes.
• If multiple actions are recoverable, the UI makes the scope of each undo action clear.
• Undo is not offered for effects that have already left the system boundary and cannot be recalled.

Implementation Checklist

• Capture the prior object, value, position, relationship, and selection state before applying the action.
• Display a recovery notice close to the action result or in a consistent status region.
• Label the action with the object or operation, such as Undo delete or Restore report.
• Keep the undo control keyboard reachable and visible long enough to use.
• Provide a committed or expired state so users know when recovery is no longer available.
• Restore focus, counts, ordering, and selection predictably after undo.
• Avoid combining undo with pre-action confirmation for the same low-risk routine action.
• Escalate to persistent history, trash, version rollback, or admin recovery when a short recovery window is insufficient.
• Do not claim undo support until integration, storage, notifications, and external effects can actually be reversed.

Common Generated-UI Mistakes

• Offering undo for an action that cannot actually be reversed.
• Showing a recovery control so briefly that users cannot perceive or reach it.
• Restoring only part of the prior state while implying full recovery.
• Using a vague Undo label when several actions could be undone.
• Stealing focus to a transient notice after every routine action.
• Pairing a confirmation dialog and undo for ordinary cleanup actions, adding friction without extra safety.

Critique Questions

• What exact state is stored so the action can be reversed?
• Can any external recipient, payment, permission, notification, or webhook still observe the action after undo?
• How will users know whether the action is recoverable, restored, expired, or committed?
• Is the recovery affordance reachable by keyboard and visible long enough?
• What happens when users perform several recoverable actions in a row?
• Would a persistent trash, version history, or rollback log be safer than a short undo notice?