A user is three seconds from your activation metric. The form is filled in, the cursor is over the button, and the button says Submit. They pause. What does submitting do — save a draft, publish to their team, start a subscription? Nothing on the screen answers that, so the safest move is to do nothing, and they close the tab. Your dashboard records a drop-off at step four. Nobody in the company will ever know that a single word cost you the account.
This happens constantly, and it is fixable in an afternoon. Microcopy — the button labels, hints, empty states, error messages, tooltips and confirmations scattered through your interface — is the text users actually read, at exactly the moments they decide whether to continue. It is also, uniquely in product work, free to change and fast to test: no design system revision, no migration, no engineering quarter.
This guide covers what microcopy is and where it lives, why so few words carry so much weight, the eight surfaces where microcopy decides the outcome, more than forty before-and-after rewrites you can lift directly, the three formulas that make short copy work, and how to ship and test wording changes on a live product without a release cycle.
Key Takeaways
- Microcopy is the text at the decision points — buttons, hints, errors, empty states, tooltips, confirmations. It is short, but it sits exactly where users hesitate.
- Name the outcome, not the mechanic. "Create my first report" tells the user what happens; "Submit" makes them guess, and guessing is where drop-off comes from.
- Errors need three parts: what happened, why, and what to do next — in plain words, next to the thing that failed, with nobody blamed.
- Write from the user's side of the screen. Their words, their goal, their moment. Internal feature names in a first-run interface are a tax on comprehension.
- Empty states are onboarding. A blank screen with a good sentence and one button converts; a blank screen with "No data" is a dead end you paid to build.
- Test it — microcopy is the only interface change you can ship and measure the same week, especially when the guidance layer is delivered without a code release.
What Is UX Microcopy? (Definition & Where It Lives)
UX microcopy is the functional text embedded in an interface to help people use it: the words on and around controls, rather than the words that describe the product. It is written to be scanned, not read; it exists to remove a specific doubt at a specific moment; and it is measured by whether users complete the action, not by whether the sentence is elegant.
Microcopy, defined. The small, functional pieces of interface text — labels, hints, states, errors, confirmations — that carry a user through a product. Marketing copy earns the signup. Microcopy earns everything after it.
It shows up in more places than most teams have an owner for:
| Surface | What it decides | The failure mode |
|---|---|---|
| Button labels | Whether the user clicks at all | Generic verbs — "Submit", "OK", "Continue" |
| Empty states | Whether a new user ever starts | "No data yet" with no way forward |
| Error messages | Whether the user recovers or leaves | Codes, blame, and no next step |
| Form hints & labels | Completion rate, data quality | Requirements revealed only after failure |
| Tooltips | Whether a feature is understood | Restating the label in more words |
| Onboarding copy | Time to first value | Explaining the UI instead of the outcome |
| Confirmations | Trust after irreversible actions | "Are you sure?" with no consequence named |
| Permission asks | Opt-in rate | Asking before explaining the benefit |
Notice what the failure column has in common: every one of them is a place where the product knows something the user doesn't, and declines to say it. That's the whole diagnosis. Microcopy work is mostly the discipline of writing down what your team already knows, at the moment the user needs it.
Why a Handful of Words Beats a Redesign
-
It sits exactly where users hesitate
Friction isn't spread evenly across a product — it clusters at a few controls, fields and dialogs. Microcopy is the only design material that lives precisely at those points, which is why a rewrite can move a completion rate that months of layout work didn't touch.
-
It's the fastest change you can make
No migration, no design system revision, no data model. Words can be written on Monday and measured on Friday — and when they're delivered through a guidance layer rather than the codebase, they don't even need a release.
-
It carries the mental model
Users build a theory of how your product works from the words it uses. Consistent, honest naming makes that theory correct; shifting terminology ("workspace" here, "project" there, "board" in the docs) makes it wrong, and a wrong mental model produces support tickets forever.
-
It's where your product's manners are visible
Tone at the failure points — the error, the limit, the "you can't do that" — is what users remember. A product that explains problems without blaming the person reading earns forgiveness for the next one.
-
It's the cheapest fix for the drop-offs you can't explain
When analytics shows a stall at one step and the design looks fine, the words are usually the suspect. Rewrite them before you rebuild anything — it costs a day and rules out the likeliest cause.
Three Formulas Behind Microcopy That Works
Short copy is not improvised. Three patterns cover most of the interface:
Most microcopy is one of three shapes: verb + outcome for buttons, what/why/next for errors, and what/payoff/action for empty states.
1. Buttons: verb + the user's outcome
Not the system's action ("Submit form") but the person's result ("Send my invite", "Start free trial", "Delete 3 reports"). The label should survive being read alone — because it will be — and should make the consequence obvious before the click, especially where money or deletion is involved.
2. Errors: what happened + why + what to do next
In that order, in the user's language, placed next to the thing that failed. Never lead with a code, never use "invalid", and never phrase it as something the user did wrong. The test: could a person fix this without leaving the screen or contacting support? If not, the message is incomplete.
3. Empty states: what this screen is for + the payoff + one action
An empty state is the first thing a new user sees on every screen, which makes it the highest-traffic onboarding surface in the product. Three sentences and a button turn a dead end into a starting line — and the button should be the single most useful next action, not a link to documentation.
Microcopy Examples: 40+ Before-and-After Rewrites
The same screen, twice — first written for the system, then written for the person using it:
Nothing changed except the words. The left screen tells a new user that the product is empty; the right one tells them what they're about to get and hands them the shortest path to it.
Buttons & calls to action
- "Submit" → "Create my first report"
- "OK" → "Delete 3 reports"
- "Continue" → "Continue to payment"
- "Save" → "Save and publish to my team"
- "Get started" → "Connect my data source"
- "Sign up" → "Start free — no card needed"
- "Confirm" → "Send 12 invitations"
- "Learn more" → "See a 60-second example"
Empty states
- "No results found." → "No reports match those filters. Try widening the date range."
- "You have no projects." → "Projects keep your work separate per client. Create your first one →"
- "Nothing here yet." → "Your team's activity will appear here once someone publishes. Invite a teammate →"
- "0 integrations" → "Connect a data source to see live numbers instead of samples."
- "Inbox empty" → "You're all caught up. New requests land here as they arrive."
Error messages
- "Something went wrong." → "We couldn't save your changes — the connection dropped. Your draft is safe; try saving again."
- "Invalid email." → "That address is missing an @ — check for a typo."
- "Upload failed." → "That file is 12 MB; the limit is 5 MB. Try compressing it or uploading a CSV."
- "You entered an invalid value." → "Dates need to be in DD/MM/YYYY format — for example 24/07/2026."
- "Access denied." → "Only workspace admins can change billing. Ask your admin, or request access →"
- "Error 500." → "Something broke on our side, not yours. We've been alerted — try again in a minute."
Forms & fields
- "Name" → "Workspace name — your team will see this"
- "Password" → "Password — at least 10 characters" (shown before typing, not after failing)
- "Company size" → "How many people will use this? We use it to set sensible defaults."
- "Phone (optional)" → "Phone — only used if a report fails overnight"
- "URL" → "Your site's address, e.g. app.yourcompany.com"
Tooltips & contextual hints
- "Filters" → "Narrow this list by plan, date, or owner"
- "Segments" → "Save a group of users once, then target it in any tour or survey"
- "Archive" → "Hides this from the list without deleting the data"
- "Sync" → "Pulls the latest rows from your warehouse — takes about 30 seconds"
Confirmations & destructive actions
- "Are you sure?" → "Delete this workspace? Its 42 reports and history go with it. This can't be undone."
- "Cancel subscription?" → "Cancel on 30 August? You keep full access until then, and your data stays for 90 days."
- "Discard changes?" → "Discard your edits to this report? The last saved version stays as it was."
Success & progress
- "Success!" → "Report published — your team can see it now."
- "Saved." → "Saved. Changes are live for everyone in this workspace."
- "Loading…" → "Crunching 40,000 rows — about ten seconds."
- "Step 2 of 5" → "Step 2 of 5 — two minutes left"
Permission & opt-in asks
- "Allow notifications?" → "Want an alert when a report fails? We'll only notify you about failures."
- "Subscribe to updates" → "Get an email when we ship something you asked for — about once a month."
- "Accept cookies" → "We use analytics cookies to see which features get used. You can decline and everything still works."
The pattern across all of them: the improved version adds the one piece of information the product already had and the user didn't — the consequence, the limit, the format, the timing, the payoff. Almost no microcopy work is creative writing. It's disclosure.
Microcopy Best Practices: 7 Rules
1. Write the outcome, not the mechanic
Every label, hint and heading should answer "what do I get?" before "what does this do?". Users don't want to configure a segment; they want to stop emailing the wrong people. Lead with the second thing.
2. Use the user's vocabulary, not your schema's
Internal names leak into interfaces the moment nobody's guarding the door — "entity", "workspace object", "flow trigger". If a term appears in your database and in your onboarding, one of them is wrong. Listen to how customers describe the thing in support tickets and use that word everywhere, consistently.
3. Say it where the doubt is
Requirements belong beside the field, not in a help article; consequences belong on the button, not in a footnote. Contextual placement is what separates microcopy from documentation, and it's why tooltips and inline hints outperform even excellent help centres for first-run comprehension.
4. Front-load the words that carry meaning
People scan the first two or three words of anything. "Connect Stripe to see revenue" survives a scan; "In order to see revenue data, connect your Stripe account" does not. Cut throat-clearing openers — "Please note that", "In order to", "You can now" — and start with the verb or the noun that matters.
5. Take the blame, always
"We couldn't process that" not "You entered an invalid value". The user's error is usually the interface's failure to say what it wanted, and even when it isn't, blame changes nothing except how the person feels about your product at their least patient moment.
6. Keep terminology consistent across every surface
The same concept should carry the same name in the UI, the tooltips, the onboarding, the release notes and support replies. Maintain a short shared glossary of the 20 terms your product actually uses — it's the cheapest documentation your team will ever write and it prevents the most expensive confusion.
7. Ship, measure, rewrite
Microcopy is the one part of the interface where you can run a genuine before-and-after in a week: change the words on the step with the worst drop-off, watch completion for seven days, keep or revert. Do that three times on your signup flow and you'll learn more about your users than a quarter of interviews.
UX Microcopy: Do vs. Don't
✅ Do
- Name the outcome on every button
- State requirements before the user fails them
- Give errors a what, a why, and a next step
- Turn empty states into starting lines
- Use one word per concept, everywhere
- Put the copy where the doubt happens
- Say what an irreversible action will destroy
- Test wording on your worst drop-off step
❌ Don't
- Ship "Submit", "OK" or "Continue" as final labels
- Reveal password rules only after a failed attempt
- Lead an error with a code or the word "invalid"
- Leave "No data" as an empty state
- Let internal object names reach the interface
- Bury requirements in a help centre article
- Ask for permissions before explaining the benefit
- Treat wording as the last five minutes of a design
Shipping and Testing Microcopy Without a Release Cycle
The frustrating part of microcopy work is not writing it — it's that improving a sentence usually means a pull request, a review, a deploy, and a two-week wait to learn whether it helped. The guidance layer doesn't have to work that way. With Kompassify you can put contextual words on top of your live product without touching the codebase:
- Write hints where they're needed. Anchor a tooltip to any element and explain it in the user's words — published live, no release ticket.
- Rescue dead-end screens. Layer guidance and a clear next action onto empty states and stalled steps, so a blank screen becomes a starting line.
- Say it differently for different people. Show one wording to trial users and another to admins by segment — the same control, explained in the language of whoever's looking at it.
- Measure the rewrite. Built-in analytics show completion for the steps your copy touches, so "does this wording work?" becomes a number instead of an opinion.
- Keep it consistent. Tours, checklists, tooltips and announcements come from one place, so your terminology stays the same across every guidance surface.
Kompassify is GDPR compliant and EU-hosted, free for under 100 monthly active users, with paid plans from $129/month.
Put the Right Words in the Right Place
Kompassify lets you add contextual tooltips, guidance and onboarding copy on top of your existing product — no code, no release cycle. Explain the confusing control, rescue the empty screen, and measure whether the new wording actually moved completion. GDPR compliant, EU-hosted, and free for under 100 monthly active users.
Start for Free →Frequently Asked Questions
What is microcopy in UX?
Microcopy is the small interface text that guides a user through a product: button labels, form hints, empty-state messages, error messages, tooltips, placeholder text, confirmation dialogs and success notices. It is called micro because each piece is a handful of words, not because its impact is small — these are the words users actually read, at the exact moment they are deciding whether to act. Where marketing copy persuades someone to try a product, microcopy determines whether they can use it.
Why is microcopy important?
Because it sits at the decision points. A user who hesitates at a button, misreads a form field, or hits an error they can't interpret does not file a complaint — they leave, and your analytics record a drop-off with no explanation. Rewriting the words at those moments costs an afternoon and no engineering time, and it removes friction that a redesign would take a quarter to address. Microcopy is also the cheapest thing to test: it is the only part of the interface you can change, measure, and change again in the same week.
What makes microcopy good?
Four things. It is specific — it names the actual outcome ('Create your first report') instead of a generic verb ('Submit'). It is written from the user's point of view, in the words they would use, not your internal feature names. It arrives at the moment of doubt rather than in documentation elsewhere. And it takes responsibility when something goes wrong: a good error message says what happened, why, and what to do next, without blaming the person reading it.
What is the difference between microcopy and UX writing?
UX writing is the discipline; microcopy is the output. UX writing covers the whole practice — voice and tone, terminology systems, content design, information hierarchy, the decision of whether a screen needs words at all. Microcopy is the concrete text those decisions produce at the level of a button, a hint, or an error. In small teams the distinction rarely matters; what matters is that someone owns the words with the same seriousness the interface gets.
How do you write good button microcopy?
Name the outcome, in the first person of the user's intent. 'Start my free trial' beats 'Submit'; 'Send invite' beats 'Confirm'; 'Delete 3 reports' beats 'OK'. Two rules follow from that: the label should make sense read on its own, out of context, because that is how it will be scanned; and it should tell the user what will happen after the click, especially when the action is irreversible or costs money. If a button needs an explanatory sentence beside it, the label is doing too little work.
How do you write a good error message?
Three parts, in order: what happened, why, and the next step — in plain language, with no error codes as the headline and no blame. 'That file is 12 MB; the limit is 5 MB. Try compressing it or uploading a CSV instead' does the whole job. Avoid the classic failures: vague ('Something went wrong'), accusatory ('You entered an invalid value'), and technical ('Error 422: unprocessable entity'). And put the message next to the thing that failed, not in a banner at the top of a long form.
Can you change microcopy without a code release?
Some of it, yes. Text baked into your components needs a release, but the guidance layer around them — tooltips, onboarding hints, empty-state prompts, contextual explanations, announcement copy — can be delivered on top of your product with a no-code tool like Kompassify: write the words, anchor them to the element, target a segment, and publish live. That makes microcopy testable in days rather than sprints, which is how you find out which wording actually moves completion rates. Kompassify is GDPR compliant and EU-hosted, free for under 100 monthly active users, with paid plans from $129/month.