UX Microcopy That Helps People Finish

It's 11:40 at night, and Bettina is trying to send her first invoice. She's a freelance illustrator, the job is finished, and she'd like to be paid before the month ends. She fills in nine fields, presses "Submit" and gets "Invalid input."

The form doesn't say which field it means. She tries twice, then closes the tab and goes to bed with the invoice unsent.

Bettina is invented, and so is Quaymark, her invoicing app. Quaymark's ads and its landing page had already done their work, because she'd signed up. What stopped her was UX microcopy, the small text inside a flow that explains an action or helps someone recover.

The UK Home Office shows a more useful error. It uses a passport question, "When was your passport issued?", and its example error reads "The date your passport was issued must be in the past." The message names the rule, so the person knows what to change.

Three questions for reviewing a flow

Bettina's screen failed a simple test. Use these three questions to review the flow.

The microcopy test

Where am I?

• What is this screen or field, and what does it want from me?

What just happened?

• Did that work? If it failed, whose problem is it and was anything lost?

What do I do now?

• What's the next action, and what will happen when I take it?

"Invalid input" told Bettina something failed and stopped there. If a line helps someone answer a question, keep it and use the principles in how to write clear copy to make it plainer. If it doesn't, it's probably decoration, and clever decoration in a failure state tends to annoy.

Buttons

Bettina's "Submit" button hid what it actually did, which was send an invoice to a client. The GOV.UK Design System says to write buttons in sentence case and describe the action, with examples like "Start now" and "Sign in." In Quaymark, the label can name the recipient too.

Quaymark: the last step of an invoice

Generic

Submit

Says what happens

Send invoice to Priya Holm

Naming the action and the recipient also lets people catch a wrong recipient before anything is sent. Invented example.

Check what the product does before you pick the verb. GOV.UK uses "Continue" when a service doesn't save the person's information and "Save and continue" when it does. People want to know whether they're about to lose their work.

Near a commitment, a short line under the button can finish the promise: "You won't be charged until your trial ends on June 3." The call-to-action lesson goes deeper on button wording.

Labels, hints and placeholders

In Quaymark, the due-date format sat inside the empty box as placeholder text. It vanished on Bettina's first keystroke. NN/g's article on placeholders puts the harm in its title: the text disappears as you type, which strains memory and makes answers harder to check before submitting.

The same article recommends a visible label outside the field. Name the field in the reader's words, so "Business name" beats "Entity," and put the hint outside the box too, where it stays while someone types.

A hint can also say why you're asking, right where people decide whether to answer: "We'll only call if there's a problem with your payout."

One field, two ways

Placeholder doing all the work

• Empty field reading: 'Tax ID (9 digits, no dashes)'
• The instruction vanishes on the first keystroke
• Looks already filled in to some people
• Nothing left to check against at the end

Label and hint

• Label: Tax ID
• Hint: 9 digits, no dashes.
• Hint stays while you type
• The person can check their answer before moving on

Error messages

This is where Bettina gave up, so it's where I'd look first. NN/g's error-message guidelines ask for plain language, a message placed next to the problem and no blame. They name "invalid," "illegal" and "incorrect" among the words to avoid.

The Home Office guidance adds that a message should explain the error and what caused it, without relying on colour alone. WCAG's error-identification criterion asks for detected errors to be described in text. A red border round Bettina's field wouldn't be enough.

GOV.UK says to be specific and never to clear what someone has typed. It keeps ineligibility and capacity problems off error messages altogether, because no correction will help. Those get their own page.

GOV.UK also tells writers to avoid "please" in error messages, "because it implies a choice." Someone who wants to finish has no choice, so the polite word misdescribes the moment. The same page rules out "sorry" and jokey words like "oops."

"Oops!" on a failed payment reads as though the company isn't taking your money seriously. When you're tempted to be charming, read the line aloud in the voice of someone who has just lost twenty minutes of work.

Rewriting Quaymark's errors

Empty field

Now: Enter the client's email so we know where to send this invoice

Was: This field is required

Bad format

Now: Enter the due date as month, day and year, like 06/30/2027

Was: Invalid date

Payment failed

Now: Your bank declined this card. You haven't been charged. Try another card or call your bank.

Was: Error 402

Show more

Our fault

Now: We couldn't save your invoice because of a problem on our side. Your draft is safe. Try again in a minute.

Was: Oops! Something went wrong!

In these invented examples, the last two answer the frightening question about lost money or work.

In the rewritten Quaymark, Bettina's ninth field turns out to be the due date, typed with dots. The new message sits under that field and names the format, the way the passport error names its rule. Her other eight answers are still filled in.

Only write "You haven't been charged" or "Your draft is safe" once you've confirmed with the developer that the system knows it's true.

Empty states

Before that first invoice, Bettina's account was empty, and it's easy to ship a screen that only says "No data." NN/g's empty-state guidance asks for the system's status, cues for learning the interface and direct pathways to key tasks.

Quaymark's first login

Status only

No invoices found.

Status, learning, pathway

No invoices yet. Once you send one, you'll see here whether it's been opened and paid. [Create your first invoice]

A filtered search needs a different message. 'No paid invoices in March. Clear filters' tells people their invoices still exist.

A load that failed can produce the same blank screen. Tell someone with forty sent invoices that they have "No invoices yet," and you've frightened them for nothing.

Check the available states before promising a recovery action.

What the empty screen needs from the system

Before writing, ask the developer whether the app can tell first use apart from a failed request. Does clearing a filter restore the results? Write a separate message for each state the system actually reports.

First use, filtered results and a failed request each need a message that explains the empty screen.

Confirmations and success messages

After someone finishes, they still want to know whether it went through and whether anything is left to do. GOV.UK's confirmation-page pattern includes a reference number where relevant, a note that a confirmation email has been sent and a section on what happens next.

Before: Thank you for your submission.

After: Invoice #1042 is on its way to Priya Holm. We've sent you a copy, and we'll email you when Priya opens it.

Promise that last email only if Quaymark can actually tell when an invoice is opened. If someone has one more step to take after signup, name it here and carry it into your welcome emails.

Dialogs and destructive actions

NN/g warns that confirmation dialogs for routine actions train people to click through and ignore the one that matters. Reserve the interruption for a consequence Bettina needs to consider before she acts.

When something can't be undone

Do

• Name what will be lost: 'Delete 14 invoices?'
• State the consequence: 'Clients will no longer be able to pay through these links.'
• Label buttons with the action: 'Delete 14 invoices' and 'Keep invoices'
• Offer undo when you can, instead of a dialog

Avoid

• Ask 'Are you sure?'
• Label the buttons 'Yes' and 'No' or 'OK' and 'Cancel' when the choice is unclear
• Interrupt for something routine and easily reversed
• Guilt people with 'No, I don't want to save money'

That last item is called confirmshaming. If Bettina declines an offer, let her return to her invoice without insulting her choice.

Where people hesitate, answer the objection where it comes up: "We ask for your card to prevent abuse. You won't be charged during your trial."

Check that explanation with whoever owns billing. The longer version of the idea is in handling objections on landing pages.

Set a few house rules

A flow needs consistent words. If Bettina creates an "invoice" on one screen and a "payment request" on the next, she'll assume they're two different things. Write down a dozen or so terms, including what you call the customer's stuff and how you sound when something fails.

Voice can flex with the moment. A success screen can carry some warmth, and a declined payment should be calm and direct, whatever your brand personality says.

Microcopy audit for one flow

• Every button says what will happen next
• Every field has a visible label, and no instruction lives only in a placeholder
• Every sensitive request explains why you're asking
• Every error says what went wrong and how to fix it, next to the problem
• Errors don't wipe what the person typed
• Empty states explain the status and offer a next step
• The final screen confirms it worked and says what happens next
• We call the same thing by the same name throughout

How do you find the worst lines?

Start where people get stuck and leave the rest for later. Ask support which questions keep coming in, and check your analytics for the step where people leave. Then trigger every error yourself with empty forms and wrong formats, and screenshot what you get.

Watch one person use the flow while you say nothing. When they hesitate, ask what they expected to happen. Note the hesitation and their explanation together so you can compare both with the wording on screen.

Walk a flow with the labels exposed

Pick one flow that matters, such as signup or checkout. The landing pages topic covers the pages around it. Paste screenshots of every button, error, empty state and confirmation into one document.

Mark each line against the three questions, then rewrite the five worst into a before-and-after spec for whoever builds the flow.

Back in the rewritten Quaymark, it's 11:40 again and Bettina types the due date with dots. The line under the field shows her the format, so she changes the separators and presses "Send invoice to Priya Holm." She goes to bed with invoice #1042 sent.