Microcopy: The Cheapest Conversion Work Available
Rewriting a button, a label, an error and an empty state costs an afternoon and moves more than a redesign does. Here is what to change, why each rewrite works, and where microcopy cannot save you.
On This Page
A team spends six weeks moving a form above the fold, rebuilding it in two columns and adding a progress bar. Completion barely moves. Then somebody changes the button from "Submit" to "Send my enquiry", adds one line under the phone field explaining why it is being asked, and rewrites the error that fires when a date is in the past. That took an afternoon.
This is not a trick and it is not a growth hack. UX microcopy is the highest-yield work per hour available in most interfaces, for a reason that has nothing to do with persuasion: layout decides where a person looks, and words decide what they believe is about to happen. Doubt about what happens next is what stops people, and no arrangement of boxes answers it.
The five surfaces carrying almost all of it are buttons, field labels and helper text, error messages, empty states, and confirmations. Every one of them is a string in a file. None needs a design review, a component change or a release train, which is precisely why they get neglected. Nothing in the process forces anybody to own them.
What follows is the rewrite pattern for each surface, with the reasoning, because the reasoning is what lets you do the next one without asking anyone.
Why UX microcopy beats most layout changes
Layout changes are expensive because they are entangled. Moving a form means touching a grid, a breakpoint, a component and probably a test. Words are entangled with nothing. One string, one deploy, no regression surface beyond the string itself.
Cheapness is only half the argument though. The other half is that most abandonment is caused by a question the interface refused to answer. Three questions, really, and they repeat everywhere.
- What is about to happen to me? Will this send something, charge something, publish something, or merely move me to the next step? A button labelled with a real verb answers it. A button labelled "Continue" does not.
- Why are you asking me this? Every field whose purpose a user cannot work out is a small negotiation. Some of those are lost silently, in the sense that the person simply leaves.
- What do I do now? This is the one errors and empty states are supposed to answer and usually do not, because both get written last, by whoever is nearest.
A layout change can improve how quickly somebody finds the answer. Only words supply the answer. That is the whole hierarchy, and it is why we run a copy pass before proposing structural work in product design: it is cheaper, it is reversible, and it frequently removes the reason for the structural work.
Buttons: name the outcome, not the mechanism
"Submit" describes what the browser does. "Send my enquiry" describes what the person does. The second is better for an unremarkable reason: the user is deciding whether to do a thing, and the label is the only place that thing is named.
The rewrite, and the reasoning
"Sign up" becomes "Create a free workspace". The first describes registration, which nobody wants. The second describes the thing that will exist afterwards, which is what they came for, and it states the price in passing. "Learn more" becomes "See how pricing works", because "Learn more" forces the reader to guess the destination from surrounding context, and anybody scanning the links alone gets nothing at all.
One caution against enthusiasm. Buttons should be predictable before they are charming, and a witty label on a destructive action is a genuine hazard. "Yeah, bin it" is funny once and dangerous every other time. Keep personality for places where nothing irreversible happens and keep the rest boring. Where the same labels recur across a whole site, they also become a brand guidelines question, best answered with a short list of approved patterns rather than a paragraph about tone.
Labels and helper text: answer the question being asked
Start with the mechanical part, because it is non-negotiable and often wrong. Every field needs a real label element tied to its input. Placeholder text is not a label: it vanishes the moment somebody types, it usually sits at poor contrast, and it leaves screen reader users with an unnamed field. A form that labels by placeholder is broken before any of the copy questions arise.
Then the copy question, which is one question: why are you asking? A phone number field with no explanation reads as a sales trap. The same field labelled "Phone (optional)" with a line saying it is used only if email bounces reads as thoughtful. Nothing changed except that the reason was stated.
Run the "why are you asking" test
Go through the form field by field and answer, out loud, why each one exists and what happens to the value. Fields that survive get a one-line reason wherever the reason is not obvious. Fields that do not survive get deleted, which is the better outcome, because a form is not a container for everything the business might one day want. Our parent company puts this well in a form is a triage instrument: every field should earn its place by sorting enquiries, not by hoarding data.
Two more habits worth adopting. Put format guidance before the input rather than after the failure, so an expected date format or a password rule is visible while somebody types instead of arriving as a rebuke. And mark the optional fields rather than the required ones when most are required, because the shorter list is the one people actually read.
Errors: what happened, and what to do now
An error message has exactly two jobs: say what went wrong, and say what to do about it. "Invalid input" does neither. "Enter a date in the future, for example 12/03/2027" does both, in the same number of pixels. WCAG 2.2 asks for errors to be identified in text and for a suggestion to be offered where one is known, which is a usability requirement that happens to be written down as an accessibility one.
The announcement matters as much as the wording. An error that appears visually but is never announced leaves a screen reader user resubmitting the same form with no idea why it will not go through. ARIA live regions handle that, and moving focus to the first field in error handles the rest. Copy and mechanism are the same job here, which is why a microcopy pass should never be handed to somebody who cannot also change the markup.
Tone, and who gets blamed
Do not apologise theatrically and do not blame the reader. You entered an invalid email is an accusation; "That email address is missing an @" is an observation with the fix inside it. Server failures are the opposite case: say plainly that it was your fault, say whether the data was kept, and say what to do. "We could not save this. Your text is still here, try again in a moment" respects the person more than any amount of sorry.
Do not write error strings in a spreadsheet. Open the real product and break it: submit the form empty, use an expired card, upload the wrong file type, turn off the network mid-save. You will find errors with no copy at all, copy attached to errors that can no longer occur, and at least one message written for a developer who has since left. That inventory is the actual work. The rewriting takes an hour.
Empty states: the screen nobody mocks up
Every new user starts here, and almost every design file starts with the screen full of data. So the first thing somebody sees after signing up is frequently the least considered screen in the product: a grey box, an illustration, and the words "No items yet".
An empty state has one job and it is not decoration. Say what goes here, why it is worth having, and give the one action that fills it. Three short lines. "Nothing matches blue widget. Try a shorter search, or clear the two active filters" beats "No results found" because it names the cause and offers the exit.
The related surfaces are the ones between empty and full: loading, waiting, partial failure. Those deserve their own treatment, and we have written about the states nobody mocks up separately. The common thread is that a person left in an unresolved state will invent an explanation if you do not supply one, and the explanation they invent is almost always worse than the truth.
Confirmations: what changed and what happens next
"Your changes have been saved" confirms a mechanism. "Saved. Your team will see this the next time they open the project" confirms an effect, which is what the person wanted to know. The same applies at the end of a form: a thank-you page that repeats the words "thank you" three times and says nothing about what happens next has wasted the only moment when the reader is paying full attention.
Destructive confirmations follow the opposite rule: be specific about the damage. "Are you sure?" is not a safeguard, because nobody reads it after the second time. "Delete this project and everything in it? This cannot be undone" names the scope and the permanence, and gives somebody a reason to stop.
A redesign changes what a screen looks like. A rewrite changes what somebody believes is about to happen to them.
Before and after, with the reasoning
The rewrites below are ordinary. That is the point: none of them required research, and all of them can be argued for from first principles in a single line.
| Before | After | What changed |
|---|---|---|
| Submit | Send my enquiry | Names the outcome, so the reader knows what leaves their hands |
| Sign up | Create a free workspace | Describes what will exist afterwards, and states the price in passing |
| Learn more | See how pricing works | Says where the link goes, which also helps anyone scanning links alone |
| Invalid input | Enter a date in the future, for example 12/03/2027 | Says what is wrong and shows an acceptable value |
| No results found | Nothing matches blue widget. Try a shorter search or clear the filters | Names the cause and offers a next action instead of a dead end |
| Your changes have been saved | Saved. Your team will see this the next time they open the project | Confirms the effect rather than the mechanism |
| Are you sure? | Delete this project and everything in it? This cannot be undone | States the scope and the permanence of the damage |
| Optional | Optional. We only use this if your email bounces | Gives the reason, so answering feels like a choice rather than a levy |
How to run a microcopy pass
One person, one day, in this order. The order matters more than the writing skill does.
- Inventory the strings on one flow. Pick the flow carrying the most consequence, usually signup or checkout, and list every string in it including the ones that appear only when something fails.
- Walk it as a first-time user, on a phone. Not as the person who built it. Note every place you paused, and write down the question you were asking at that moment in your own words.
- Break it deliberately. Empty submissions, wrong formats, expired states, no network. Screenshot everything that appears. The worst copy lives here, and it is invisible from a design file.
- Rewrite against the three questions. What is about to happen, why are you asking, what do I do now. Any string that fails to answer the question its screen raises gets rewritten or removed.
- Check the announcement, not only the appearance. Tab through with a keyboard, confirm errors are announced and focus lands somewhere sensible, and verify that no field is labelled by placeholder alone.
- Ship in one batch and note the date. Shipping strings one at a time makes the effect impossible to see. One batch, one date written down, and something to compare against later.
Whether you then test formally or simply watch what happens is a judgement call with real arguments on both sides, and it is the subject of testing with five users or shipping and measuring. For copy specifically we lean towards shipping, because the changes are reversible and the cost of being wrong is one more deploy.
Where microcopy cannot help you
Now the concession, and it is a substantial one. Microcopy fixes doubt. It does not fix a weak offer, a wrong price, a flow with too many steps, or a product that does not do the thing the visitor came for. If people are leaving because the honest answer is no, better words make the no arrive sooner, which is useful and is not conversion work.
It also cannot rescue a structure that has outgrown itself. If a visitor cannot find the section they need, the fix is information architecture rather than a better link label, and the honest version of that conversation is a site that has outgrown its menu. Rewriting labels on a broken hierarchy produces well-worded confusion.
One more surface worth naming, because it is growing quickly and is written by nobody in particular: the words an assistant or chat widget uses. A widget such as Flidu puts website-informed answers and contact actions in one place, and every string around it is microcopy under another name: the greeting, the placeholder, the handover to a human, and above all the refusal. Getting the refusal right is its own discipline, covered in keeping an assistant from promising something you do not sell.
The decision rule we would apply: if somebody knows what they want and hesitates, it is a words problem and you should spend the afternoon. If they do not know what they want, or want something you do not offer, it is a positioning problem and words will only make the exit more polite. Sorting those two apart is the first hour of any conversion work worth paying for.
And if the strings across your product have drifted apart because six people wrote them over four years, that is a verbal identity problem with a copy pass attached. Send us the flow that worries you most and we will tell you which of the two it is: start here.
Common questions.
What is microcopy in UX?
Microcopy is the small functional text inside an interface: button labels, field labels and helper text, error messages, empty states, confirmations, tooltips and system notices. It differs from marketing copy because its job is to remove doubt at the moment of action rather than to persuade. It is usually the cheapest part of an interface to change and one of the most consequential.
How do you write a good error message?
Say what went wrong and what to do about it, in that order, in plain language. Avoid blaming the reader: describe the problem rather than accusing them of causing it, and show an acceptable value where one exists. If the failure was on your side, say so and confirm whether their input was preserved. Make sure the message is announced to assistive technology, not merely displayed on screen.
Should button labels use verbs?
Yes, and the verb should describe the outcome for the person rather than the action for the system. Send my enquiry, create a workspace and see pricing all tell the reader what happens next, while submit, continue and learn more make them guess from context. The exception is destructive actions, where the label should be unambiguous and unfunny, naming exactly what will be removed.
Is placeholder text an acceptable substitute for a label?
No. Placeholder text disappears as soon as someone starts typing, which removes the field name exactly when it is needed for checking an answer. It also tends to sit at low contrast and it leaves the field unnamed for screen reader users. Use a persistent visible label attached to the input, and keep placeholders for format examples if you use them at all.
How do you write a button label that converts?
Name the outcome the person gets rather than the mechanism they operate. "Get the audit" beats "Submit", because the label carries the reason for clicking instead of describing the form. Keep it to a few words, match the wording of the heading above it so the promise does not shift between them, and never let two buttons on one screen compete for the same primary action.
How often should interface copy be reviewed?
Review the strings on any flow you change, and run a full pass over the highest-consequence flow once or twice a year. Copy drifts quietly as different people add features, and the drift stays invisible until somebody reads the whole flow in one sitting. Break the flow deliberately during that review, because failure states hold the oldest and worst text in most products.
Facing this in your
own business?
Tell us where you’re headed — we’ll map the shortest honest route.