Undo and Redo: Meaning, Design Rules, and UI Examples

Quick Answer

Undo reverses a user's previous action. Redo reapplies an action that was just undone.

In UI design, undo/redo is not only a keyboard shortcut pair. It is a recovery model that tells users, "You can try this, and you can come back." That feeling changes behavior: people edit more confidently, explore features more freely, and recover from mistakes without stopping their flow.

Term	Meaning	Common shortcuts
Undo	Reverse the last action and return to the previous state	`Ctrl+Z` / `Cmd+Z`
Redo	Reapply an action that was undone	`Ctrl+Y` / `Cmd+Shift+Z`

If an action can be safely reversed, prefer undo over a blocking confirmation dialog. If an action cannot be reversed, use confirmation, delay, review, or a clear recovery path instead.

Why Undo/Redo Matters

Without undo, users become cautious. They avoid trying new tools, hesitate before changing settings, and rely on repeated confirmation dialogs. A product may look simple, but every irreversible action creates mental friction.

Undo changes the contract. The interface becomes more forgiving because a mistake is not final. This is especially important in products where people create, edit, sort, delete, configure, or experiment.

Good undo design answers three questions:

What action will be reversed?
How long can the user recover?
What happens if the user performs another action before undoing?

If those answers are unclear, users may not trust the control even when it technically exists.

When to Use Undo

Use undo for actions where the system can restore the previous state without creating legal, financial, or data-integrity problems.

Strong candidates:

Editing text, images, layouts, canvases, or records.
Deleting, archiving, hiding, or moving items.
Bulk changes such as applying labels, changing status, or reordering a list.
Local settings that can be restored to their prior value.
Multi-step flows where users need to go back and correct earlier decisions.

Undo is especially valuable when the user is exploring. The more a product asks users to try, tune, compose, or compare, the more it needs recovery.

When Not to Use Undo

Do not promise undo when the product cannot actually reverse the action.

Be careful with:

Payments, transfers, purchases, and legally binding approvals.
Messages or emails already delivered to external recipients.
Destructive actions that trigger external APIs or downstream workflows.
Multi-user operations where restoring one user's state would overwrite someone else's later work.

For these cases, use a different recovery model:

A review step before commitment.
A short cancellation window before execution.
A trash/archive state before permanent deletion.
Explicit confirmation for rare, high-risk actions.

The key is honesty. A product should never label something "undo" if the real behavior is only "hide the mistake locally."

Undo vs Confirmation Dialog

Confirmation dialogs ask users to predict whether they are making a mistake. Undo lets users recover after they discover the mistake.

Use this rule:

If the action is common and reversible, use undo.
If the action is rare, destructive, and irreversible, use confirmation.
If the action is reversible for a limited time, show a toast with an undo action and make the time window visible or predictable.

For example, deleting a note can often be handled with "Note deleted. Undo." A payment submission should not be handled that way unless the system truly delays the transaction and can cancel it.

Design Rules for Undo/Redo

1. Make the Reversed Action Specific

Avoid a vague label like "Undo" when the context is not obvious. When possible, say what will happen:

"Undo delete"
"Undo archive"
"Undo status change"
"Restore 12 selected items"

Specific labels reduce anxiety. They also help users trust that the product remembers the right operation.

2. Keep Undo Discoverable

Keyboard shortcuts are not enough. Many users never discover them, and touch interfaces do not have the same shortcut model.

Use visible affordances:

Toolbar buttons for editor-like products.
Toast actions after delete/archive/move operations.
History panels for complex creation tools.
Menu items with shortcut hints for desktop-like web apps.

3. Define the Scope

Undo can be local, page-level, document-level, or account-level. Users need to know the boundary.

Examples:

In a text field, Cmd+Z should undo text entry in that field.
In a canvas editor, undo should affect the document or selected object.
In a list, "Undo archive" should restore the archived item, not reverse unrelated list sorting.

Ambiguous scope is one reason undo feels unreliable.

4. Preserve Order and Context

When undo restores something, put it back where users expect it.

If a deleted list item returns at the bottom of the list, the user may think the undo failed. Restore position, selection, focus, and visible context when possible.

5. Pair Undo With Redo in Editing Tools

If users can step backward multiple times, they can also go too far. Redo repairs over-undoing.

For editor-like products, redo is part of the same confidence loop. Without it, undo can become another irreversible action.

Example: Delete With Undo

A good delete flow avoids interrupting a common action but still protects the user.

Recommended pattern:

User selects "Delete" or presses a delete icon.
Item disappears immediately.
A toast appears: "Item deleted. Undo."
If the user selects Undo, the item returns to its previous location.
If the timeout passes, the item remains deleted or moves to a recoverable trash state.

Avoid this pattern when deletion is permanent and cannot be restored. In that case, confirmation is more honest than fake undo.

Implementation Checklist

Can the product restore the exact previous state?

Does undo restore order, selection, focus, and related metadata?

Is the undo action visible after destructive operations?

Are keyboard shortcuts supported where users expect them?

Is redo available when multi-step undo is available?

Does the interface explain time-limited recovery windows?

Are irreversible operations separated from reversible ones?

Have multi-user conflicts been considered?

Common Mistakes

Treating Confirmation as a Substitute for Undo

Confirmation dialogs do not help users recover. They only ask users to be certain before acting. For frequent reversible actions, this slows everyone down.

Hiding Undo Behind Shortcuts Only

Power users may know Cmd+Z, but many users will not. If undo is essential to safety, it should be visible.

Reversing Too Much

Undo should reverse the user's last meaningful action, not a hidden chain of system side effects. If a single visible action triggers several backend changes, the user-facing undo should still feel like one understandable recovery.

Forgetting Redo

When undo supports multiple steps, redo protects users from undoing too far.

Japanese source: Undo/Redoとは？意味・アンドゥ/リドゥとUI設計の使い方
Related principle: User Control
Related principle: Error Prevention
Related principle: Feedback

FAQ

What does undo redo mean?

Undo redo means the paired actions of reversing a previous operation and then reapplying it if needed. Undo goes backward in the action history. Redo moves forward again after an undo.

Is undo the same as cancel?

No. Cancel usually stops an action before it is committed. Undo reverses an action after it has already happened.

Should every delete action have undo?

Every common reversible delete action should have undo or a recoverable trash state. Permanent destructive actions need confirmation, review, or delayed execution instead.

Is redo always required?

Redo is most important when the product supports multi-step undo. For a single toast-based undo, redo is usually unnecessary.