Loading…
Loading…
Buttons are the primary interaction triggers in any interface. Their labels are the final piece of microcopy users read before committing to an action. Vague labels create hesitation; specific labels create confidence. The best button labels complete the sentence 'I want to...'
stellae.design
Button labels serve as the final decision point in user flows. Users scan a page, reach a button, and the label determines whether they click or hesitate. Good button labels are specific, action-oriented, and predictable.
Before/after examples: • Before: 'Submit' → After: 'Create account' • Before: 'OK' → After: 'Delete permanently' • Before: 'Yes' → After: 'Confirm payment of $29.99' • Before: 'Click here' → After: 'Download report (PDF)'
Button labels are the text on interactive controls that tell users what will happen when they click — and because buttons represent commitment points where users take action, the clarity and specificity of their labels directly determines whether users click with confidence or hesitate with uncertainty, making button copy one of the highest-leverage UX writing investments a team can make. Vague button labels like 'Submit,' 'OK,' or 'Click here' force users to infer what the button does from surrounding context, which increases cognitive load and creates moments of uncertainty that reduce click-through rates by 10-30% compared to specific, action-oriented labels, according to multiple A/B testing studies from organizations like HubSpot and Unbounce. Beyond conversion impact, button labels serve as critical wayfinding signals — users scan interfaces by reading buttons and links first to understand what actions are available, so descriptive labels like 'Save draft,' 'Publish post,' or 'Cancel subscription' create an interface that is self-documenting and navigable even before users read the surrounding body text.
Mailchimp replaces generic button labels throughout its interface with specific, action-describing alternatives: 'Send campaign' instead of 'Submit,' 'Save and close' instead of 'Done,' 'Create audience' instead of 'OK,' and uses destructive-action labels like 'Permanently delete' in red to ensure users understand the irreversibility of the action before clicking. This specificity extends to the email builder where buttons adapt to context — 'Schedule email' when a send date is set versus 'Send now' when it is not — so the label always reflects the actual outcome of the click rather than a static generic term. A/B testing showed that these specific labels increased completion rates for campaign creation workflows and reduced accidental sends.
GitHub's pull request interface uses highly specific button labels that tell developers exactly what will happen — 'Merge pull request,' 'Squash and merge,' 'Create a merge commit' — rather than a single generic 'Merge' button, because each action has different consequences for the repository's commit history that developers need to understand before clicking. The 'Close with comment' and 'Close pull request' buttons differentiate between closing with feedback and closing silently, and destructive actions like 'Delete branch' appear only after the merge is complete with clear, specific labels. This precision in button labeling reflects the high stakes of version control operations where an ambiguous click can affect an entire team's codebase.
A project management application uses the same 'OK' and 'Cancel' button pair for every confirmation dialog — whether the user is saving a task, deleting a project, removing a team member, or archiving a sprint — providing no contextual information about what 'OK' will actually do in each situation and forcing users to re-read the dialog body text every time to understand the consequence of their click. Users develop a habit of clicking 'OK' without reading, which works fine for low-stakes confirmations but leads to accidental deletions and irreversible changes when the same generic pattern is applied to destructive actions. Replacing 'OK' with specific labels like 'Delete project,' 'Remove member,' and 'Archive sprint' in each context would prevent these errors by making the button itself communicate the action.
• The most common mistake is defaulting to generic labels — 'Submit,' 'OK,' 'Continue,' 'Click here' — across an entire application because they are fast to implement and do not require copywriting for each context, but this false efficiency costs conversion rate, increases support requests, and creates accessibility barriers for users who navigate by button and link lists. Another frequent error is labeling destructive actions with the same visual and textual weight as constructive ones: a 'Delete' button that looks identical to a 'Save' button and sits next to it with no differentiation invites accidental clicks that a red-colored 'Permanently delete' with appropriate spacing would prevent. Teams also write button labels as nouns rather than verbs — 'Subscription' instead of 'Subscribe,' 'Download' as a section heading rather than 'Download report' as an action — which creates ambiguity about whether the element is informational or interactive.
Was this article helpful?