Writing & Expression: Design & UX CopyMicrocopy · Humane Errors · Voice & Tone · The Copy Checklist
BigCat's Writing
Designers and engineers have been writing all along — we just don't call it that: the words on a button, the empty-state hint, the error dialog, the placeholder in a form. This "microcopy" is tiny, yet it lands at the exact moment a user hesitates and decides whether to sail through or rage-quit. Four things today: how to write good microcopy, how to make errors humane, how to build a Voice & Tone system, and a copy checklist you can run line by line.
Principle 01
Microcopy: The Smallest Words, The Biggest Lever
The Craft of Microcopy
Yifrah · Microcopy · Conversion
The Principle in One Line
Microcopy is the unassuming little text in an interface — buttons, labels, placeholders, hints. It uses the fewest words, yet it appears at the very second a user is deciding, and becomes their entire guide.
"Good microcopy can completely change the user experience, and turn a website from one that's tense and unclear into one that's friendly, considerate and human."
— Kinneret Yifrah, Microcopy: The Complete Guide (2017)
Why It Works
People don't "read" interfaces; they scan. At every decision point — click this button or not, fill this field or not — those few words are all they have to go on. Generic words ("Submit," "OK") push the decision back onto the user: what happens if I click? Words specific to the action and its outcome remove that uncertainty. This is the cheapest, highest-leverage spot in experience design: change nothing in the layout, swap a few words, and conversion and trust both move. The craft isn't in vocabulary — it's in standing at the moment of hesitation and saying the next step plainly.
Before → After
SubmitCreate my account"Submit" is the developer's view — it names a system action. "Create my account" is the user's view — it says what clicking gets them. A button should answer "what happens when I click."
Empty state: "No data""No projects yet. Hit New in the top right to start your first one.""No data" is a dead end. A good empty state is an invitation — it tells the user what to do and where the door is.
When to Use + Common Mistakes
✓ Buttons, form labels, empty states, confirmation dialogs, onboarding hints — every point where a user must decide
✓ Self-check: does every button answer "what happens when I click"?
✗ Mistake: generic words like "Submit / OK / Cancel" that dump the judgment back on the user
✗ Mistake: using a placeholder as a label — it vanishes the moment they type, and they forget what the field was for
This Week's Exercise + Reflection
Find a "Submit" button in your product (or a daily app) and rewrite it as a verb phrase that says "what happens when I click." Then picture the user reading it. Reflection: who should own microcopy — the designer, the engineer, or a dedicated UX writer?
Principle 02
Humane Errors: Plain Words, the Problem, a Way Out
Humane Error Messages
Nielsen · Errors · Empathy
The Principle in One Line
A good error does only three things: in plain words, say what happened, why, and what to do now. Never dump an error code; never blame the user.
"Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution."
— Jakob Nielsen, 10 Usability Heuristics, #9 (1994)
Why It Works
By the time an error appears, the user is already frustrated. A cold "Operation failed" or a bare "Error 500" pours salt in the wound. An error is fundamentally a conversation: the user tried something and it didn't work, and the system should answer like a calm colleague — not an alarm. Watch for blame too: turn "you entered it wrong" into a neutral description, and move the subject off "you." A solid error has a clear three-part anatomy you can fill in.
What happened+Why+What to do
The error triad — missing "what to do" is deadliest; it strands the user at a dead end
Before → After
Error 500: Invalid input.We couldn't save your changes — the connection dropped. Try again; we've kept your draft.The first has only a code and an accusation. The second has all three parts, plus a reassurance (your draft is safe) that takes the panic down a notch.
Operation failed. Please try again.That email is already registered. Use a different one, or log in instead."Operation failed" leaves the user spinning. Name the cause (already registered) and give two ways out, and they know exactly where to go.
When to Use + Common Mistakes
✓ Form validation, network errors, empty results, permission denials — any "it didn't work" moment
✓ Logs for developers can carry codes; the user-facing UI keeps only plain words
✗ Mistake: throwing raw stack traces or error codes at ordinary users, multiplying their panic
✗ Mistake: saying only "something went wrong" with no next step, or opening with "you" and turning it into blame
This Week's Exercise + Reflection
Find the most common error in your product and rewrite it as "what happened + why + what to do." Reflection: which errors deserve detail (for developers to debug) and which deserve a spare, kind line (for ordinary users)? Could one error have two versions?
Principle 03
Voice & Tone: One Voice, Many Tones
Voice & Tone System
Mailchimp · Voice · Consistency
The Principle in One Line
Voice is the product's personality — steady throughout. Tone shifts with the situation. One voice, many tones — just as a person at a wedding and at a funeral is the same person, speaking differently.
"Your voice doesn't change much from day to day, but your tone changes all the time."
— Mailchimp, Content Style Guide (Voice & Tone)
Why It Works
One person dashing off a line or two goes on instinct, but a product has hundreds of copy touchpoints written by many hands — without a shared voice, the copy develops split personality: playful on this page, bureaucratic on that one. Voice is a fixed set of adjectives (say "friendly but not flippant, expert but not stuffy"), written into the style guide so everyone aligns. Tone reads the situation: a user who just paid can be greeted cheerfully; one who just hit an error needs restraint and care. The classic disaster is one "playful" tone smeared across every screen — joke while a user loses their data, and the most consistent voice becomes an insult.
One Voice
Friendly, clear, unpretentious — running through both success and failure
Success · cheerful tone
"Done! Your report is on its way 🎉"
Error · restrained tone
"Your report didn't send. We've saved the draft — try again shortly."
Before → After
Oops! Something went wrong, but no worries! 😄 (on a failed-payment page)Your payment didn't go through. Your card wasn't charged — check the number and try again.Tone-situation mismatch is a cardinal sin: the user's payment failed, and that 😄 reads like mockery. Restrain the tone, reassure first (no charge), and it's right.
An error page using the same marketing voice as the home page: "Let's begin an amazing journey together!""This page is gone. Head home, or try a search."The voice can stay consistent (both friendly), but a serious moment must switch to a restrained tone — not recycle the welcome line.
When to Use + Common Mistakes
✓ Building a copy style guide, multi-author collaboration, cross-team alignment — define voice first, then talk tone
✓ Before writing each line, ask: how does the user feel right now? What tone catches them?
✗ Mistake: conflating voice and tone — assuming "the brand is playful" means being cute everywhere
✗ Mistake: forcing playfulness into serious moments (errors, payment, privacy) — joking in a crisis
This Week's Exercise + Reflection
Write three voice adjectives for your product, then draft one line each for "success / waiting / error" and check whether the voice stays consistent and each tone fits. Reflection: do formal B2B or financial products need a "humanized" voice — or is restraint itself their voice?
Principle 04
The Copy Checklist: Can You Cut Half? Does It Sound Human?
The UX Copy Checklist
Krug · Checklist · Cutting
The Principle in One Line
Words on screen need to be even leaner than in an essay — users came to get something done, not to read you. Run a checklist before the final draft, and the first cut is always: can I delete half of this?
"Get rid of half the words on each page, then get rid of half of what's left."
— Steve Krug, Don't Make Me Think (2000)
Why It Works
Krug's "cut half, then cut half again" sounds extreme, but in practice it really does flush out mountains of pleasantries and instructional filler — welcome blurbs, over-explanation, polite padding. Every extra word is in the way. But cutting isn't the only yardstick; a useful checklist asks at least four things: ① Clear (does the user get it instantly?) ② Concise (can it be shorter?) ③ Conversational (does it sound human?) ④ Useful (do they know what to do after reading?). Between short-but-vague and long-but-clear, always pick clear — cutting is meant to sharpen the guidance, not to minimize the word count.
Before → After
Welcome to our platform! We're thrilled to have you. To help you get started, please follow the steps below to complete your initial setup…Three steps to start: ① Create a project ② Invite teammates ③ Import dataThe first is all "happy talk" the user can't use; the second hands over a roadmap, cuts eighty percent, and is friendlier for it.
Please be advised that in order to proceed you will need to complete all of the required fields below.Fill in the fields marked * to continue."Please be advised that in order to" is pure polite noise; cut to the bone, the instruction is actually clearer.
When to Use + Common Mistakes
✓ Any final-draft audit of interface copy; onboarding and empty states are filler hot zones
✓ Run the four questions before shipping: clear / concise / conversational / useful
✗ Mistake: warming up with "happy talk," stuffing a whole manual into the UI
✗ Mistake: sacrificing clarity for brevity — over-abbreviating or piling on jargon, leaving users more lost
This Week's Exercise + Reflection
Take an onboarding or empty-state passage from your product, cut it in half Krug-style, then run the four questions over what's left. Reflection: does "cut half" apply to character-based languages too, where each character carries more information? How would you adjust the yardstick?
— Going Deeper —
Who should really own microcopy — the designer, the engineer, or a dedicated UX writer?
Ideally a dedicated UX writer, but most teams don't have one. In reality it becomes "the placeholder text someone fills in last," written by whoever ships the screen — and the product's voice splinters. A more workable approach: treat microcopy as part of design, write real copy (not Lorem ipsum) at the mockup stage, and let one person or one style guide own the voice. Copy isn't the paint you add before launch; it's the skeleton of the experience.
Can AI mass-produce microcopy? What can you hand off, and what can't you?
It can draft; it struggles to set the tone. AI is great at generating piles of first-draft buttons and hints, sparing you the blank-page dread; but the judgment of "how does the user feel right now, what tone catches them" depends on understanding the product's voice and the specific moment, and still needs a human. A workable split: AI produces candidates, a human filters by the Voice & Tone guide, tunes tone, and sets boundaries — especially at high-stakes touchpoints like errors, payment, and privacy, where you shouldn't let AI make the call.
Errors should "offer a next step," but sometimes there's no fix (the server is down). How do you balance honesty and care?
When there's no fix, the "next step" is honesty plus the smallest viable action. Don't fake a solution ("please try again" when you know retrying won't help is deception); instead state the situation and give one thing they can actually do: "Something broke on our end and we're fixing it. Check back in a few minutes, or watch our status page." Care isn't whitewashing — it's not letting users batter a wall in vain, and not letting them think it's their fault. Honesty is itself a form of care.
Should a global product hold one voice across cultures?
The core of the voice (friendly, clear, trustworthy) should stay globally consistent, or the brand's personality fractures; but the register should localize. Playfulness and a casual "you" that feel natural in English can read as flippant in Japanese or formal business Chinese. So it's not copying the phrasing but carrying the same character expressed in locally appropriate ways — like the same person visiting different countries: temperament unchanged, manners adapted.
Are concise, concrete, and conversational the same set of principles in long-form and in microcopy?
The underlying spirit is shared; the constraints are utterly different. Long-form has room to build up, to pace itself, to ease the reader in; microcopy has no such luxury — it lands when the user is distracted, rushed, and just wants the task done, and it's tightly bound by space and context (a button is a few words). So microcopy pushes "concise" to the extreme, focuses "concrete" onto a single action, and even keeps "conversational" restrained — it isn't you talking, it's you saying the user's next step for them.