Restate and confirm before critical actions
Aliases: confirm critical steps · restate the action · error prevention
What it is
A transfer, an account deletion, a submission that cannot be pulled back—once those fire, the outside world changes. At the moment of the press, a user with a cognitive disability may no longer hold a complete representation of “what I am doing.” Confirmation and restatement requires that, before the action goes out, the thing about to happen is said again in words the person can recognise, and that a distinct consent is collected, different from the act of filling the form.
What gets restated is this action—who, to what, how much, where—not a dump of every field collected in the flow. A dialog that only says “OK” has not restated anything; it has asked for another click.
Why it happens
Action intent decays while the form is being filled. People remember they are “doing a thing” without still binding object and amount. Confirmation turns recall into recognition: a proposition written on the screen can be checked (“is it this?”) instead of rebuilt from scratch.
OK / Cancel often fails because it carries no proposition, only an extra click. For impaired executive function that extra click becomes a habit-press. The checkable facts have to live inside the confirmation surface. After the action has already hit a third party or an irreversible state, undo does not close this gap—undo addresses a miss-tap; restatement addresses a miss-thought.
Studying it
Conformance checks for legal, financial, and user-controlled data changes ask whether a review mechanism exists before submit. A more direct probe is think-aloud: interrupt when the confirmation appears and ask what will happen if they proceed. If they cannot name the object or the amount, restatement did not occur.
Independent variables: whether the copy includes object and outcome; whether the confirm control is distinct from the primary fill button. Dependent variables: ability to state consequences without looking back at the form; erroneous-submit rate.
Do not substitute “an extra confirm reduces mis-taps.” That is a motor-error question with a different evidence shape.
Where it stops holding
Actions that are immediately undoable and only affect a local draft do not need restatement every time, or confirmation itself fatigues and people learn to dismiss it. Low-stakes toggles need immediate feedback, not a dialog. The wording must reuse the terms the user just used, not switch vocabulary at the last second. A countdown that auto-executes the action cancels consent.
Applying it
- Before irreversible or high-stakes actions, restate actor, object, amount, and destination in full numbers—not “the above.”
- Name the confirm control as the action (“Confirm transfer”), not a generic OK. Cancel must be equally findable.
- Verify: cover everything except the confirmation panel and ask someone who never filled the form what will happen. If they cannot name the object or the outcome, restatement failed. Then walk a person with a cognitive disability through a real high-stakes path and watch whether they actually read the confirm screen, rather than treating it as a surplus click.
Related
- Same group: J4.07.1 Reduce the number of choices shown at once · J4.07.2 Give the interface a consistent, predictable structure
- Nearby: J4.09 Reducing memory load · J3.09 Accidental activation and undo · A6.19 Prospective memory
- Search terms:
confirmation and restatement·error prevention·cognitive accessibility