Confirmation dialogs are a ritual
We instrumented the confirm dialogs in a procurement tool at Orbit Supply for six weeks. Ninety-two per cent were dismissed in under 1.5 seconds — faster than the modal text can be read. The dialog was not a decision point; it was a keystroke people had learned. The two destructive incidents in that period both passed through it without pause.
The dialog does have a legitimate narrow use: interrupting a habit for something rare and irreversible. Used for every delete, it trains the exact reflex it was meant to prevent. If an action happens fifty times a day, no wording will make the fifty-first click deliberate.
Three classes of action, three treatments
Reversible actions — archiving, tagging, reordering, most edits — should just happen, with an undo affordance available for around 30 seconds and a permanent record in the item's history. No dialog. The interaction cost of undoing on the rare mistake is far lower than the aggregate cost of confirming every time.
Consequential but recoverable actions — changing a purchase order line after approval, reassigning a case — happen immediately but require a correction path rather than a delete: a new entry that supersedes the old one, carrying a reason code and the author. Finance and audit teams need the original to remain visible, and an interface that silently overwrites makes that impossible.
Irreversible or externally visible actions — releasing a payment, sending an RFQ to 400 vendors, publishing an auction — get real friction. Type the vendor count to confirm, or better, a staged send with a five-minute hold and a visible cancel. Orbit's RFQ release uses the hold, and it catches two or three mistaken releases a month, which no dialog ever did.
Undo is decided in the data model
You cannot bolt reversibility onto a schema that mutates in place. If the update statement overwrote the previous value, undo is a lie the interface tells. Deciding early which entities are event-sourced, which are soft-deleted with a tombstone, and which are genuinely mutable is a design decision as much as an engineering one, and it should be made when the screens are drawn.
In ledgers and anything an auditor will read, deletion should not exist. A wrong entry is corrected by a reversing entry with its own timestamp, author and reason. This annoys users for about a week and then becomes the reason a dispute takes twenty minutes to resolve rather than two days.
Undo also needs a boundary. Once an action has crossed a system edge — the payment file has gone to the bank, the email has left — the interface must stop offering to undo and start offering the compensating action, named for what it actually is. Offering undo that quietly cannot work is worse than offering nothing.
Write audit trails for the person reading them at 2am
Most audit implementations store a JSON blob of the changed row and render it as a JSON blob. The person opening it is usually a support agent under time pressure, not an engineer. Render a field-level diff — old value, new value, who, when, and the reason if one was captured — in the same visual language as the form the change was made in.
Capture intent where you can get it cheaply. A required reason code on corrections, chosen from a short list with a free-text option, turns the audit log from a record of what changed into a record of why. At Orbit, the reason codes exposed that 31 per cent of post-approval line changes came from one supplier's inconsistent pack sizes, which was a data problem, not a user problem.
Measure regret
Undo usage, correction rate and time-to-correction per screen are design metrics and belong in the same review as page performance. A screen where six per cent of submissions are corrected within an hour has a layout or labelling defect, and no amount of additional training will move it.
The pattern we look for is a correction rate that is concentrated rather than uniform. Uniform correction is people changing their minds, which is normal. Concentrated correction — one field, one screen, one time of day — is the interface producing errors, and it is usually fixable in an afternoon once you can see it.