Microcopy: The Small Words That Guide
Microcopy is the short text in an interface: buttons, labels, hints, and errors. Its three jobs according to NN/g and how to write buttons and placeholders.
What exactly is it?
NN/g defines it by size: microcopy is the shortest copy, fewer than three sentences. It includes button and link labels, form field instructions, control labels, page titles, error messages, and tooltips (NN/g: UX copy sizes: long, short, and micro).
That definition matters because microcopy cannot do all the work. NN/g itself notes that microcopy alone cannot create a complete experience: it needs other interface elements and a mix of short and long copy.
What jobs does it do?
NN/g suggests classifying each piece of text by its primary job, not by its form (NN/g: The 3 I’s of microcopy):
- Inform. It explains and educates: titles, summaries, and tooltips such as the label on a camera icon that reads “Search by image.”
- Influence. It pushes an immediate action: calls to action, promotions, and taglines.
- Interact. It explains what an element does: button and link labels, category names, placeholders, and breadcrumbs.
One piece of text can do more than one job. The classification helps you check whether a text does the job it needs to do in its place. On a payment form, a button that says “Pay” interacts; one that says “Pay $500 now” also informs.
How do you write a button?
Grafana, in the UX writing guide of its Writers’ Toolkit, sets clear rules: start with a verb, use one or two words, four at most, and say what happens when the button is clicked. It recommends specific pairs such as “Save” and “Don’t save” instead of generic “OK” or “Cancel.” It uses sentence case with no final punctuation, as in “Save changes” (Grafana: UX writing).
These are rules from one product’s style guide, not research findings. Use them as a starting point and compare them with what your own users do. The underlying question is always the same: does the person know what will happen if they tap this button?
What about placeholders?
A placeholder is the gray text that appears inside an empty field. NN/g argues that it hurts usability more than it helps (NN/g: Placeholders in form fields are harmful). Its main reasons:
- The text disappears as soon as someone types, so people who get distracted or fill in a long form forget what belongs in the field.
- Without a visible label, people cannot review their answers before submitting, and autofill mistakes go unnoticed.
- To fix an error, you have to reveal the placeholder field by field.
- People mistake the placeholder for a value that is already entered and skip the field.
- Light gray text has poor contrast, and some screen readers do not announce it.
The practical rule: the label stays visible outside the field, and the placeholder is an optional example of the expected format, such as “dd/mm/yyyy.” If an instruction is essential, put it outside the field as a hint, not inside it. If mobile space is very tight, NN/g considers a floating label better than a placeholder used as a label, though it still prefers an external label. For more on forms, see form design.
How do you set the tone?
Grafana describes the tone as friendly and conversational, but more measured than a text message. It suggests not using “please,” addressing people as “you,” and using active voice so it is clear who performs the action. For an unresponsive server, its guide prefers the plain “The server is unresponsive” and discourages apologies and dramatic or playful phrasing, which sound friendly but do not inform.
Tone is not a branding whim. In moments of error or urgency, clarity matters more than personality. If your brand is playful, save the humor for low-risk text, such as a welcome screen, and keep errors direct.
Illustrative example
Illustrative example: a transit app has a “Continue” button on four different steps. Someone booking a trip by card cannot tell whether “Continue” confirms the route or already charges them, and many drop out on the last step because of that doubt. The team reviews the microcopy: on the first step the button says “Confirm route,” on the second “Go to payment,” and on the last “Pay $3.50.” Each button says what will happen, and a usability test shows whether the doubt disappears.
For error text, review how to write error messages. And for blank screens, empty states show how microcopy guides people when there is no content yet.
Common mistakes
- Using “OK,” “Yes,” or “Submit” on every action without saying what is submitted.
- Putting essential instructions inside a placeholder.
- Using internal product terms that the person does not know.
- Writing long sentences on a button or tooltip.
- Changing the word for the same action from one screen to the next.
- Using humor in an error message the person needs to understand urgently.
What you can do tomorrow
- Walk through your main flow, copy the text of every button, and ask someone what they think each one will do.
- Review your placeholders. If they contain instructions, move those into a visible label.
- Find the “OK” and “Submit” buttons and replace them with a verb and its object, such as “Save changes.”