The short version: Good microcopy is specific, short and tells people what to do next. Label buttons with verbs, keep visible labels on every field, write errors that say how to fix the problem, give empty states a next step, and use the same words for the same thing everywhere.
Last updated: 21 October 2026.
Microcopy is the text inside the interface: buttons, labels, hints, errors, empty states and confirmations. It decides whether people finish a task. A beautiful checkout with an error that says "Invalid input" still loses the order, because the user cannot tell what to change.
This guide is the set of rules we apply when writing interface copy for web and mobile products, with the guideline or study behind each one.
Why does microcopy matter so much?
People do not read interfaces, they scan them. In Jakob Nielsen's 1997 study of how people read on the web, 79 percent of test users always scanned a new page and only 16 percent read word by word (NN/g, September 1997). Inside a task, attention is even narrower. The only words that get read are the ones next to the thing the user is about to touch.
That makes microcopy part of the interaction, not a layer over it. A label is an instruction. A button is a promise of what will happen. An error is the recovery path. When they are wrong, users guess, and guessing is where support tickets and abandoned forms come from.
How should you label buttons?
Use a verb that says what the button does. Apple's Human Interface Guidelines say it is almost always best to label buttons and links with a verb, and to avoid being too cute or clever (Apple HIG, Writing).
| Weak label | Better label | Why |
|---|---|---|
| OK | Delete project | Names the consequence |
| Submit | Send request | Says what happens next |
| Yes / No | Keep editing / Discard changes | Readable without the question |
| Click here | Download invoice (PDF, 120 KB) | Describes the link on its own |
| Continue | Continue to payment | Hints at the next step |
The "readable without the question" test matters most for destructive dialogs. People skim the title, look at the buttons and press one. If the buttons only make sense after reading the paragraph above them, someone will delete the wrong thing.
One accessibility rule follows from this. WCAG 2.2 success criterion 2.5.3, Label in Name, asks that the accessible name of a control contains its visible text (W3C). If the button says "Send request", voice control users will say "click Send request", so the code must not name it "submit-btn-2".
How should you write form labels and hints?
Every field needs a visible label that stays visible. Nielsen Norman Group's research on placeholders found that text inside the field in place of a label makes it harder for people to remember what a field is for and to check and fix errors, and adds burden for users with visual and cognitive impairments (NN/g, Placeholders in form fields).
Apple's writing guidance allows placeholder or hint text for format, such as an example like "name@example.com", as long as fields are clearly labelled. That is the rule we follow: the label says what, the hint says how, and the hint never replaces the label.
A few more habits that pay off:
- Ask for the thing in the user's words. "Mobile number" beats "MSISDN".
- Mark the minority. If most fields are required, mark the optional ones.
- Say the format before the error, not after. "Date of birth, for example 27 3 1990" prevents the mistake.
- Keep one term per concept. If it is a "workspace" on one screen, it is not a "team" on the next.
What makes an error message useful?
Nielsen Norman Group's error-message guidelines (Neusesser and Sunwall, May 2023) group the rules into three: make errors highly visible, communicate constructively, and respect the user's effort (NN/g). In copy terms that means three things.
Say how to fix it. Apple's example: "That password is too short" is less helpful than "Choose a password with at least 8 characters". The second sentence is the fix.
Do not blame. The GOV.UK Design System asks error messages to be in plain English, use positive language and avoid jargon like "form post error" as well as words like "forbidden", "illegal" and "you forgot" (GOV.UK Design System). It also advises against "please", because it implies the user has a choice.
Keep their work. GOV.UK also says not to clear form fields when showing an error. Keeping the bad value lets people see what went wrong and edit it rather than retype everything.
Then match the error to the label. GOV.UK's pattern repeats the field's own language, so a field labelled "How many hours do you work a week?" gets "Enter how many hours you work a week". The user never has to work out which field the message belongs to.
WCAG 3.3.1, Error Identification, sets the floor: when an input error is detected automatically, the field in error is identified and the error is described in text (W3C). A red border alone does not meet it.
When should errors appear?
Timing is copy too. Baymard Institute's research on inline form validation (January 2024) found that 31% of sites have no inline validation at all, and recommends avoiding premature validation, removing an error as soon as the input is corrected, and using positive validation for fields that pass (Baymard Institute).
Premature validation is the common failure: an email field that shows "Enter a valid email address" after the first character. Validate when the user leaves the field, then re-check on every keystroke once an error is showing, so the message disappears the moment it is fixed.
What should empty states and confirmations say?
An empty state is the first thing a new user sees in most products, so it should not be a grey "No data". Apple's guidance is to provide clear next steps on any blank screen. Our pattern is one line on what will appear here, and one button to make the first one: "No invoices yet. Invoices you send will appear here. Create invoice."
Confirmations should name what happened and, where it matters, how to undo it. "Project archived. Undo" is better than a generic "Success!", and far better than a modal that has to be dismissed.
Apple's guide adds a subtle point about voice: avoid "we" in error messages, because it is unclear who "we" refers to. "Unable to load content" is clearer than "We're having trouble loading this content."
How do you keep tone consistent across a product?
Write a short word list before writing screens. Apple suggests creating a list of common terms and referring to it to keep language consistent, and choosing one capitalisation style per element type, such as sentence case for all headings. A useful list fits on one page:
- The product's nouns, with the one approved term for each.
- The verbs for common actions (create, delete, archive, share).
- Capitalisation per element: buttons, headings, menu items.
- Tone rules for success, warning and error states.
- Words you never use, such as internal codenames and blame words.
Tone should shift with the situation. Apple's example contrasts a user who has just hit an exercise goal with one whose payment has failed; the second user wants clarity, not cheerfulness.
How do you test microcopy?
Read it aloud in context, not in a spreadsheet. Then test the risky moments with real people: the error states, the destructive confirmations, the empty states. Small rounds are enough: Jakob Nielsen's analysis found that a test with five users uncovers about 85% of usability problems (NN/g, March 2000), and copy problems are among the easiest to spot, because confusion shows up as hesitation on a specific word. For high-traffic forms, an A/B test on a label or button can settle arguments with data.
Microcopy is cheap to change and expensive to get wrong, which is why we write it during design rather than at the end. If your product needs a copy and flow review, our product UX design team does exactly that, and for the visual side of the same process see our UI design workflow from wireframes to polish.
