Write button labels that complete the user's sentence
Button labels aren't brand moments. They're functional signposts that tell users exactly what action they're committing to. The test is simple: if someone reads only the button text without any surrounding context, do they know what will happen when they click?
The sentence completion test
Your interface sets up an implicit sentence. The button completes it. When you write "Continue" on a checkout page, the user has to remember where they are in the flow to know what "continue" means. But "Continue to shipping" or "Continue to payment" finishes the thought.
This isn't about being verbose. It's about reducing cognitive load at the exact moment someone has to make a decision. The brain shouldn't have to cache context to parse an action.
Primary actions deserve specificity
Generic verbs—Submit, Continue, Next, Proceed—make users do interpretive work. They're acceptable for secondary actions where context is obvious, but primary buttons should carry their weight.
Compare these:
- "Submit" vs. "Create account"
- "Save" vs. "Save draft" or "Publish post"
- "Delete" vs. "Delete 3 selected items"
The specific version removes ambiguity. It also gives users a chance to catch mistakes before they happen. If the button says "Delete 3 selected items" and they only meant to delete two, they'll notice.
State what happens, not what the user should do
Buttons describe outcomes, not instructions. "Click here to download" is instructions. "Download report" is an outcome. The difference matters because users scan for objects and actions, not for tutorials on how to use your interface.
This principle applies to confirmation dialogs too. "Are you sure?" with "Yes" and "No" buttons makes users translate their intent twice. "Delete this post?" with "Delete post" and "Keep post" buttons maps directly to what they want to happen.
Avoid pronouns in button text
Pronouns force users to resolve references. "Add to my cart" requires unpacking who "my" refers to. "Add to cart" doesn't. Same with "Save my changes"—just "Save changes" is clearer because there's no possessive ambiguity.
The exception is when the pronoun eliminates actual confusion, like "View your profile" vs. "View profile" on a page that shows multiple profiles. But that's rare.
Use the same verb the interface used to start the action
If your navigation says "Edit profile," the button at the bottom shouldn't say "Update settings." Terminology consistency isn't just a style guide concern—it's a confirmation signal. When the verb changes, users wonder if they're still doing what they intended.
This connects directly to consistent terminology as a structural decision. Your button labels are part of your taxonomy. Treat them that way.
Test by removing all surrounding text
Take your button label and read it without the page heading, form fields, or body copy. If you can't tell what it does, neither can a user who's skimming or using assistive technology that announces buttons out of context.
"Submit form" is barely better than "Submit" if fifty other pages on your site also have forms. "Submit contact request" or "Send message" tells someone exactly what's about to happen.
Length limits are real but not an excuse
Yes, mobile screens constrain button width. Yes, some CMS templates have character limits. But "Download PDF" fits in the same space as "Download" and provides actual information. The constraint isn't the problem—lazy defaults are.
If you genuinely can't fit specificity, your interface probably has a structural problem. Maybe the button is trying to do too much. Maybe the page context is unclear. Fixing the label often means fixing the flow.
Button text is microcopy with macro impact. Write it like someone's trying to finish a task, not navigate your brand voice.