Microcopy and UX writing

Microcopy is the short text of an interface: button labels, field labels and hints, error messages. The work of writing it is called UX writing.

The smallest texts

The label on a button, the explanation under a field, the line “Something went wrong”, the word “Done”: texts of this size are called microcopy. They are written with no less care than articles, and read more often, because nobody can get through a form without reading them. The profession that does this is called UX writing, “writing for the interface”; government services, for example the UK’s GOV.UK, call it “content design”.

Nielsen Norman Group’s researchers distinguish three jobs of microcopy. It informs (a headline, a hint), helps people act (a field label, the text of an error) and influences a choice (a call to action, a slogan). All three meet in a request form, where a person decides whether to trust you.

This is an important place. A page can be skimmed, a visitor may not finish a paragraph, but a form is either filled in or not. If they didn’t understand what happens after the button, or got the message “Error 422”, they leave. Often this is the site’s last contribution to whether you get a message or a phone call. And the good news is that work on microcopy is cheap: a few lines, and the result shows at once.

Check yourself: what are the three jobs of microcopy?

To inform, to help people act (labels, errors), and to influence a choice (a call to action).

A button names the action

The most noticeable line of a form is the button. The word on it should answer “what will happen when I press it?” “Submit” answers “what will the form do”: it will send the data. But the person needs to know what they will get: they’ll book, order or ask a question.

A practical rule: a verb plus what the person gets. “Book a consultation”, “Request a call”, “Get a quote”, “Join the club”. The test: put the name after the words “I want to…”. “I want to book a consultation” sounds right. “I want to submit” doesn’t.

You have already thought of this phrase: it’s written in the brief as the main action. The button, the headline of the form and the link from the home page name it the same way. That way a person going from the home page to the form never stumbles on a new word.

Two more rules. There is one main-action button: beside it “Cancel” or “Back” are made quieter, not just as bright. And dangerous actions are named plainly: “Delete request”, not “Yes”. A window asking “Are you sure?” with “Yes” and “No” makes people read the question again.

Check yourself: how do you check that a button is labeled well?

Finish the sentence “I want to…” with the button’s name. If it sounds natural (“I want to book a consultation”), the label is good.

Labels and hints

Every field needs a label. It stands above the field or beside it and stays visible while the person types. There is a common trap here: the label is written inside the field in gray type (a placeholder), and the job is considered done. But as soon as the person starts typing, the label vanishes and they no longer remember what it was. Gray type is hard to read, and screen readers don’t always announce it. A hint inside the field can stay as an example (+1 000 000 0000), but not in place of a label.

The second hint stands under the field and answers “why are you asking for this?” Phone: “We’ll call to give you a time”. Email: “We’ll write when it’s ready. No mailing list”. People give more readily what they understand the reason for. And if you can’t explain why a field is needed, maybe it isn’t: the shorter the form, the more people get to the end. We’ll come back to this in the part on persuasion, with the Fogg model.

Make labels conversational questions or short nouns: “What should we call you” instead of “Full name” (if you don’t need the surname), “Phone number” instead of “Contact details”. Mark what’s required in words: “(optional)” or an asterisk with an explanation at the top of the form. An asterisk with no explanation says nothing.

Check yourself: what is wrong with writing a label only inside the field?

It disappears when the person starts typing, it is hard to read, and it isn’t always available to screen readers. A label should stay visible above the field.

Error messages

An error is the most unpleasant thing that happens in a form, and the words decide whether the person fixes it or leaves. A good message has three parts:

1. What happened. “The number is missing some digits.”
2. What to do. “Write the whole phone number.”
3. An example, if there is a format. “For example, +1 000 000 0000.”

What shouldn’t be in it: codes (“Error 422” is a programmer’s language; the code can stay, small, at the end for support), reproach (“you entered it incorrectly”; describe the situation, not the person) and officialese (“an invalid value has been entered in the field”). Don’t write in capitals or use many exclamation marks: the person is upset enough.

Three technical conditions. The message stands beside the field, not only at the top of the page. It doesn’t rely on a single color: a red border with no words can’t be seen by someone who is color-blind or blind. And what was typed isn’t erased: nothing is worse than filling in a whole form again because of one digit. The accessibility standard WCAG asks for exactly this: identify the error in text and, where possible, suggest a fix (success criteria 3.3.1 and 3.3.3, linked in the sources). The GOV.UK Design System has a well-tested pattern for the same thing.

Compare two versions of one form in the diagram. Switch the moment to “Error in the phone” and tap a text: the diagram explains what is wrong with it and what was done.

Before After

Filling in Error in the phone Sent

Contact form Full name *

 

Phone *

 

By clicking this button you agree to the privacy notice Submit

Tap any text in the form: you’ll hear what’s wrong with it or what was done.

Check yourself: what are the three parts of a good error message?

What happened, what to do, and an example of the right format.

After sending, and beside the consent

When a person has pressed the button, they wait: “did it arrive or not?” The message after sending answers three questions:

• Did it arrive. “Request received.”
• What next, and when. “We’ll call you today before 6 p.m.”
• What if not. “If we can’t reach you, we’ll send a text. Changed your mind? Call us.”

A time in such a message is a promise, and promises have to be kept. Don’t write “shortly” if in fact you reply every other day: an honest deadline offends less than a broken one.

Now the consent. The form collects a name and a phone number, which are personal data, and the law cares how you use them. The full legal side comes in the sixth lesson and in part 15. For microcopy, remember three things:

1. Consent, where you rely on it, is a separate act, a checkbox. Not a phrase like “By clicking the button you agree…” that can’t be declined.
2. The box is unchecked by default. A box checked in advance counts as a dark pattern (more in the part on persuasion): the form makes the decision for the person. Under the GDPR and the UK GDPR consent must be a clear affirmative act, and pre-checked boxes are named as not valid (Recital 32); the EU’s top court said so in the Planet49 case in 2019.
3. The text is clear without a lawyer. “I agree to you using my name and phone number to contact me about this request. More in the privacy notice.” It says what for, why and where to read more.

A caution that matters: under the GDPR a contact form often doesn’t need consent at all, because answering the person’s inquiry can rest on another lawful basis. Then a plain notice beside the form does the job. In the US, most state laws ask for a notice at the point of collection rather than a checkbox. Russia’s law (152-FZ) leans harder on consent and, since 2025, wants it as a separate document. This is general information, not legal advice: have a lawyer read your consent wording, or ask your data protection authority (in the UK the ICO).

Check yourself: what should the message after a request is sent contain?

That the request is received, what happens next and when, and what to do if contact doesn’t happen.

When microcopy lets you down

• Cuteness in the wrong place. A joke in a “Couldn’t save” window irritates a person who has lost their data. Lightness is right when nothing is breaking, and we’ll talk about tone later.
• Shaming. A decline button that says “No thanks, I don’t like saving money” is a technique called confirmshaming: the person is shamed for their decision. An honest decline is neutral: “No, thanks”.
• Invented urgency. “Only two places left!” when there are no places and never will be. This is deceit, and such techniques are looked at in detail ahead. Regulators treat them the same way: the US FTC’s 2022 report on dark patterns names fake urgency, and the EU’s Digital Services Act (Article 25) bans online platforms from interfaces that deceive or manipulate users.
• Too short. Cut for clarity, not to count words. The message “Error” is short and useless.

Check yourself: why is “No thanks, I don’t like saving money” a bad button label?

It shames the person for declining, so that they’ll stay. An honest decline button is neutral: “No, thanks”.

Practice

In the preview is your project’s main-action form: the fields are there, the words are not. Fill them in.

1. The form headline in an h2 with the class form-title: name the action.
2. The labels of two fields in label elements and the hints under them in a span with the class hint: why you are asking for this data.
3. The consent text in a label with the class consent: what for, why, where to read more. Don’t check the box.
4. The button text for the main action from the brief, in the same words.
5. In the note “What the site will say”: three error messages and the message after sending, with a time.

The preview won’t show error messages: on a real page a script shows them, like the phone hint in the lesson on progressive enhancement. For now it’s enough to write them and check them against the list: what is wrong, what to do, an example.