Button, Label & CTA Copy Conventions

The full lesson

The words on a button are some of the most important copy in any interface. A single verb choice — “Submit” vs. “Save changes” vs. “Get your free trial” — can shift task-completion rates, cut support contacts, and build or break user trust before anyone clicks. Button and CTA copy sits at the crossroads of writing craft, interaction design, and persuasion ethics. Done well, it disappears into the background. Done poorly, it creates hesitation, false expectations, and sometimes manipulative patterns that can even create legal problems.

Why Button Copy Is Harder Than It Looks

Most button labels are written as an afterthought. Engineers insert form actions, PMs copy a competitor, or designers grab placeholder text that never gets replaced. The result: interfaces packed with “Submit,” “Click Here,” “OK,” and “Proceed.”

Those labels technically work, but they fail to answer the question every user silently asks before every click: “What will happen when I do this?”

That question is the contract every button label must fulfill. When the outcome is predictable, users click without hesitation. When it’s ambiguous, they pause, scan the surrounding text for clues, or give up entirely. Research on link and button labels consistently shows that descriptive, outcome-oriented labels outperform generic ones on task completion and reduce the cognitive load of navigating an interface.

The Core Formula: Verb + Object + Outcome Context

The most reliable pattern for button copy is a tight verb-object construction that names the specific action the system will perform.

The formula is: [Action verb] + [what is acted on], optionally extended with [outcome context] when the stakes or novelty of the action call for it.

“Start free trial” beats both “Start” (no object) and “Start your 14-day free trial with no credit card required” (fine as surrounding copy, but too heavy as a button label).

Choosing the right verb

Verb choice carries real meaning. Match the verb to the actual interaction:

• Create / Add — for bringing something new into existence
• Save — for keeping changes the user has already made
• Send — for dispatching content to another person or system
• Delete / Remove — for destructive actions (always pair with a confirmation step)
• Download / Export — for pulling data out of the system
• Sign up / Log in — for authentication entry points (not “Register” or “Sign in” interchangeably — pick one and stick with it)
• Get — acceptable for CTAs where the user receives something (“Get started,” “Get the guide”)

Avoid verbs that describe the UI interaction rather than the outcome. “Click,” “Tap,” “Press,” and “Select” are UI-layer words. They add no meaning and break down on touch, keyboard, and voice interfaces.

Primary, Secondary, and Destructive Buttons

Every button in a dialog, form, or action cluster has a semantic role — meaning it communicates a specific level of importance. The copy must match that role in both wording and visual weight.

Primary buttons carry the recommended or most-likely next step. The label should be the clearest possible statement of the primary outcome: “Save draft,” “Place order,” “Create account.”

Secondary buttons are alternatives or escape routes. They need to feel clearly different from the primary in both visual weight and wording. “Cancel,” “Go back,” and “Keep editing” are typical secondary labels. Avoid pairing “OK” with “Cancel” — these create a false parallel. “OK” does something specific; “Cancel” undoes the intent to do it. Instead, pair the primary action with a genuine opposite: “Delete account” / “Keep my account.”

Destructive buttons — those that perform irreversible actions — follow a stricter rule. The label must name the specific thing being destroyed, not just the action verb. Write “Delete project,” not “Delete.” This serves two purposes: it makes the label self-contained in a confirmation dialog where the user may have lost context, and it gives the user one final, unambiguous checkpoint before losing data.

CTAs in Context: Marketing vs. Task UI

Call-to-action (CTA) copy in a marketing or promotional context follows slightly different rules than buttons in a product UI.

Product UI buttons optimize for clarity and speed. The user is in a flow and needs to know exactly what happens next — without reading the surrounding copy. Short, specific, verb-object labels win.

Marketing CTAs carry a heavier persuasion load. They must overcome inertia and motivate a voluntary action. Here, outcome-benefit framing earns its place: “Start building for free,” “See all features,” “Try it — no credit card needed.”

The constraint that applies to both contexts is accuracy. A CTA that overpromises (“Get instant access”) followed by a friction-heavy flow (email verification, plan selection, credit card entry) betrays user trust and damages conversion downstream. Good UX writing treats CTAs as the first micro-moment in a larger experience contract.

Accessible Button Labels

Button copy is the primary way screen reader users identify and invoke interface actions. When a button contains only an icon — no visible text — it still needs an accessible name, delivered via aria-label or aria-labelledby.

Key WCAG 2.2 principles for button labels:

2.4.6 Headings and Labels (AA) — Labels must be descriptive. A button with no text content and no aria-label gets announced as “Button,” which fails this criterion.

2.4.9 Link Purpose / Button Purpose (AAA) — Each button’s purpose should be clear from the label alone, without needing to read the surrounding page.

2.5.3 Label in Name (AA) — If a button has visible text, the accessible name must contain that exact text. A button visually labelled “Save” with aria-label="Save document" is fine — the accessible name contains the visible text. A button visually labelled “Save” with aria-label="Persist record" fails.

2.5.8 Target Size (AA, new in WCAG 2.2) — Touch targets must be at least 24x24 CSS pixels (with exceptions for inline controls). Button copy that wraps because it is too long can push the target below that minimum — making this a writing constraint as much as a layout one.

For icon-only buttons, the accessible name should match what a sighted user would naturally infer: aria-label="Close dialog", not aria-label="X" or aria-label="icon-close".

<!-- Icon-only button with correct accessible name -->
<button aria-label="Close dialog">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

<!-- Avoid: accessible name does not describe the action -->
<button aria-label="X">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Disabled Buttons and State Copy

A disabled button with no explanation is a dead end. It is especially frustrating for users with cognitive and motor disabilities, who may spend real effort trying to invoke it before realizing it is not interactive.

Two modern patterns handle this well:

1. Explain the prerequisite inline — Add helper text next to or below the button: “Complete all required fields to continue.” This keeps the button visible as a landmark while explaining what is blocking the user.

2. Use aria-describedby to annotate the disabled state — Screen reader users hear both the button label and the reason: “Save changes, button, disabled — fill in all required fields to continue.”

The outdated pattern is a visually greyed-out button with no explanation. Users are left guessing whether something is broken, whether they lack permission, or whether they missed a required step.

Consistency and the Role of a Content System

Individual button labels do not exist in isolation. Users encounter them in sequence — across screens, sessions, and devices. Inconsistency accumulates invisibly. If “Save” appears on one screen and “Update” appears on an equivalent screen doing the same thing, users wonder whether the two actions are different.

A mature content design practice maintains a button vocabulary: a curated set of approved verbs paired with their canonical use cases, stored in the design system documentation alongside the component itself. This follows the living-docs model — content standards co-located with the component, not in a separate tone-of-voice document that drifts out of sync.

In practice, this means:

• Standardizing on “Log in” not “Sign in” (or vice versa) and enforcing it in the design system
• Documenting the approved label for each button variant in the component spec
• Running a CTA audit before major releases to catch label drift
• Including button copy in design token documentation as a content pattern reference, not just a visual spec

The goal is a label vocabulary so consistent that users never notice it — they just trust the product.

Testing Button Labels

Button copy is one of the highest-ROI areas for content testing. Small word changes can be measured with high precision.

A/B testing works well for high-traffic CTAs where you can reach statistical significance quickly. Test one variable at a time — the label vs. a different label, not the label plus the button color. A 95% confidence threshold requires roughly 40 or more conversions per variant to detect a 10–20% difference.

First-click testing is faster and cheaper for validating whether users understand where to click to accomplish a task. Show a static screenshot and ask users to click where they would go to perform a specific action. Low click accuracy on a CTA is a strong signal that the label is failing — even before you write any code.

The outdated instinct is to trust gut feel or copy competitors. Neither tells you whether the label works for your users in your specific context.