BBMM Technologies
← All articles
6 min readundo, interaction, error-prevention, engineering

Designing Undo: Forgiveness as a Feature

By Mykhailo Boichuk · Co-founder & Vice-President

In short

Undo turns mistakes from disasters into minor inconveniences, which lets people work faster and more confidently. Designing it well means making actions reversible by default, defining a clear scope for what undo affects, and preferring recovery over confirmation prompts. The engineering cost is real because reliable undo shapes how state is modeled, but the payoff is an interface people trust enough to explore.

Forgiveness changes how people work

When a mistake is cheap to reverse, people act more freely and explore more, because the cost of being wrong is small. When mistakes are permanent, people slow down, hesitate, and avoid features they are unsure about. Undo is the mechanism that buys this confidence. It is not a convenience bolted on at the end but a property that shapes how willing users are to use the product at all.

The contrast with confirmation dialogs is instructive. A confirmation interrupts every action, including the overwhelming majority that were intended, to prevent the rare mistake. Undo inverts this: it lets every action proceed immediately and provides a remedy for the rare case that was wrong. For most actions, undo is the more respectful design.

Reversible by default

Designing for undo means treating reversibility as the default and irreversibility as the exception that must be justified. Deleting an item can move it to a recoverable state rather than erasing it. Sending can hold briefly before committing. Each irreversible action is a place where the user can be permanently harmed by a slip, and each one deserves scrutiny.

  • Make destructive actions reversible for a window rather than immediate and final.
  • Reserve true confirmation for actions that genuinely cannot be undone.
  • Tell the user that an action can be undone, so they feel free to proceed.

Scope and clarity matter

Undo is only trustworthy if the user understands what it will reverse. Ambiguous scope, where the person cannot tell whether undo affects the last keystroke, the last action, or the last several, breeds caution rather than confidence. The unit of undo should match the user’s mental model of a single action, and the interface should make clear what pressing undo will restore.

Reliable undo is an architectural decision, not a feature added late. Retrofitting it onto state that was never designed to be reversed is far more expensive than modeling actions as reversible from the start.

Key takeaways

  • Undo lets people act and explore without fear of permanent mistakes.
  • It is usually more respectful than confirmation dialogs that interrupt every action.
  • Treat reversibility as the default and irreversibility as the justified exception.
  • Make the scope of undo match the user’s idea of a single action.
  • Design for undo early, because retrofitting it onto existing state is costly.

Frequently asked questions

Why prefer undo over confirmation dialogs?
Confirmations interrupt every action to prevent rare mistakes, while undo lets every action proceed and provides a remedy only for the rare case that was wrong.
What makes undo trustworthy?
A clear scope that matches the user’s idea of a single action, so they know exactly what pressing undo will restore.
Is undo expensive to build?
It can be, because reliable undo shapes how state is modeled. Designing actions as reversible from the start is far cheaper than retrofitting undo later.

References

About the author

Mykhailo Boichuk

Co-founder & Vice-President

Mykhailo is an engineer who builds native applications and the systems behind them. He concentrates on macOS and iOS performance, local-first data architecture, and the synchronization problems that come with offline-capable software.