J4.07.3confirmation and restatementdesignresearch

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

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/J4.07.3