Microcopy is the small text on buttons, form labels, error messages, and empty states. It is easy to ignore and expensive to get wrong. This guide shows you how to write microcopy that tells users exactly what will happen and what to do next, so they hesitate less and finish more often. You will get concrete rewrites, a checklist, and the mistakes to avoid.
What microcopy actually does
Every interface is a conversation. Microcopy is the interface answering the user’s unspoken questions: What is this? What happens if I click? Did that work? What went wrong? When these answers are missing or vague, users pause, guess, or leave. Good microcopy removes that hesitation. It is not decoration; it is functional writing that reduces the effort of using a product.
The three moments microcopy matters most
- Before an action: button and link text that predicts the outcome.
- After an error: messages that explain the cause and the fix.
- At empty or first-use states: text that tells a new user what to do.
Write buttons that describe the outcome
A button should name the result, not the mechanism. “Submit” tells the user nothing. “Create account,” “Send message,” or “Download invoice” tell them exactly what they will get. This matters because users scan buttons to decide whether to commit. When the label matches their goal, they act with confidence.
| Weak | Better |
| Submit | Create my account |
| OK | Delete this file |
| Click here | See pricing plans |
| Yes | Yes, cancel my subscription |
Turn errors into recovery
An error message has one job: help the user continue. It should say what happened, why, and what to do, in plain language. Avoid codes and blame. Compare “Invalid input” with “That email address is missing an @ symbol. Please check and try again.” The second names the exact problem and the exact fix, so the user recovers in seconds.
A real scenario
A checkout form rejected payments with the single line “Transaction failed.” Support tickets piled up because users could not tell whether their card was declined, the address was wrong, or the site was broken. Rewriting the message to “Your card was declined by the bank. Try another card or contact your bank” cut confusion immediately, because it pointed to a cause the user could act on. Nothing about the payment system changed; only the words did.
Common mistakes and how to fix them
Being clever instead of clear. Jokes and puns in errors frustrate stressed users. Fix: save personality for low-stakes moments like success states; be plain when something breaks.
Vague labels. “Manage,” “Options,” “More” force users to guess. Fix: name the specific action or destination.
Blaming the user. “You entered an invalid value” feels accusatory. Fix: describe the problem neutrally and offer the correction.
Hiding the consequence. Destructive buttons labeled “OK” cause accidental data loss. Fix: label the action itself, like “Delete permanently.”
Placeholder text as labels. Text that vanishes when typing leaves users unsure what a field wanted. Fix: keep a visible label above the field.
Action checklist
- Rewrite every button to name its outcome, not “Submit” or “OK.”
- Make each error state what happened and what to do next.
- Remove jargon and internal codes from user-facing text.
- Give empty states one clear first action.
- Keep labels visible; do not rely on disappearing placeholders.
- Read messages aloud; if they sound robotic or cryptic, revise.
- Test with someone unfamiliar and watch where they hesitate.
Conclusion and next step
Microcopy is cheap to change and quick to pay off. Pick your most important flow, such as sign-up or checkout, and rewrite every button and error in it this week. Watch where users still pause, and keep tightening the words until the path is obvious.
FAQ
How long should microcopy be?
As short as possible while still answering the user’s question. A button is two to four words; an error may need a full sentence if it must explain a fix. Clarity beats brevity when they conflict.
Should microcopy have personality?
In calm moments, yes, a light tone builds warmth. In errors, failures, or destructive actions, drop the personality and be direct. Match the user’s emotional state.
Are placeholders a good substitute for labels?
No. Placeholder text disappears when users type, so they lose track of what the field needs. Keep a persistent visible label and use the placeholder only for an example.
Who should write microcopy?
Whoever understands the user’s task. It does not require a specialist, but it does require testing with real people, since assumptions about what is “obvious” are often wrong.
References
- Nielsen Norman Group, articles on error messages and UX writing
- MDN Web Docs, form and accessibility labeling guidance