Microcopy: Principles, Patterns, and Systematic Practice

Microcopy is the small on-screen text — button labels, error messages, empty states, tooltips.

Microcopy: The Small Words That Decide Whether Users Convert, Trust You, and Come Back

Microcopy is every word in your product that isn't marketing copy or long-form content: the button that says 'Get started' vs. 'Sign up free,' the error that says 'Invalid input' vs. 'Please enter a phone number with area code,' the empty state that says 'No items' vs. 'Nothing here yet — try importing a CSV to see your data.' These strings, individually trivial, collectively define whether users feel supported, whether they trust you with their data, and whether they finish the flows you spent months building. Most teams under-invest in microcopy — it lives in scattered locale files, is written by whichever engineer implemented the feature, and is never systematically reviewed.

Principles that work across products

(1) Say what happens next. 'Save' is fine; 'Save and continue to review' is better when there's a next step. (2) Use the user's language, not internal jargon. 'Reconciliation' is your word; users say 'match transactions.' (3) Front-load the important word. 'Delete this project' beats 'Are you sure you want to delete this project?' — the verb is the point. (4) Prefer specific over general. 'That email isn't in our system' beats 'Login failed.' (5) Avoid negative framing where positive works. 'Available' beats 'Not occupied.' (6) Never blame the user. 'We couldn't process that card' beats 'You entered an invalid card.'

The patterns that come up over and over

Empty states: explain what will appear here, and give the next action. 'No customers yet. Import from CSV or add your first customer.' Errors: identify what went wrong, whose fault it is, what to do. Loading states: after 2s, tell the user what's happening ('Fetching your data — this can take up to a minute for large accounts'). Confirmations: describe the consequence and the recovery ('This will delete 47 records. You can restore from Settings > Trash for 30 days.'). Success: confirm and offer the next step ('Invoice sent to Ada. Send another or view sent invoices.'). Onboarding: one action per screen, never a bulleted list of steps.

Voice and tone: same voice, different tone by context

Voice is who you are — consistent across the product. Tone is how you speak given the moment. A cheerful product should still be quiet during a failed payment; a serious product can be playful in an empty state. Document voice as 3-5 adjectives with examples ('we are: direct, warm, precise; we are not: cutesy, jargony, hedging'). Document tone contextually: how errors sound, how confirmations sound, how celebrations sound. Publish this so any writer, engineer, or PM shipping copy can align without a review bottleneck.

Making it a system, not a scramble

Centralize strings in an i18n system (i18next, Format.js, Lingui) even for English-only products — it's the artifact where microcopy lives, is reviewed, and evolves. Assign an owner (usually a content designer, or a PM/designer with the appetite). Set up review cadence: quarterly audit of the highest-traffic strings (top 100 by impressions), lightweight review at feature launch. A/B test high-leverage strings (primary CTAs, empty state actions, checkout confirmations) — small copy changes routinely move conversion by 5-15%. Track wins in a shared doc so the lessons compound across teams.

Multilingual expansion

The moment you add a second language, microcopy quality visibly regresses in the second language unless you plan for it. Best practice: (a) provide translators with context — screenshots, character limits, tone guidance per string — not just a spreadsheet of source strings. (b) Reserve visual space for languages that expand (German averages 30% longer than English; French, Spanish 15-25%). (c) Never concatenate strings with placeholders that assume English grammar — 'You have {n} items' breaks in languages with gendered plurals; use full sentence variants. (d) Review translations with a native speaker who also knows the product; automated translation of microcopy produces subtly wrong results that erode trust.

Frequently asked questions

Do we need a content designer?
At 30+ engineers or 2+ product teams, a dedicated content designer typically pays back within a quarter through improved conversion and reduced support load. Below that, a designer or PM with strong writing chops carries the practice with 10-20% of their time.
How do we handle microcopy for AI-generated features?
Even more carefully. LLM-generated text has quality variance and can produce embarrassing or dangerous output. Wrap it with fixed microcopy that sets expectations ('This is a draft — review before sending'), enables correction, and clearly attributes to AI where relevant. The framing microcopy carries most of the trust.
Should error messages differ for different user roles?
Yes when it materially helps. An admin seeing a permission error can be told 'You need the Billing role to see this'; an end user seeing the same error just needs 'You don't have access — ask your admin.' Route the message by role, don't try to make one string serve both.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database