{"slug":"confirmation-vs-undo","meta":{"title":"Confirmation vs Undo","slug":"confirmation-vs-undo","kind":"decision","summary":"Whether an action should ask \"are you sure\" or just happen with a way back. The answer is decided by reversibility and blast radius, not by how dangerous the verb sounds.","problem":"Confirmation gets applied by feel, so it lands on the wrong actions — a dialog on archiving one item that someone does forty times a day, and none on the bulk delete that cannot be undone. Once everything is confirmed, people click through confirmations without reading, and the protection is gone anyway.","family":["act","recover"],"data_shape":["record"],"principles":["friction","orientation"],"interaction":["decision"],"density":"low","complexity":"low","status":"stable","visibility":"public","use_when":["You are adding a destructive or hard-to-reverse action.","An existing screen confirms everything, or nothing.","People report both \"too many pop-ups\" and \"I lost work\" about the same product."],"avoid_when":["The action is a pure navigation or a read. Neither mechanism applies."],"alternatives":[{"slug":"review-queue","when":"The action repeats hundreds of times a day — that volume settles the question by itself."},{"slug":"unsaved-changes-guard","when":"The risk is losing work in progress rather than performing an action."}],"ask_leo":"Decide per action whether it confirms or offers undo, and apply the rule\nconsistently across this app.\n\nIf the action is reversible and affects one record, do it immediately and show\na brief message with an Undo control. Keep the undo available for at least ten\nseconds, and make undo restore the exact previous state, not an approximation.\n\nIf the action is irreversible, or affects many records at once, or is visible\nto someone outside the company — sending an email, issuing a refund, deleting\na customer — confirm first. The confirmation must name what will happen and\nhow much: \"Delete 43 invoices? This cannot be undone.\" Never a bare \"Are you\nsure?\".\n\nFor the most severe irreversible actions, require the person to type the name\nof the thing being destroyed.\n\nDo not confirm an action that people perform many times a day. If it is\nfrequent AND irreversible, make it reversible instead — that is the real fix.\n\nNever show two confirmations in a row for one intent.\n","related":[{"title":"Review Queue","url":"/patterns/review-queue","summary":"The clearest case where undo beats confirmation, because the action repeats all day."},{"title":"Eliminating friction","url":"/patterns/friction","summary":"Why a confirmation is a tax charged to everyone to protect against a few."}]},"body":"## The decision\n\nTake the first row that matches.\n\n| If this is true | Use | Because |\n|---|---|---|\n| The effect leaves your system — an email sent, a payment taken, a webhook fired | **Confirm** | Nothing you build can recall it |\n| The action is irreversible in the data | **Confirm**, and name the count | Undo would be a lie |\n| It affects many records at once | **Confirm**, and name the count | The blast radius is the risk, not the verb |\n| It happens many times a day | **Undo** | A dialog here costs more than the mistakes it prevents |\n| It is reversible and affects one record | **Undo** | Cheaper, safer, and does not train click-through |\n| None of the above | **Undo** | The safer default: it protects without taxing |\n\nTwo things are deliberately absent from that table: how destructive the verb\n*sounds*, and how nervous the person who requested the feature feels. \"Archive\"\nsounds gentle and \"Delete\" sounds severe, but if archive is irreversible and\ndelete is a soft flag, the correct treatments are the other way round.\n\n## Why undo is usually the better instrument\n\nA confirmation dialog charges **every** user on **every** invocation to protect\nagainst a mistake **some** users make **occasionally**. Undo charges nothing up\nfront and pays out only when needed.\n\nIt is also more honest about how people work. Nobody reads the fifth identical\nconfirmation, so confirmation on frequent actions does not prevent errors — it\nconverts them into errors made slightly later, after a reflexive click. The\ndialog produces the feeling of safety without the fact of it.\n\n## When confirmation genuinely wins\n\n**Irreversibility is the real trigger.** If you cannot offer undo, you owe the\nperson a moment of attention instead — and the way to spend it well is\nspecificity: what, how many, and that it cannot be taken back.\n\n**Blast radius is the second.** One archived record is a mistake; forty deleted\ninvoices is an incident. Bulk actions deserve confirmation even when a single\none does not, which means the same verb can be correct both ways in one product.\n\n**Leaving the system is the third.** A sent email cannot be unsent. A short\nsend-delay window is a real alternative here — it is undo, implemented as a\ndelay — and it is usually better than a dialog.\n\n## Making undo real\n\nThe failure mode of undo is that it is approximate. If undoing a delete restores\nthe record but drops its attachments, or restores it at the bottom of a list\ninstead of its original position, people learn not to rely on it, and you now\nhave neither mechanism.\n\n- Restore the exact previous state, including position and related records.\n- Keep the affordance visible long enough to be used — ten seconds is a common\n  floor, longer for bulk actions.\n- Say what happened. \"Archived\" alone is not enough; \"Invoice INV-1041\n  archived\" is.\n- Put the undo in the same place every time, so it is a habit rather than a\n  hunt.\n\n## Getting it wrong\n\n- **\"Are you sure?\"** — the least useful sentence in software. Sure about what,\n  affecting how much?\n- **Confirming everything**, which trains click-through and removes the\n  protection from the actions that needed it.\n- **Undo on something irreversible**, which is a promise the system cannot keep.\n- **Two dialogs for one intent**, which reads as the software not knowing what\n  it wants.\n- **A toast that disappears in two seconds**, which is decoration, not recovery.\n\n## Exemplars\n\n**Gmail's undo send** is the strongest example in consumer software: the action\ngenuinely leaves the system, and rather than adding a dialog they added a delay\nand made undo possible. That is the move worth stealing — change the\nreversibility instead of adding friction.\n\n**GitHub's repository deletion** shows the other end done properly: type the\nrepository name to proceed. Irreversible, high blast radius, rare — exactly the\nregime where a confirmation should be *harder*, not softer.\n\n**macOS Finder** trashes rather than deletes, which converts nearly every\ndestructive file action into a reversible one. Most confirmation debates\ndisappear once someone asks whether the action could simply be made reversible.\n\nThe extractable rule: **confirmation and undo are not two styles, they are two\nanswers to one question — can this be taken back?** Answer that first, and the\ninterface follows.\n"}