Undo / Redo
Undo reverses your last action on a computer, like deleting text, moving a file, or changing a setting.
Redo brings back something you just undid. Together, they give you a safety net for experimenting without fear of making permanent mistakes. On Windows you press Ctrl+Z to undo and Ctrl+Y to redo. On Mac, it is Cmd+Z and Cmd+Shift+Z. They are two of the most important commands to know.
What it looks like
Undo / Redo, explained at three levels
At home
Undo is your computer's eraser: it takes back whatever you just did. If you accidentally delete a sentence, pressing Ctrl+Z brings it right back. Redo is the opposite: if you undo something and change your mind, Ctrl+Y puts it back. Most programs let you undo multiple steps in a row, so you can go back through several recent changes. It is one of the most reassuring features on any computer.
At work
In a business setting, undo and redo reduce the risk of data entry errors and encourage employees to experiment with formatting and design choices. Knowing that mistakes are easily reversible helps team members work more confidently. Most business applications support multi-step undo, letting users reverse a sequence of changes. Training materials should emphasize these commands as essential productivity tools.
At home
Undo and redo are implemented through action history stacks. Each undoable action is pushed onto an undo stack. When you press undo, the most recent action is reversed and moved to the redo stack. Performing a new action after undoing typically clears the redo stack. Some applications implement branching undo trees that preserve the full history of all actions, including alternative paths.
At work
In collaborative enterprise tools, undo behaviour becomes more complex when multiple users edit simultaneously. Real-time collaboration platforms must handle operational transformation or conflict-free replicated data types to manage concurrent undo operations. Understanding the undo model of business-critical applications helps set accurate user expectations. Some enterprise systems limit undo depth or disable it for certain operations to maintain data integrity.
At home
Technically, undo systems are typically implemented using the Command pattern, where each action is encapsulated as an object with execute and undo methods. Memento patterns store snapshots of application state for restoration. Complex applications may combine operation-based undo for fine-grained actions with snapshot-based undo for bulk operations. Memory management for undo history requires balancing depth against resource consumption.
At work
At the architecture level, undo capabilities in distributed systems require careful design around consistency and conflict resolution. Event sourcing architectures naturally support undo by replaying the event log with specific events removed. In regulated environments, undo operations must be auditable, creating an audit trail that shows not just the final state but the complete history of changes. Designing undo for complex business processes (like reversing a multi-step approval workflow) requires domain-specific logic beyond simple state restoration.
Real-world examples
At home
Jerome is editing a family photo and accidentally applies a filter that ruins the image. He panics for a second, then presses Ctrl+Z three times. Each press reverses one step, taking the photo back through each change until it looks perfect again. He breathes a sigh of relief, grateful for the undo button.
At work
Fatima, a financial analyst, accidentally overwrites a formula in a critical spreadsheet cell. Instead of trying to recreate the complex formula from memory, she presses Ctrl+Z to undo the change. The original formula reappears instantly. She presses Ctrl+Z a few more times to confirm nothing else was affected, then uses Ctrl+Y to redo the steps that were correct.
Common confusions
- It's a popular misconception that undo works the same everywhere. Some applications only support one level of undo, while others support dozens or unlimited levels.
- A frequent misconception is that undo can recover anything. Some actions like permanently deleting files or closing without saving may not be undoable.
- There's a widespread belief that redo and repeat are the same. Redo restores something you just undid, while repeat performs the same action again on new content.
For analysts
When specifying requirements for any application where users edit content or data, always include undo and redo as a core requirement. Define how many levels of undo are needed and which actions should be undoable. For collaborative applications, clarify how undo should behave when multiple people are editing the same content. Users expect undo to work reliably, and its absence or inconsistency is a frequent source of frustration.
History & origin
The undo command was conceived by Warren Teitelman in the late 1960s as part of his work on the BBN-LISP programming system. It gained mainstream attention when Apple incorporated it into the Macintosh in 1984 as a standard Edit menu command. Multi-level undo, which allows you to reverse multiple consecutive actions, became common in the 1990s and is now expected in virtually every application.