On this page
Scott
Undo and redo are safety controls for creative work. They should make the last reversible change obvious, preserve the user’s place, and explain what will be restored. Begin with a clear history model, then test compound actions and collaboration conflicts. A shared UI design collaboration workspace helps teams review the before-and-after states instead of debating an abstract rule.
Model the change history users can predict
Users do not need an implementation diagram; they need to know what one undo will remove. Group actions by the user’s intention, not every low-level property update. “Move card and update its label” can be one history step when both changes came from a single gesture. Keep the label concrete enough to identify the affected object.
- Show the action name and the object or area it affects.
- Keep undo and redo available while the history has a valid next state.
- Do not silently discard a branch when a new edit is made; explain what happens.
Design recovery for destructive or expensive edits
For deletion, bulk replacement, or a long-running generation, offer a reversible path close to the action. A toast can restore a small change; a confirmation dialog is useful when the consequences are broad or the action cannot be undone. Do not use a confirmation dialog to compensate for an unclear button label.
When undo restores a previous state, keep the viewport, selection, and focus stable whenever possible. If the user cannot see what changed, show a short highlight or a before-and-after preview. Recovery should reduce investigation, not create a second mystery.
Handle branches, shortcuts, and collaboration
Keyboard shortcuts should match the visible controls and work with the user’s platform conventions. If a new edit after undo creates a new branch, tell the user whether redo is still available. In a collaborative file, distinguish a local undo from reversing another person’s change; never imply that a personal undo rewrites the whole team’s history without confirmation.
- Test a single edit, a grouped edit, and a bulk edit.
- Test undo after switching frames, pages, or selection.
- Test a concurrent change and a reconnect after offline work.
- Test the empty-history and end-of-history states.
Make the branch rule visible
Consider a user who moves a card, presses Undo, and then changes its title. The title edit starts a new branch. If the earlier move is no longer available through Redo, say so in the history and keep the restored card position intact; if both branches can be recovered, show which one the next action selects. Test the sequence as a visible story: move, undo, edit, inspect Redo, reload, and reconnect. A user should never discover the branch rule only after losing work.
Check the boundary states
| State | Expected feedback |
|---|---|
| Empty history | Undo is unavailable and no stale action label is shown. |
| End of history | Redo is unavailable after the newest state is restored. |
| Reconnect after offline work | The user can tell which local changes were kept, merged, or need review. |
| Concurrent edit | Undo identifies the local change and does not imply that a teammate’s edit was erased. |
Review the recovery path in the prototype
Use a prototype to walk through the accidental-change story: make the edit, undo it, verify the restored state, and redo it. In Pixso, place the history states beside the main screen and leave a comment that names the expected recovery result. This gives reviewers a concrete path to inspect before the control is handed to development.
Measure success by recovery confidence: can someone identify the affected change, restore it, and continue without losing unrelated work? If not, simplify the history language or move the recovery affordance closer to the consequence.
