UX Patterns Guide
UX Error Prevention And Recovery established

Undo

Let the action complete, preserve the exact prior state, report what changed, expose a clearly labelled recovery control, and resolve to either restored state or committed final state.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • The action is common and mistakes are likely.
  • The exact prior state can be restored reliably.
  • Pre-action confirmation would slow users down or create habituation.
  • The action can be held locally, queued, or reversed before irreversible side effects occur.

Avoid when

  • The action has external side effects that cannot be recalled.
  • Recovery would restore only part of the user's lost work.
  • The consequence is severe enough that users need to understand it before the action happens.
  • The system cannot preserve enough state to restore identity, order, relationships, or permissions.
  • A short recovery notice would disappear before affected users can reasonably act.

Problem it prevents

Users need to recover from common reversible actions after acting quickly, without being blocked by confirmation prompts before every low-risk command.

Pattern anatomy

What a strong implementation has to make clear

User need

The action is frequent enough that pre-action confirmation would slow users down or become automatic.

Pattern promise

Let the action complete, preserve the exact prior state, report what changed, expose a clearly labelled recovery control, and resolve to either restored state or committed final state.

Required state

Normal state before the user action.

Recovery path

Undo action disappears before users can activate it.

Access contract

Make the undo control keyboard reachable and programmatically identifiable.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button.
  • The recovery panel also exposes a commit outcome so users can see when the deletion is final.
  • Undo restores the deleted task to the list and reports Quarterly report restored.
  • Committing deletion removes the recovery action and reports that the deletion is final.
Weak implementation

Vague, hidden, hard to recover from

  • A tiny x removes an item with no object-specific recovery label.
  • A toast says Done and vanishes without a keyboard reachable undo control.
  • A second delete overwrites the first recoverable item without explaining which action Undo affects.
  • The UI promises undo for a side effect that has already notified external recipients.
UI guidance
  • Show a named recovery affordance after the completed action, such as Undo delete for a specific task, near the result or in a consistent status region.
  • Keep the recovery control visible, keyboard reachable, and paired with clear restored or committed status instead of relying on an ambiguous disappearing message.
UX guidance
  • Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result.
  • Use undo only when the product can faithfully restore the prior state and clearly communicate when recovery is no longer available.
Implementation contract

What the implementation must handle

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.

Interaction

  • 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.

Accessibility

  • Make the undo control keyboard reachable and programmatically identifiable.
  • Announce the completed action and recovery availability without forcing focus away from the current task.
  • Do not make recovery depend only on a fast disappearing visual toast.
  • Expose committed, expired, and restored outcomes in a status region.

Review

  • 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?
Interactive lab

Inspect the states before you copy the pattern

Recover after a completed action

Delete an item, inspect the undo window, and watch the final committed state.

Undo
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Normal state before the user action.

Keyboard / Access

Visible undo controls must be reachable in the normal tab order or through an established command shortcut.

Avoid Generating

Offering undo for an action that cannot actually be reversed.
Evidence trail

Source-backed claims behind this guidance

Material Design: Snackbars

Google Material Design - checked

Material snackbar guidance includes undo actions for amending recent choices after the action completes.

Full agent/debug reference

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?
Accessibility
  • Make the undo control keyboard reachable and programmatically identifiable.
  • Announce the completed action and recovery availability without forcing focus away from the current task.
  • Do not make recovery depend only on a fast disappearing visual toast.
  • Expose committed, expired, and restored outcomes in a status region.
  • Keep labels specific when several actions could be undone.
  • Respect reduced-motion preferences for any animated recovery notice.
Keyboard Behavior
  • Visible undo controls must be reachable in the normal tab order or through an established command shortcut.
  • Common platform shortcuts can supplement visible controls but should not be the only recovery path.
  • Routine actions should not move focus unexpectedly to the notice.
  • Activating Undo restores the item and leaves focus in a predictable location near the restored object or original trigger.
  • If the recovery window expires, keyboard focus must not remain on a removed control.
Variants
  • Toast undo
  • Snackbar undo
  • Persistent restore from trash
  • Version rollback
  • Undo stack
  • Redo
  • Bulk action undo
  • Time-delayed commit

Verification

Last verified: