Copywriting That Converts · Email copy and microcopy · lesson 14 of 19 · 10 min
Microcopy and UX writing
Small words, big effects
Microcopy is the small text in interfaces: button labels, form hints, error messages, empty states, tooltips, confirmation messages, loading states. It often gets written last, by whoever is closest to the code. Yet it frequently determines whether a user completes a task or gives up.
Principles of good microcopy
- Clear before clever: users are trying to get something done.
- Specific: tell users exactly what to do or what happened.
- Concise: every word must earn its place.
- Helpful: anticipate the question and answer it at the right moment.
- Human: sound like a helpful person, not a system.
- Consistent: use the same term for the same thing everywhere.
Buttons and links
Buttons should describe the action and its result:
| Vague | Better | |---|---| | OK | Save changes | | Submit | Send my application | | Continue | Continue to payment | | Yes / No (in a dialog) | Delete project / Keep project |
In confirmation dialogs, label buttons with the actual action. "Are you sure? Yes / No" forces users to reread the question; "Delete this invoice? Delete / Cancel" is clearer.
Form hints and labels
- Put labels above fields, always visible.
- Use hints to prevent errors: "Include country code, e.g. +92 300 1234567".
- Explain why you need sensitive data: "We'll only use your phone number to confirm your delivery."
- Mark optional fields rather than required ones if most fields are required (or vice versa, consistently).
Error messages
A good error message says what went wrong and how to fix it, without blame:
Bad: "Invalid input."
Bad: "Error 422."
Bad: "You entered the wrong date."
Good: "Enter the date as DD/MM/YYYY, e.g. 05/03/2026."
Good: "That card was declined. Check the details or try another payment method."
Good: "This email is already registered. Log in or reset your password."
Security note: for login errors, avoid revealing which part was wrong if it helps attackers ("Email or password is incorrect" is standard practice).
Empty states and confirmations
Empty states (a dashboard with no data yet) are opportunities to guide:
"No invoices yet. Create your first invoice — it takes about two minutes." [Create invoice]
Confirmations should reassure and state what happens next:
"Payment received. Your receipt is on its way to your email, and your booking is confirmed for Saturday 10:00."
Microcopy that reduces anxiety
Near commitment points, small reassurances matter:
- "No card required"
- "Cancel any time from your account settings"
- "We never share your email"
- "You won't be charged until your trial ends on 14 March — we'll remind you 3 days before"
Each must be true. A reassurance that turns out to be false (for example, an unexpected charge) is worse than none.
Voice and localisation
Microcopy should reflect brand voice but lean towards clarity. When localising — for example into Arabic or Urdu — do not translate word-for-word. Work with native writers, check right-to-left layouts, ensure dates, currencies and number formats match local conventions, and allow for text expansion in buttons.
Accessibility
- Buttons and links must make sense out of context ("Download the pricing guide", not "Click here").
- Error messages should be announced to screen readers and associated with the right field.
- Avoid relying on colour alone ("fields in red are required").
- Provide descriptive alternative text for meaningful images.
Worked example: a clinic booking flow
Before:
Step title: "Details" Button: "Next" Error: "Invalid phone"
Confirmation: "Success!"
After:
Step title: "Your contact details"
Hint: "We'll text your appointment reminder to this number."
Button: "Continue to choose a time"
Error: "Enter a mobile number with country code, e.g. +966 5X XXX XXXX."
Confirmation: "You're booked with Dr. Amina at 4:30 pm on Tuesday. We'll text a reminder the day before.
Need to change it? Use the link in your confirmation email."
Microcopy audit checklist
- [ ] Buttons describe actions and outcomes
- [ ] Every error explains how to fix it, without blame
- [ ] Hints prevent common errors
- [ ] Reassurances near commitment points are true
- [ ] Terms consistent across the product
- [ ] Localised by native writers; accessible out of context
Hands-on: a microcopy audit sheet
Walk through a key flow (sign-up, checkout, booking) and capture every piece of interface text:
| Screen | Element | Current text | Problem (unclear / blaming / vague / missing) | Rewrite | Evidence (support tickets, recordings, errors) |
|---|---|---|---|---|---|
| Checkout | Error | "Invalid input" | vague, no fix | "Enter a UAE mobile number starting 05, e.g. 050 123 4567" | 38 tickets/month "phone not accepted" (illustrative) |
| Sign-up | Button | "Submit" | describes action, not value | "Create my free account" | - |
| Payment | Helper | (none) | missing reassurance | "You won't be charged until your order ships" | exit survey: card anxiety |
Prioritise rewrites on steps where analytics or session recordings show drop-off or repeated errors.
Before and after: error messages
| Before | After | Why it's better | |---|---|---| | "Error 422" | "That email is already registered. Log in or reset your password." | Explains and offers a way forward | | "Invalid password" | "Use at least 12 characters — a short phrase is easiest to remember." | Tells the rule before failure; friendly guidance | | "Payment failed" | "Your bank declined the payment. Try another card or pay with Apple Pay. You haven't been charged." | Cause, options, reassurance |
AI and UX writing
Product teams increasingly use AI assistants (and design-tool plugins in Figma and similar tools) to draft interface strings. Give the model your content style guide, character limits per component and the user's situation ("user has just entered a card and it was declined"). Review for accuracy — a model does not know your system's real error causes — and test with screen readers. For interfaces translated into Arabic or Urdu, have native speakers review for right-to-left layout, tone and length.
Microcopy and dark patterns
Microcopy is where manipulative design often lives: "confirmshaming" opt-outs ("No thanks, I prefer paying full price"), pre-ticked boxes, and cancellation flows that hide the button. Regulators including the FTC, the UK CMA and EU authorities treat many of these as unfair or deceptive practices. Write opt-outs neutrally ("No thanks") and make cancelling as easy as signing up.
Video lecture: Microcopy and UX writing
Lecture coming soon · 13 chapters · about 8 minutes. Read the full transcript below.
- Microcopy and UX writing
- Why microcopy matters
- Microcopy principles
- Buttons and forms
- Errors, empty states, confirmations
- Simple example: Riyadh clinic booking
- Realistic example: Dubai grocery app (illustrative)
- Watch me do it: microcopy audit
- AI for interface text
- Microcopy and dark patterns
- Accessibility and localisation
- Common mistakes
- Recap
Lecture transcript
Microcopy and UX writing
The smallest words on your website might be doing the most work. The button label. The line under a form field. The error message that appears when a card is declined. That's microcopy. And when it's wrong, people get stuck, anxious or annoyed, right at the moment they were about to act. In this lecture you'll learn the principles of good microcopy, how to write buttons, form hints, errors, empty states and confirmations, how to use AI for interface text safely, and where microcopy crosses into dark patterns. Then you'll watch me audit a checkout flow.
Why microcopy matters
Why does microcopy matter so much? Because it appears at decision points. A visitor can love your landing page and still abandon at the form, because a field label is unclear or an error message blames them. Microcopy is also cheap to fix and easy to measure. You can see where errors cluster, where people hesitate in recordings, and which questions support keeps answering. Every one of those is a microcopy opportunity.
Microcopy principles
Here are the principles. Be clear before clever. Be specific: tell people exactly what to do. Be helpful at the moment of need, which often means before an error, not after. Be human, never blaming: we couldn't find that address is better than invalid input. And be consistent: the same thing should have the same name everywhere. Think of microcopy as a calm, competent flight attendant. Short, clear instructions, delivered at the right moment, in a reassuring tone.
Buttons and forms
Buttons first. A button should say what happens when you press it, ideally with the value: create my free account, not submit. Download the checklist, not click here. For destructive actions, be explicit: delete project, not OK. Then form hints and labels. Labels must stay visible, not vanish as placeholders when people start typing. Put format hints before the field: UAE mobile number starting zero five. Explain why you need sensitive data: we'll only use your phone number for delivery updates.
Errors, empty states, confirmations
Now errors, empty states and confirmations. A good error message says what happened, why if it's useful, and how to fix it, in plain words. Your bank declined the payment. Try another card or pay with Apple Pay. You haven't been charged. That last sentence matters enormously, because the reader's first fear is being charged twice. Empty states, like an empty inbox or no search results, should guide the next action. Confirmations should say what happened and what happens next: order confirmed, we'll email tracking details within twenty-four hours.
Simple example: Riyadh clinic booking
A simple example. A clinic booking flow in Riyadh asks for a national ID number with no explanation, and the error message says invalid input. Patients call the clinic instead, or give up. The rewrite: a label that says national ID or Iqama number, a hint before the field showing the expected number of digits, and a line explaining it's needed to match your insurance. The error becomes: that number looks one digit short, please check the ten digits on your card. Same form, far less confusion.
Realistic example: Dubai grocery app (illustrative)
Now a realistic scenario, with illustrative details. An online grocery app in Dubai sees many support chats saying the app won't take my phone number. Session recordings show people typing plus nine seven one, or leaving a space, and getting a generic invalid phone error. The fix is part design, part words. The field now accepts common formats, and the hint says: UAE mobile, for example zero five zero, one two three, four five six seven. The error, if it still happens, says exactly what's expected. Support chats on that topic fall away over the following weeks. Microcopy didn't just reduce frustration. It saved support time.
Watch me do it: microcopy audit
Watch me audit a flow. I open the checkout on my phone and screenshot every screen. I make a table: screen, element, current text, problem, rewrite, and evidence. On the sign-up screen, the button says submit, so I rewrite it to create my free account. On the payment screen there's no reassurance at all, and exit surveys mention card anxiety, so I add: you won't be charged until your order ships, if that's true. The error message says error four two two, which I rewrite to: that email is already registered, log in or reset your password. Then I prioritise the rows where analytics or recordings show real drop-off. Evidence decides the order.
AI for interface text
AI is now common in UX writing. Designers generate interface strings with assistants and design-tool plugins. That's fine, with three rules. Give the model your style guide, the character limit for each component, and the user's situation, like the user's card was just declined. Check accuracy, because the model doesn't know your system's real error causes and may invent reassurances like you haven't been charged when that's not guaranteed. And for Arabic or Urdu interfaces, have native speakers review tone, length and right-to-left layout.
Microcopy and dark patterns
Now, dark patterns. Microcopy is where manipulation often hides. Confirmshaming, like no thanks, I prefer paying full price. Pre-ticked boxes for marketing or add-ons. Cancel flows that bury the button or make you click through five guilt-trip screens. Regulators including the US FTC, the UK CMA and EU authorities treat many of these as unfair or deceptive. The alternative is simple. Neutral opt-outs, like no thanks. Unticked boxes. And cancelling that's as easy as signing up. Honest microcopy builds the trust that brings customers back.
Accessibility and localisation
Two more things good microcopy always considers: accessibility and localisation. Accessibility first. Screen reader users hear your button labels without seeing the design around them, so read more, repeated five times, is useless. Read more about delivery times is clear. Error messages should be announced to assistive technology and placed next to the field they refer to, not only shown in red at the top. Now localisation. If your product serves Pakistan, the Gulf and the UK, a translation isn't enough. Arabic runs right to left and often needs different sentence structures. Urdu and Arabic strings can be longer or shorter than English, which breaks tight buttons. Formality levels differ too. So budget time for native speakers to review real screens, not just a spreadsheet of strings.
Common mistakes
Common mistakes. Generic labels like submit and OK. Placeholders used as labels, which disappear as people type. Error messages that blame or use codes. No reassurance near payment. Different names for the same thing across screens. Ignoring accessibility, like buttons that only make sense visually or error messages that screen readers can't reach. And writing interface text in isolation without looking at the actual screen, where length and context change everything.
Recap
Recap. Microcopy lives at decision points, so small words have big effects. Make buttons describe value, keep labels visible, put hints before errors, and write errors that explain and fix without blaming. Reassure at payment. Use AI for drafts, but verify accuracy and localisation. Keep it honest: no confirmshaming, no pre-ticked boxes, easy cancellation. Try this now: audit one flow you own using the six-column table in the lesson text, and fix the three rows with the strongest evidence of drop-off first.
Key takeaways
- Microcopy often decides whether users complete a task.
- Buttons should describe the action and result; confirmation dialogs should name the action.
- Error messages explain what went wrong and how to fix it, without blame.
- Reassurances must be true; localise and make microcopy accessible.
Try it
Audit the microcopy of one sign-up or checkout flow: rewrite three buttons, three error messages and one empty state or confirmation.