Button Labels and CTAs
A button is the smallest thing you'll ever write, and the place your product asks the most of someone: commit. In that one word sits the whole conversation — the trust you've built, the value you've promised, the small act of courage it takes to click.
Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.
Listen to the full Button Labels and CTAs course on DesignPath
Get it right and the next step feels obvious. Get it wrong and everything you built up to that moment quietly goes to waste.
When It Matters Most
The stakes rise wherever the click costs something:
- Conversion moments — sign-up, checkout, upgrade. This is where intent becomes a business, or doesn't.
- Irreversible or scary actions — delete, pay, submit. People freeze when they can't tell what happens next.
- First or high-friction steps — where someone is still deciding whether to believe in you.
A "Next" buried in settings can be ordinary. The buttons that carry your funnel deserve your very best sentence.
What This Module Covers
Two crafts turn a label into a confident click: writing words the user would say, that name exactly what happens next — and quieting the doubt in the half-second before they commit. The next articles show you how.
Labels as the User's Voice
A button is the one place in your interface where the user actually speaks. They don't read "Submit" so much as say it, as their own next move. Get that voice right and the click feels obvious; get it wrong and they stall over a label that's talking at them instead of for them.
Make Copy Role-Playable
Think of your interface as a dialogue. The product provides context (titles, body, tooltips); interactive elements (buttons, fields, toggles) represent the user's voice. Users should be able to "say" button labels as their own actions.
- ❌ "Reserve your apartment stay" — the product is speaking at the user
- ✓ "I'll reserve" — the user is speaking through the button
Babbel's onboarding asks "What's your name?" conversationally, then uses the name in a greeting — treating signup as dialogue rather than form-filling. Booking.com's "I'll reserve" button puts the user in the first person.
Labels Must Reflect Immediate Outcomes
"Buy now" and "Book now" feel pushy and may cause abandonment because they describe a transaction, not the next step. Use labels that describe what actually happens next:
- "Show rooms" (not "Book")
- "Select a rate" (not "Reserve now")
- "Explore options" (not "Get started")
- Dice uses "Browse first" for users hesitant to sign up immediately — it names what actually happens next and removes the commitment anxiety of "Sign up"
If you struggle to name a button, the screen likely needs redesigning.Naming difficulty is usually a symptom of unclear purpose. When you're close but not quite there, ask AI for several label options in the user's voice — then choose, don't settle for its first.
No Generic Yes/No Buttons
"Are you sure? Yes / No" leaves users uncertain which is the dangerous action. Specific labels are safer and faster:
- "Quit" and "Stay" for confirmation dialogs
- "Delete forever" and "Keep" for destructive actions
- "Submit application" and "Save draft" for form completion
Titles and Buttons Must Work Without Body Text
Users scan visual hierarchy — titles and buttons first, body text often not at all. "Done," "Almost there," and "Attention" as titles are meaningless without the body text that explains them — and body text may be skimmed or missed. Titles should stand alone. Test: remove the body text and ask if the title still communicates what the user needs to do.
italki anti-pattern:uses "Action required" as a title when simply asking a user to confirm a lesson. The vague urgency creates anxiety disproportionate to a mundane confirmation request. Titles should match the actual weight of the situation.
Foodpanda good example:secondary button "Your order is on the way" conveys status even without reading body text — a status label masquerading as a button, but it communicates the user's situation instantly.
Anti-example — Bloom's confirmation screen:presents two simultaneous questions in the same view, creating cognitive overload. The button mapping becomes unclear because users can't tell which button answers which question. When two questions share one set of buttons, you always have a design problem — split them into two separate steps, or collapse them into one question.



