The Undo Button Is a Moral Position

The most generous feature in any piece of software is the one nobody puts on a landing page. Undo does not demo well. It has no onboarding tour, no confetti, no metric attached to it. And yet it quietly decides what kind of person you are allowed to be while you work: careful and afraid, or curious and a little reckless.[1]

I have been thinking about undo for most of this year, partly because of a client project and partly because I noticed how differently I behave in tools that have it. In my text editor I write badly on purpose, knowing I can take it back. In my banking app I hold my breath before every tap. Same person, same afternoon, two completely different temperaments, and the only thing that changed was the price of being wrong.

This essay is my attempt to write down what I have learned about that price: who sets it, who pays it, and why I have come to think of it as a moral decision rather than a technical one.

The price of a mistake

Every tool sets a price on mistakes, whether its makers notice or not. A text editor with fifty levels of undo makes a wrong paragraph cost nothing. A form that clears itself when you press back makes the same mistake cost ten minutes and some of your trust. The difference is not technical. Both are choices about who carries the risk: the person using the tool, or the tool itself.[2]

When I review interfaces for clients, I now ask one question before anything else: what happens if I am wrong here? The answer tells me more about the product than any style guide. If the honest answer is you lose your work, no amount of polish on the rest of the screen will make people relax. They will move slowly, second-guess every field, and blame themselves when something breaks.

That last part matters most. People rarely blame software for a lost afternoon. They blame themselves for not being careful enough, and then they become careful, and careful people explore less, try fewer things and learn the tool more slowly. An expensive mistake doesn't just cost the moment it happens; it costs every curious moment afterwards.

You can see this in almost any team that has used the same tool for a few years. There is usually one person who knows which buttons are safe, and everyone else routes around the rest. The unsafe corners of the product go quiet. Nobody files a bug about them, because nothing is technically broken. They have simply been priced out of use.

Undo is a promise about time

We usually describe undo as a feature, but it is closer to a promise. It says: for a while, the past is still editable. What you did a minute ago is not final yet. You are allowed to look at the result before you decide whether you meant it.

That promise changes the order in which people think. Without undo, you have to imagine the outcome before you act, which is slow and, for most of us, unreliable. With undo, you can act first and judge the result with your eyes. Designers call this direct manipulation; I think of it as being allowed to think with your hands.[3]

The length of the promise matters too. An undo that lasts one step teaches people to act in single, careful moves. An undo that reaches back through the whole session lets them wander, try three wrong things and return. An undo that survives closing the app, the kind version history gives you, lets them stop worrying about the session altogether. Each extra hour of promise buys a little more courage.

This is why I don't treat the depth of undo as a performance setting. It is a statement about how much of the past the product is willing to hold for you. Some products hold a lot, and you can feel it in the way people use them: fast, loose, a little playful. Others hold nothing, and people use them like they are defusing something.

I noticed this first in myself. In a drawing app with a long history, I will try a colour I am fairly sure is wrong, just to see it next to the others, and step back three times if I was right. In a spreadsheet that only remembers one step, I copy the whole sheet before I change a formula. Nobody taught me either habit. The tools did, by telling me in the only language software has, what it would forgive.

Confirmation is not the same as care

The lazy version of safety is the confirmation dialog. It feels responsible, but it moves the work of being careful back onto the person, at exactly the moment they have already decided. After the third dialog, nobody reads them. Undo is the opposite: it lets you act first and think afterwards, which is how most people actually think.[4]

• Confirmation asks you to be careful before you know enough.

• Undo lets you learn by doing, then take it back.

• Confirmation interrupts every action; undo only costs something when you use it.

There is a place for confirmation: actions that truly cannot be reversed, like sending money or deleting an account for good. But those should be rare, and they should feel different from everything else. When every button asks are you sure?, the one that really means it sounds exactly like the others.[5]

I once audited a settings page that asked for confirmation eleven times. Ten of those actions could have been undone with a single toast. The eleventh deleted a workspace and every file in it, and its dialog looked exactly like the dialog for changing a colour theme. The team was surprised when I showed them. They had added each dialog for a good reason, one at a time, and never looked at them together.

Where undo quietly fails

Most products have undo somewhere. The interesting question is where it stops working, because that edge is where people get hurt.

The first edge is collaboration. Undo is easy to reason about when one person edits one document. When four people edit it at once, undo can mean "take back my last change" or "take the document back to how it was a minute ago", and those are very different things. Good tools choose the first and explain it; bad tools pick one silently and let people discover the other.[6]

The second edge is sync. A change that has left your device and reached a server, a phone and a colleague's laptop is harder to take back, so many products quietly stop offering undo the moment something syncs. From the outside it looks like the feature disappeared for no reason. From the inside it is a cost the team decided not to pay.

The third edge is anything that touches the outside world: an email sent, a message posted, a payment made, a file shared with a link. These cannot be undone in the strict sense, but they can almost always be delayed, and a delay is a kind of undo.[7] A thirty-second window before something leaves the building covers most regret, which tends to arrive in the first few seconds.

The last edge is the one I see most often in client work: bulk actions. Deleting one item has an undo; deleting two hundred, from a filtered list, does not, because nobody designed the bulk version. It is exactly the action where people most need a way back.

What these edges have in common is that they are invisible until you fall off one. The interface looks the same on both sides: the same button, the same colour, the same short animation. Only the consequence is different. If a product has to have edges like this, and most do, the least it can do is mark them, so that the moment you step from reversible to permanent feels different in the hand.

Designing the reversible version

When a team agrees that something should be reversible, the next question is always how. Over the years I have ended up with four patterns that cover almost everything. None of them is new, and that is the point: they are boring enough to be built in a sprint.

Soft delete. Nothing is removed straight away; it is marked as removed and hidden. A trash view shows what has gone and when, and a quiet job empties it after thirty days. The person sees a clean list immediately, and the product keeps a month of second thoughts in the back room. It costs a column in a database and a screen most people never open.

The undo toast. After an action, a small message appears with a single button: undo. It stays for eight to ten seconds, long enough to notice a mistake but short enough not to clutter the screen. The important detail is that the action has already happened when the toast appears. The person is not being asked; they are being offered a way back.

The delay. For anything that leaves the building, wait before sending. The interface shows the message as sent, with a small countdown and a way to pull it back. Most people never notice the delay, and the few who need it are grateful every time.

Versions. For documents, settings and anything people build up over time, keep snapshots and let people browse them. This is the most expensive pattern and the most powerful, because it turns the past into something you can look at instead of something you have to remember. When people know that yesterday's version still exists, they rewrite today's with much less fear.

Choosing between them is mostly a question of how far back regret usually reaches. For a message it is seconds, so a delay is enough. For a deleted file it can be weeks, so soft delete makes sense. For a document it can be months, and only versions will do.

What undo asks of the people who build it

Undo is expensive to build well. Every action has to be recorded, every change has to know how to reverse itself, and collaboration makes all of it harder. That cost is exactly why it is a moral position rather than a feature: a team that builds undo has decided to spend its own time so that the people using the tool can spend less of theirs being afraid.

The cheapest version is still worth doing. A trash folder instead of instant deletion. A toast that says archived, undo for ten seconds. A draft saved every few keystrokes. None of these are clever. All of them move risk from the person to the software, where it belongs.[8]

It also asks something of the rest of the design. If you know an action can be undone, you can make it fast: one tap, no dialog, no second screen. Undo is what earns you the right to remove friction everywhere else. Teams that skip it end up adding friction back one dialog at a time, and the product gets slower and more nervous with every release.

There is a management version of this too. Teams that can roll back a release ship more often and more calmly than teams that can't, for the same reason people write more freely in an editor with undo.[9] Reversibility is not only a user-interface idea. It is how any group of people gets brave enough to try things.

A small rule

So here is the rule I try to design by: if an action can be reversed, do not ask; if it cannot, make it slower, not scarier. It is a small rule, and it has changed almost every interface I have touched this year. The screens got calmer, the support emails got shorter, and at least one client told me their team started trying features they had been avoiding for months.

When the rule is hard to follow, it is usually because the reversible version hasn't been built yet. That is not a reason to reach for a dialog. It is a line on the roadmap, and I have learned to write it down as one, with the same weight as any feature a customer asked for.

That, in the end, is what undo buys: permission to be curious. It is the quietest feature in any product and, I have come to think, one of the kindest.[10]