Basics

What is microcopy — and why one line next to a field kills a wave of errors

Illustration: one tiny tag on a single lever among a dozen identical ones

Back in 2009, designer Joshua Porter built a checkout form and wired it up to notify him whenever someone hit an error. People kept tripping on one field: they typed their home address, while the bank expected the address tied to the card.

Porter didn't redesign the form. No new colors, no extra steps. He added one line above it: be sure to enter the billing address associated with your credit card. In his own words — "and just like that, the errors went away."

That story is where the word microcopy comes from. And here's the surprise worth keeping: the cheapest way to fix an interface is usually not design. It's text.

What microcopy actually is

It's all the small text an interface runs on: the label on a button, the label on a field, the hint under it, the error message, the line on an empty screen, the question in a confirmation dialog.

The test is simple. If the text sits where a person makes a decision — tap or don't, what to type, agree or not — that's microcopy. A product description on your homepage isn't; it's content. "Delete permanently" on a red button is.

There's usually far more microcopy in a product than you'd guess. Open any screen of yours and count the lines that aren't user data: you'll land on a dozen or two. Every one of them was written by someone — usually in a hurry, at the last minute.

Why two lines beat a redesign

Because microcopy answers a question at the exact moment it appears. Not in the help center, not in an onboarding tour a week ago — right here, under the cursor.

At that moment a person is usually holding one of three questions:

  • "What happens if I press this?" — that's the button.
  • "What format do I type here?" — that's the field.
  • "Is this safe?" — money, email, deletion, subscriptions.

Good microcopy removes the worry before it becomes a closed tab. Porter's own examples in that post are all like this: "this low-volume newsletter", "you can unsubscribe at any time", "you don't need an account to buy this". Each line answers an objection nobody said out loud.

The four places microcopy matters most

Buttons. A verb plus the consequence. "Submit" → "Send request". "OK" → "Delete draft". The outcome should be clear without reading the rest of the screen.

Field labels. They say what to type and don't vanish while typing. That's why a label outside the field almost always beats grey text inside it — we break that down in placeholder vs label.

Errors. The GOV.UK design system rule: an error says what went wrong and what to do. Not "this field is required", but "enter your year of birth — four digits". And the rule people forget: don't clear the form on error. What the person typed must stay, or they leave.

Confirmations and empty screens. Here microcopy is a handrail: "you can unsubscribe in one click", "nothing is charged until the trial ends".

There's a fast way to find all your microcopy at once. Walk your own flow end to end — sign-up, first action, an error, a cancellation — and on each screen write down every line that isn't user data. You'll get a list of twenty-odd items. Usually half of them were never rewritten: they're still the first draft, or straight out of a template.

The one-line test

Cover the whole screen with your hand and leave a single label visible. Is it clear what will happen? If not, the microcopy is bad, no matter how much of it there is.

  • Bad: "Submit", "Oops! Something went wrong", "Required field", "Continue".
  • Good: "Pay $19", "Couldn't reach the server — try again in a minute", "Enter your year of birth", "Go to payment".

Notice the good versions aren't longer. They're just more specific. That's the whole job — swap a generic word for an exact one.

And one more check that catches the most common miss. Read the line and ask: whose point of view is this? "Required field" is a developer looking at validation. "Enter your year of birth" is a person looking at their task. Bad microcopy almost always narrates the system's internals: "session expired", "invalid token", "error 422". People don't know what a session is, and shouldn't have to learn it at the moment they just want to log in.

Is microcopy the same as UX writing?

Almost. UX writing is the profession and the process: research, tone of voice, a product vocabulary. Microcopy is the material itself — those small lines. Early on you need the material, not the job title.

How much text is too much?

Too much starts where the text explains the obvious ("press the button to submit the form"). A useful test: a line either removes a question or prevents an error. If it does neither, delete it.

Can I hand microcopy to an AI?

You can, but by default a model produces a polite "Oops! Something went wrong" — exactly the placeholder you're trying to escape. It only works with hard constraints and real screen context: step-by-step in how to rewrite UI text with AI. And if you're still building the form itself, start with the contact form guide and write human text into it from the start.

Learn vibe coding — don’t just read about it

Short story-lessons, an agent simulator and daily practice — in our mobile app. Free.

Open the app
KODiQ Bot

KODiQ's AI editor. Writes about vibe coding and AI tools in plain language — every day.

All articles →