Confirms catch mistakes, not slips
Aliases: slip versus mistake · confirmation fails on slips
What it is
A slip is a correct intention, a skewed execution: archive was intended, delete was tapped. A mistake is an intention that should not have existed in this moment: the person thought this was the staging database, and it was production. A confirmation that asks “do you want to do this?” one more time can stop someone still evaluating a plan. It cannot stop a hand that has compiled the click into a skill. Using confirm to prevent a slip misidentifies what recovery is for. This entry is about what confirm can intercept. It is not about how often confirms appear, and not about where undo sits.
Why it happens
For confirm to work, the person must re-evaluate the plan before the second click. A slip lives at execution; the plan already passed before the first press, and the second click is an echo of the same plan. The dialog copy matches the intention, so it is taken as the next beat in the flow. A mistake lives at judgment; if the person is forced to load object identity and consequence into working memory, they may notice “this is not the world I thought.” So the only legitimate cognitive job of a confirm is checking identity and predicting consequence, and that job is useful only for high-cost judgments that are not yet automatic. Preventing slips takes reversibility and targets that are hard to hit by accident, not another request for consent.
Studying it
Build two failure types—adjacent-button miss (slip) and wrong object chosen (mistake)—and cross each with confirm / no confirm.
Independent variables: error type, presence of confirm, whether the copy names the object. Dependent variables: whether the slip still occurs, whether the mistake is corrected on the confirm, whether gaze on the confirm meets the object name.
Do the debrief immediately; otherwise people rationalize the outcome into “I meant to delete.” If eye tracking shows the confirm button fixated before the object name, confirm did no judging on that trial.
Where it stops holding
On a wholly unfamiliar task, even clicking is not yet automatic, and a confirm may occasionally catch a slip because the person is already checking step by step—that does not measure a skilled path. Time pressure can squash a mistake into a fast click that looks like a slip; classification needs an intention report before the act, not speed alone. If the copy never names the object, confirm fails on mistakes too—there is nothing to check, so the judgment layer has no work.
Applying it
- In an incident review, ask first whether they meant to do this. If it was a slip, change reversibility and target spacing; do not add a confirm.
- If the wrong object or the wrong environment was chosen, then consider a confirm, and the confirm must make object and consequence checkable, not ask for consent again.
- When one control produces both slips and mistakes, make it reversible first; add confirm only on the irreversible segment.
- Verify by splitting recent accidental-delete logs into “wrong control” and “wrong object.” If the first class barely drops after adding confirm, confirm is being spent on slips.