To err is human. Pope wrote that in 1711, and three centuries later it is still the most important sentence in software design. People are going to make mistakes. Not occasionally, not the careless ones among us. Everyone, constantly. It is the starting condition, and any system that takes input from a user has to be designed from it.
Which is probably why undo was never invented once. It kept getting invented. A system at Brown had it in 1968. A Lisp programming tool had it by 1971. Xerox PARC put it in a text editor in 1974. These people were not copying each other. They were all watching the same thing happen: a person at a keyboard, doing something they did not mean to do, with no way back. When the Macintosh shipped, Undo sat at the top of the Edit menu. It still does.
So the rule I design by: wherever there is user input, there has to be a way to correct it. Self-serve wherever possible, a button, an edit, a window of time to change your mind. And where self-serve genuinely cannot work, an easy path to something that can correct it, another system or an actual human. Amendment or undo, in one form or another, everywhere input exists. It is not a feature to add when there is time. It is part of what accepting the input means.
Where it gets hard is the guardrails, and I will be honest: there is no formula for those. It is circumstance based. What decides it is the consequences of the undo itself. Before I let a user reverse something on their own, I want the action mapped, upstream and downstream. What consumed this input? What already acted on it? If the damage from reversing is contained, hand the user the button and get out of the way. If the reversal ripples into other systems and other people, self-serve is the wrong tool. That correction needs a process, checks, maybe a human reviewing it. The mistake gets corrected either way. The route is what changes.
The map has a clock on it too. Ask whether the mistake’s ramifications are permanent, and whether they have already landed. Order something online and you can cancel it, but the window depends on the vendor: zero minutes from one, fifteen from another. Then the order ships and the window does not narrow. It ends. Anyone who has tried to get UPS or FedEx to intercept a package or reroute it midstream has felt the far side of that line. The act left the database and entered the physical world, and only the database part was ever reversible.
Some of that is just physics, and physics is not a design flaw. Some of it is complexity that got baked in for reasons nobody remembers. Either way, once the act itself cannot be undone, the question changes to whether its consequences can be amended. You cannot un-ship a box. You can return it, refund it, send the right one. And the amendment has a simple test. It worked when whatever the user intended to achieve is achieved. Not when the ticket closed. When the person ends up where they were trying to go.
Gmail’s Undo Send is the famous version of this. Launched in 2009, and it has never recalled a single email. It delays the send, five seconds at first, up to thirty now, so the undo is really a grace period with good marketing. I mean that as praise. Where reversal is impossible, time is the substitute. A window before the act becomes real, and where that fails, an amendment after.
Given all that, why do so many systems give you no way back at all? Collect the reasons and they are mostly unglamorous. Complexity. Oversight. Cost. A dependency on some external party whose system will not cooperate. A product team that never foresaw the need. A mistake so rare that building the correction never survived prioritization. Those are engineering economics, and some of them are even true. But there is one more reason on the list, and it is not like the others. Sometimes there is no undo because no undo is the business model. A flow that takes ten seconds to enter and ten days to leave is not an accident. It is somebody’s decision, taken for gains.
Here is the part that should bother us. From the user’s chair, there is no way to tell those reasons apart. The screen does not say whether the correction path is missing because it could not be built, or because somebody chose not to build it. It is just not clear, not until the user makes the mistake and goes looking for the undo that may or may not be there. That is when a system shows you what it thinks of you. Ideally before you need to know.