The right question for a confirmation screen isn't "how risky is this," it's "can I undo it"
Been iterating on confirm-before-execute UX for a phone assistant, and I've been sorting actions the wrong way. My instinct was to bucket by category — messaging, calendar, device control — and give the "sensitive" categories more scrutiny.
Got pushed on this in a thread this week and it reframed the whole thing: the real split isn't risk, it's recoverability. Toggling wifi and moving a calendar event with notice are both trivially reversible, regardless of category. Sending a text, placing a call, deleting something — not really, especially once another person's seen it. There's no unsend on a message someone already read.
That test survives contact with real cases better than "how dangerous does this sound," because the two come apart constantly — a scary-sounding action can be fully reversible, and a boring-sounding one can't be undone at all.
Practical result: collapsing every low-stakes, reversible step into one compact plan, and giving anything irreversible its own explicit line instead of burying it in a bulleted list — even if that makes the screen slightly longer.
Curious how others building confirmation/approval flows have drawn this line. Risk-based, recoverability-based, or something else entirely?
Recoverability is the right axis, and it points to a stronger conclusion than a better prompt: wherever you can build an undo, build the undo instead of the confirmation. We learned that running managed services, where every added approval step trained people to click through without reading, so the prompts meant to protect them became the reason they got burned. For the set that truly cannot be undone I would add one more axis, whether another person is affected, because that is what separates a sent text from a deleted file and it is the only case worth a full-screen interruption.
The reframe survives an even harder test, reversibility isn’t binary either. Your question is better to be how completely you can undo it and at what cost. A deleted file with a backup is cheaply reversible. A sent email is socially irreversible but factually correctable. A published number sits somewhere in between. So the confirmation screen’s real job isn’t just to say whether an action is reversible. It should tell you "what kind of undo is actually available".
There’s also a useful asymmetry rule that follows from this. When the system can’t determine whether an action is recoverable, it should default to treating it as irreversible (never quietly assume the opposite). That’s the failure mode I’d worry about with risk-scored confirmations: “low risk” gradually becomes a bucket that silently absorbs “unknown risk.”
I like the shift from risk to recoverability. It also makes me wonder whether "can I undo it?" sometimes needs one more question: "what remains after I undo it?"
Some actions are technically reversible, but the consequences aren't. Restoring a deleted record doesn't necessarily restore the notification someone already received, or the decision someone already made based on it.
That makes recoverability feel less like a property of the action itself and more like a property of the whole system around it. The confirmation UX then becomes a way of exposing that consequence before execution.