Habituated confirmations get clicked through
Aliases: confirmation fatigue · click-through · warning habituation
What it is
When confirm is the default error-prevention move, the same question repeats along one recovery path. People compile “OK” into the action chain and stop reading. Frequent confirms get clicked through means abuse makes confirm fail on the actually dangerous trial too. This entry is about frequency wrecking the strategy. It is not about which acts deserve a confirm, and not about slips versus mistakes.
Why it happens
Attention demotes a stable, repeating stimulus to background. If the recovery flow pops the same skeleton for archive, cancel, delete, and leave-without-saving, the visual system registers “that card again,” and the decision finishes before the object name is read. Aiming at the bottom-right becomes a skill. Worse, if the dangerous act reuses that face, habituation crosses the consequence boundary: the muscle that dismisses a draft confirm dismisses the production-database confirm. Stacking more confirms onto a path already clicked through only speeds the registration. Scarcity is the condition under which confirm still works. It is not politeness.
Studying it
Insert structurally identical confirms into a continuous main task, increasing count, then—without warning—swap one trial for a high-stakes object.
Independent variables: confirms per task, whether the card looks like the everyday confirm, which trial number is high-stakes. Dependent variables: whether the high-stakes trial is still clicked through, reading time on that trial, whether the object name can be restated.
Do not write “please read carefully every time.” That measures compliance, not product click-through. The main task needs time pressure so the confirm feels like a real obstacle.
Where it stops holding
A rare confirm that looks nothing like the everyday card habituates much more slowly. Repetition across days and sessions is stronger than a single lab session; “clicked through on the third trial” in the lab may already be finished by week three in the product. Scripts, macros, and automated tests click through too—they have no reader. Requiring a typed name or a wait can break the aim, but that is another layer of friction; you cannot cure click-through by turning every confirm into a punishment.
Applying it
- Count how often each confirm appears in real sessions; more than once per task is, by default, already being clicked through—delete it or switch to post-hoc undo.
- High-stakes confirms must not reuse the everyday layout and button placement, so that aiming pattern misses.
- Do not stack another confirm onto a path already clicked through in order to “add safety.”
- Verify on recordings: time from dialog appearance to press. If it is too short to finish the object name, confirm on that path is spinning.