The first design crit I ran where someone got genuinely upset was about an undo affordance. The argument was familiar: "If we add undo, users will be careless." I think about that argument often. I have come to believe it is exactly backwards.
Forgiveness in interface design isn't permission to be sloppy. It's an acknowledgment that humans are, fundamentally, the operating system you're running on.
The three forgiveness primitives
Confirm, undo, and recover. Most teams use confirm and call it a day. Confirmation dialogs are the cheapest possible forgiveness — they don't require state, just a friction surface.
But undo is where the real respect lives. Undo says: I expect you to take action quickly, and I expect that sometimes you'll be wrong, and I've built for both.
And recovery — quietly restoring data the user thought they lost — is the highest form. Most teams never get there, because it requires infrastructure decisions made months before the affordance shows up.
The forgiveness budget
Every interaction has an implicit forgiveness budget. A side-project app can lean on confirm dialogs. A medical or financial product needs undo and recovery on the same surface, because the cost of being wrong is asymmetric.
Before you ship any destructive action, ask: what does the user lose if they're wrong, and what's the cheapest mechanism that lets them be wrong without losing it? That's the design problem. Everything else is just a button.
