Verbs must be specific enough to judge consequences

What it is

Action-label consequence specificity means that a label and its adjacent context identify the state change a person is about to trigger. “Process,” “Continue,” and “Submit” name generic activity or progress. When several outcomes remain possible, the interface also needs the object, affected scope, direction, timing or status, visibility to others, and reversibility. Specificity does not mean packing every fact into a button; it supports a correct prediction of the consequences relevant to the decision and risk.

Why it happens

Before acting, people combine the label, selected object, dialog explanation, and current step into an outcome model. A generic verb can cover different transitions: “Sync” may upload, download, merge, or overwrite, while “Continue” may open a preview, create an order, or charge immediately. Object and scope answer what changes; direction and timing answer how and when; resulting state and reversibility answer what can be recovered. The greater the consequence, the less safely these slots can be inferred from habit.

Studying it

Use consequence-prediction tasks in the production-like interface. Show the label with its actual adjacent context, ask participants to state object, scope, timing, result, and recovery, then compare with implementation. After execution, observe hesitation, backtracking, wrong actions, and surprise. Add object, direction, timing, and reversibility information separately to learn which detail reduces misunderstanding at each risk level while measuring scanning and wrapping costs. Include new and experienced users, bulk selection, asynchronous work, and permission differences. Define acceptance from consequences in advance rather than inventing one global accuracy cutoff.

Where it stops holding

“Continue” can be accurate when the next step is visibly previewed and has no side effect. “Save” need not repeat location, version, and visibility when those remain stable. A heading or selection may uniquely supply what a short button omits, so label and context carry meaning together. Deletion, overwrite, public sharing, transfer, subscription, and irreversible submission need more explicit scope and result even at the cost of length. When timing is uncertain, asynchronous copy should name the committed state and notification path rather than promise a false timestamp. Translation must preserve natural syntax and complete messages.

Applying it

• Define the action contract: operation, object, count or boundary, direction, immediate/queued/pending state, external visibility, and undo or recovery conditions. Put the decision-critical subset in the label or adjacent explanation according to risk.
• Replace vague labels with distinguishable results: change bare “Process” to “Regenerate invoice,” and an overwriting “Sync” to “Upload and replace cloud version.” Do not maintain a context-free global blacklist.
• Keep dynamic scope next to the action and synchronized, such as “Delete 12 selected files.” State outcome and recovery limits for irreversible or externally visible changes, and repeat the action in confirmation rather than reverting to “OK.”
• Verify that label, supporting copy, backend command, and completion/error states use the same semantics. Ask people outside the design team to predict and execute the result; consequential misunderstanding blocks release, while low-risk findings are prioritized by reach and recoverability.

Related

• Same group: T1.02.1 Verb-first labels are the most scannable · T1.02.2 Nominalization hides the action about to happen
• Adjacent: T2.01.3 A button and its context form the sentence together · T2.06.1 State the specific object and irreversibility scope
• Search terms: action specificity · consequence preview · predictive action label