Principles
Lead with the verb
The first word the user reads should correspond to the action. Front-loading the verb makes buttons easily scannable and optimizes for assistive technologies.
Create release
Add variable
Release version
New variable
Be specific about what happens next
The label should describe the outcome of pressing the button. Instead of using a generic, overused “Submit” label, name the specific action or what happens next.
Deploy to production
Send verification email
Deploy
Send
Submit
Match the severity to the variant
Visual styling of the button should go in hand with the label. Don’t use a danger button for a benign action, and don’t use a primary button for a destructive action.
Delete project (danger button variant)
Delete project (primary button variant)
Pair destructive labels with explicit consequences explained in the surrounding content.
Don’t use punctuation, emoji, or additional formatting
Button labels should be plain text. Don’t use full stops, exclamation marks, emojis, bold, italics, or underlines.
Save variables
Save variables!
💾 Save variables
Drop the articles
Skip "a", "an", and "the" where they don’t change meaning. Unnecessary articles increase cognitive load and character count.
Add target
Create release
Add a target
Create new release
Don’t blame, scold, or shame users
Never author content that pressures, manipulates, or creates feelings of guilt in users. Making the negative option feel like a failure on users part is not acceptable.
Cancel
Skip
No, I don’t want to deploy safely
No, I’ll take the risk
Write the label before you choose the variant
Draft the label first, considering what the button actually does, then pick the variant. Authoring content first enables informed visual representation choice.
Anatomy
A button label has two jobs: tell the user what will happen when they activate it, and make sense the moment a screen reader announces it.
Verb + noun
Use a verb followed by a noun describing the item the verb acts on. Using a noun anchors to a specific outcome—without it, "Add" or "Create" can be ambiguous, depending on where in the interface the user’s attention is anchored (and assistive technologies operate without visual context).
Create release
Add step
Release
Add
Verb alone
Single verb labels work when the action is well-established in interface conventions and the surrounding context (for example: in a dialog, a form, a row in a table). Only reach for this option when it provides clearer instruction than the verb + noun version.
For example: Cancel label can work more effectively than Cancel deployment in a Dialog that’s already about a deployment.
Common standalone verbs that could be considered:
- Cancel
- Save
- Delete
- Edit
- Continue
- Skip
Icons
A button can include an icon to add emphasis. We use icons sparingly and consistently:
- One icon per button
- No Unicode symbols as substitution for icons (for example: +, >, or →)
- Icon-only buttons should always have an accessible label (aria-label) and a Tooltip that follows the same content rules as visible labels
Variants and content
The label should match the implicit meaning of a button variant used:
|
Variant |
Use for |
Label pattern |
|---|---|---|
|
Primary |
The single most important action on the screen |
Verb + noun: Create release, Deploy |
|
Secondary |
Supporting actions |
Verb + noun: Save draft, Add step |
|
Tertiary |
Low-emphasis actions and alternatives |
Verb-led: Cancel, Skip |
|
Danger |
Destructive or irreversible actions |
Verb + noun, be explicit: Delete project, Revoke access |
Button groups
When using buttons in a group, don’t repeat the same verb across labels without additional context. It creates confusion about consequences of an action and what elements it affects.
Save draft | Save release
Save | Save
Voice and tone
Use sentence case
Use sentence case for button labels to align with the rest of the interface content guidelines. Acronyms and proper nouns should keep their capitalization, for example: Configure SSL or Connect to GitHub.
Create release
Create Release
Limit length to three words
Keep labels short, but without losing meaning. Avoid labels over three words. Only use more than three words if shorter alternatives lose meaning. Make sure that button labels don’t drop onto two lines.
|
Length |
Use when |
|---|---|
|
1 word |
Verbs are universally understood and present in clear context: Cancel, Save, Delete. |
|
2 words |
The most common length: Create release, Add step |
|
3 words |
When the object needs qualifying: Save as draft, Deploy to production. |
Use plain English
Avoid jargon, internal phrases, and abbreviations the user might not recognize.
Configure SSL
Setup TLS cert
Don’t repeat what the user just read
If the button is nearby content that already describes the action and it’s consequences, don’t repeat the same phrase in the label.
For example: Once you've selected your release, you can deploy it to production.
Deploy
Deploy the selected release to production
Words to avoid
|
Avoid |
Why |
Use instead |
|---|---|---|
|
Submit |
Doesn’t tell the user what happens text. |
Name the action: Create release, Send invitation. |
|
Click here Here |
Doesn’t mean anything without additional context. |
Name the action: View logs. |
|
OK |
Doesn’t name the action and is vague. |
Use Got it, Continue, or the name specific outcome. |
|
Yes No |
Makes it harder to understand the consequences of an action. |
Name the outcome: Delete project / Cancel. |
|
Continue Next (in single-step flows) |
Makes it harder to understand the consequences of an action. |
Name the outcome: Review changes, Confirm deployment. |
|
Done |
Doesn’t mean anything without additional context. |
Name the outcome: Finish setup, Save changes. |
|
More info |
Doesn’t name the action and is vague. |
Name the specific resources: Docs: IP address allow list |