Button text should describe the specific action that will happen

What it is

An action-and-object button label uses a recognizable verb to state what activating the control will do and includes the object when needed to distinguish scope or consequence, such as “Save draft” or “Export selected orders.” It treats the button as a system promise: visible label, accessible name, and actual behavior must agree. Specificity does not mean putting every explanation inside the control; when stable adjacent context identifies one object, the label can retain only the action.

Why it happens

Before acting, users predict a state change from the button. The verb supplies the type of change and the object limits its scope. Missing either can make publishing look like saving, removal look like permanent deletion, or an action on all items look like one on the current item. Clear labels also distinguish controls in voice commands, shortcuts, and screen-reader button lists. A label saying “Download report” that first opens a paywall, or “Save” that also publishes, breaks the language–behavior contract.

Studying it

In the real flow, ask intended users before activation to restate what will happen to what, then compare the prediction with the result. Record mistakes about object, scope, timing, and reversibility. Compare a short verb, verb plus object, and combinations with adjacent explanation on correct action, hesitation, slips, and distinguishability in a screen-reader button list. High-risk studies cover distraction, bulk selection, and permission differences rather than relying on isolated string preference.

Where it stops holding

The general action contract applies to all action copy; this leaf concerns how buttons carry it. Tight space, repeated rows, and a clear heading may leave the object in adjacent context, but may not truncate the critical verb or hide scope until after activation. Navigation controls may name a destination rather than a data operation, such as “View bill.” Platform-fixed controls may restrict visible text, while still requiring a correct accessible name and pre-trigger explanation. Irreversibility and warning intensity belong to high-risk confirmation design.

Applying it

• Record action, object, scope, result, reversibility, and permission conditions for each button. Verify implementation before writing the user-facing label.
• Use a clear verb by default. Add the core object or count when several objects, bulk scope, or neighboring actions could be confused, such as “Archive 8 conversations.”
• Align visible label, accessible name, shortcut menu, and event result. For asynchronous operations, distinguish starting, queuing, and completion.
• Run prediction-to-result regression before release. If users cannot identify the object or the result exceeds the label's promise, change the copy or interaction rather than relying on a post-action notice.

Related

• Same group: T2.01.2 Generic words prevent users from predicting outcomes · 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.1 State the specific object and irreversibility scope
• Search terms: action-object label · button promise · outcome prediction