Microcopy is the smallest text in an interface — and often the most consequential. A confusing button kills conversion. A friendly error reduces support tickets. An empty state turns first-time users into power users. This guide gives you the patterns that work.
Microcopy Patterns Cheat Sheet
Element
Bad
Good
Primary button
Submit
Send invite
Destructive button
OK
Delete project
Error
Invalid input
Email must include "@"
Empty state
No data
No invoices yet. Create your first →
Placeholder
Enter name
e.g. Acme Inc.
Confirmation
Are you sure?
Delete 12 files permanently?
Buttons
Start with a verb and describe the outcome. "Save changes" is clearer than "Save"; "Pay $49" outperforms "Continue". Use sentence case (not Title Case) for a modern, conversational feel. Avoid stacking buttons of equal weight — one primary action per screen.
Error Messages
Errors are not failures; they're conversations. A good error answers three questions:
What happened? "Card declined."
Why? "Insufficient funds."
What now? "Try another card or top up."
Avoid system-speak ("Code 401"), avoid blame ("You entered…"), and place the error inline next to the field that caused it.
Empty States
Empty states show up the first time a user reaches a screen with no content. Treat them as onboarding moments:
One-line context: "No invoices yet."
Single primary action: "Create your first invoice"
Optional tip or link to docs.
Skip illustrations if they slow the page. The fastest empty state is the best one.
Test Your UI Copy
Check button labels and headers for clarity and emotional pull.
A button label, a placeholder, an empty state, a hover tooltip — each is a tiny conversation between the product and the user. "Cancel" and "Discard changes" describe the same action; one terrifies users into leaving fields filled, the other gives them permission to undo. Microcopy is where most product friction is invisibly created or quietly removed.
Labels match the user's vocabulary, not the database column. Users say "email address", databases say "user_email_addr". Pick the user version.
Placeholders are not labels. They disappear when typing starts and are invisible to screen readers. Use them only for examples ("e.g. [email protected]").
Empty states sell the next action. A blank dashboard should explain what to do, not apologise. "No invoices yet — create your first one in 30 seconds" beats "No data".
Errors tell the user what to do next. "Your password must include a number" beats "Invalid password". Never blame the user for a system constraint.
The "confirm shutdown" example
Before: Modal title "Are you sure?", body "This action cannot be undone.", buttons "Cancel" / "OK".
After: Modal title "Delete project Q4-Launch?", body "All 47 tasks and 12 attachments will be permanently removed. Team members will lose access.", buttons "Keep project" / "Delete forever". Now the user understands the scope, can verify they are deleting the right thing, and the destructive button is unambiguous.
Tone calibration
Loading states: reassuring ("Almost there…") not cute ("Doing the thing!").
Success states: brief ("Saved") not celebratory ("🎉 Awesome! You did it!"). Save celebration for genuine milestones.
Errors: calm and specific ("Card declined — try another card or contact your bank"), not blamey ("Invalid card!").
Confirmations of destructive actions: serious. No emojis, no levity.
The 4 am rule. Read every error and confirmation message imagining you are a tired user at 4 am trying to recover from a mistake. If the copy makes you feel worse, rewrite it.
Frequently Asked Questions
Small UI text — buttons, errors, tooltips — that appears at user decision points.
1-3 words starting with a verb that describes the outcome.
Say what went wrong, why, and how to fix it — without blame or jargon.
Briefly — one line of context plus a primary action is enough.
Build a microcopy guide alongside your design system covering verbs, tone, and punctuation.