Generic words prevent users from predicting outcomes

What it is

Generic button labels such as “Continue,” “Confirm,” “Submit,” and “OK” mainly express a role in a flow and rarely specify an outcome alone. They are not always wrong. “Continue” can accurately advance when one stable, adjacent context establishes the object and next state. When the control saves, publishes, pays, grants access, or exits a task, a generic word is usually insufficient for prediction. The criterion is outcome predictability in the complete usage context, not membership in a blacklist.

Why it happens

A generic word transfers meaning to headings, step structure, and memory. “Submit” may mean send for review, publish finally, or merely save a form; “OK” may confirm a destructive action or dismiss a notice. With multiple plausible outcomes, users must reread or guess, and pressure, stacked dialogs, and small screens amplify errors. Conversely, in an unbranched wizard with a persistent heading, no side effect, and a working return path, progressing is the complete result. A longer label invented for specificity would add noise rather than information.

Studying it

Test the button with its real heading, selections, state, and resulting behavior. Before activation, ask users to predict the next screen or data change and report confidence. Vary context visibility, reversibility, and plausible consequences to locate where generic wording creates divergence. Include deep links, screen-reader navigation, translated lengths, and error recovery. Classify errors as missing context, polysemous wording, or implementation exceeding the promise; do not use an isolated word-guessing task to reject every generic label.

Where it stops holding

“Got it” or “OK” on a purely informational notice, “Continue” in a reversible single-path wizard, and platform controls with settled conventions may be sufficient. “Cancel” does not guarantee no change: if dismissal discards input, say so. When a platform owns fixed button labels, provide the object and result before triggering the system dialog or in its available body. High-risk confirmation buttons still restate the action; this leaf explains when generic labels lack predictive information.

Applying it

• Annotate each generic button with its actual navigation, data, charge, permission, and reversibility effects. If a reasonable second interpretation exists, use an action or destination plus object.
• Permit a generic label only when context is adjacent and persistent, there is one plausible result, consequences are low or recoverable, and users can return. Add information when any condition fails.
• Do not make “Submit” cover different stages: write “Save draft,” “Send for review,” and “Publish article.” Do not hide payment, authorization, or account creation behind “Continue.”
• Recheck accepted labels with prediction studies and telemetry. Review again when a flow gains a side effect or its context layout changes.

Related

• Same group: T2.01.1 Button text should describe the specific action that will happen · T2.01.3 A button and its context form the sentence together · T2.01.4 Confirm and cancel wording must be opposed and clear
• Adjacent: T1.02.3 Verbs must be specific enough to judge consequences · T2.06.2 Buttons must restate the action, not say OK
• Search terms: generic button labels · Continue button · outcome ambiguity