Redo reapplies the most recent undone operation while the edit history branch is still valid. Use undo for reversal, draft state for persistent unpublished versions, and command palette for invoking commands rather than defining history semantics.
Redo reapplies the most recent undone operation while the edit history branch is still valid. Use undo for reversal, draft state for persistent unpublished versions, and command palette for invoking commands rather than defining history semantics.
Practice the judgment: Imagine this situation: Redo remains enabled after a new edit creates a different history branch and replays stale work over the user's current state. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Redo | Undo | Draft state | Command palette |
|---|---|---|---|---|
| UI or UX | UX - Forward edit-history replay | UX - Post-action recovery behavior | UI + UX - Unpublished object version lifecycle | UI + UX - Modal command surface |
| UI guidance | Show Redo as a visible command, menu item, toolbar control, or command-palette row whose enabled state matches the current redo stack. | 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. | Label the current version explicitly as Draft, Unpublished changes, Published, Active, Locked, or Unavailable, and place that label near the object title, list row, editor header, and publish actions. | Render a compact dialog-like command surface with a search input, current scope, typed command mode, active result, command metadata, and empty state. |
| UX guidance | Help the person reach a clear task outcome. | Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result. | Use draft state when users need to pause work on an object, return later, and decide whether to publish, activate, discard, or keep editing an unpublished version. | Accelerate expert navigation and repeated actions across a large product while preserving ordinary navigation for novice and low-frequency users. |
| Good UI | A document toolbar shows Undo and Redo; Redo is disabled until the user undoes Move Summary before Risk. | Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button. | A knowledge article header says Draft saved today, shows the currently published title, and offers Resume draft, Compare with published, Discard draft, and Publish. | Centered command surface with input, shortcut hint, scope chip, grouped commands, command type labels, and a visible active row. |
| Bad UI | Redo silently replays against the wrong selected object. | Undo action disappears before users can activate it. | A draft label is missing from the editor, so users publish or discard the wrong version. | Huge branded modal that buries the input below decorative content. |
| Good UX | A user moves a heading, chooses Undo, sees Redo move heading become available, and redoes the same move against the same document outline. | Undo restores the deleted task to the list and reports Quarterly report restored. | A user opens a published article that has an unpublished version, chooses Resume draft, reviews a change summary, publishes, and sees the page become visible to viewers. | Keyboard shortcut or visible trigger opens the palette, focus lands in the command input, arrows move the active row, and Enter activates the highlighted safe command. |
| Bad UX | A user undoes a move, selects a different heading, presses Redo, and the product applies the old operation to the wrong target. | The UI promises undo for a side effect that has already notified external recipients. | A user discards a shared draft and unknowingly removes another editor's unpublished changes. | Palette is the only way to reach important navigation. |
| Best fit | Users perform reversible sequences of edits and can undo too far. | The action is common and mistakes are likely. | Users need to pause and resume unfinished work across sessions, devices, or routes. | Users need to traverse a broad product surface quickly. |
| Avoid when | The action has irreversible external side effects. | Recovery would restore only part of the user's lost work. | The change is a small one-field edit that should be saved or canceled immediately. | The app has only a few obvious actions. |
| Required state | Undo-available state after a reversible edit. | Normal state before the user action. | Published or active state with an available draft. | Closed state with discoverable trigger. |
| Accessibility burden | Expose Redo as a named button, menu item, or command row when editing commands are visible. | Make the undo control keyboard reachable and programmatically identifiable. | Use headings and status regions so screen reader users know whether they are editing a draft or viewing the active version. | Use dialog semantics with a clear name and modal behavior when the rest of the page is inert. |
| Common misuse | Leaving redo enabled after a new edit invalidates the undone future. | Restoring only part of the prior state while implying full recovery. | Using Saved to mean both saved draft and published content. | Hiding basic navigation behind a keyboard-only palette. |