UX Encyclopedia

UX Writing & Microcopy

Words are interface. Every label, button, and empty state is a design decision, written alongside the layout, not poured in after. This file covers the writing craft; for error/feedback behavior (timing, placement, undo), see Feedback, Loading, Errors & Recovery.

Try it — which button loses your work? The same dialog with two sets of labels. Answer the question under each version; only one version lets you answer without guessing.
Dialog copy

Are you sure?

You have unsaved changes.

Which button loses your work?

Pick an answer above.

Principles

  • Clear > clever > cute (industry maxim — when clarity and personality conflict, clarity wins; per Mailchimp's guide, "it's more important to be clear than entertaining").
  • Google's trio — clear, concise, useful (Google I/O 2017, "How Words Can Make Your Product Stand Out," Stanphill et al.): clear = enough context to make sense; concise = economical, not merely short; useful = moves the user toward their goal. Canonical case: "Book a room" → "Check availability" raised engagement 17%.
  • Podmajersky's four qualities (Strategic Writing for UX, 2019): purposeful, concise, conversational, clear — edited in passes, one quality at a time; UX text serves user goals and business goals, and that alignment is the "strategic" part.
  • Front-load: put the differentiating word first ("Delete account," not "Would you like to delete your account?"). Users scan the first 1–2 words of links and list items (NN/g scanning research; the F-pattern makes trailing words invisible).
  • Plain language: short sentences, common words, active voice, verbs over nominalizations ("use" not "utilization"). PlainLanguage.gov is the reference; ~8th-grade reading level for general audiences is a widely used convention, not a law — simpler tests better even with expert users.
  • Scannability: users scan, not read. Fragments beat sentences in UI; one idea per element; meaningful headings; bullets over paragraphs.
  • Consistency beats elegance: one concept = one term everywhere (don't alternate "sign in" / "log in" / "login"). Maintain a terminology list (word list); every major style guide below has one.

Buttons, CTAs & labels

  • Verb + object, specific outcome: "Save changes," "Delete 3 photos," "Start free trial" — not "Submit," "OK," "Yes." A label should let the user predict exactly what happens without reading anything else.
  • Dialog buttons answer the dialog's question: "Delete draft?" → [Delete] [Keep] — never [OK] [Cancel] where "Cancel" is ambiguous (cancel the dialog or the thing?). Apple HIG is explicit on this.
  • Match the label to the moment's commitment level (the "Check availability" lesson): low-commitment verbs for browsing stages.
  • Links: the text alone says the destination ("View pricing," not "Click here") — also an accessibility requirement (below).

Errors, empty states & confirmations (writing craft)

  • Error anatomy (what/why/next, placement, tone) lives in Feedback, Loading, Errors & Recovery. The writing layer: name the problem in the user's vocabulary, not the system's ("That card was declined," not "Transaction error 4021"); lead the next sentence with the fix ("Check the number and try again"); never blame ("you entered an invalid…" → "that email needs an @").
  • Empty states are onboarding (see Onboarding, First-Run & Empty States): say what this space is for and the one action that fills it — "No invoices yet. Create your first invoice." Never bare "No data found."
  • Confirmation copy restates the consequence, not the mechanism: "This deletes 214 photos permanently" beats "Are you sure?". Success confirmations name what happened ("Changes saved"), briefly.
  • Placeholder text is not a label — it vanishes on focus and fails low-vision users; use real labels, reserving placeholders for format examples ("[email protected]") if used at all (NN/g, GOV.UK form guidance). Helper text: state must-know constraints before the mistake, not in an error after it.

Mechanics & platform conventions

  • Sentence case vs. Title Case: Material uses sentence case for nearly all UI text; Apple HIG uses title case for buttons, menu items, and titles (sentence case for longer text). Neither is "correct" — match the platform, codify one choice per product, and verify against live guidelines (this spec drifts).
  • Numerals: use digits, not spelled-out numbers, in UI ("3 files," not "three files") — digits stop the scanning eye (NN/g convention); editorial prose can follow print rules.
  • Time: relative time for recency ("2 min ago") decays badly — switch to absolute past a day or two, and expose the exact timestamp (tooltip or detail view) for anything a user might cite.
  • Truncation: truncate ends — except where the ending disambiguates (filenames, emails: truncate the middle); never cut the differentiating word; expose the full string on hover/focus. Best: write shorter.

Voice & tone

  • Voice is constant (the product's personality); tone varies by the user's moment. Mailchimp's voice-and-tone guide is the canonical public model (still published): the same voice sounds different in a success state vs. an account suspension.
  • Map tone to emotional state: high-stakes moments (errors, billing, security, deletion) get calm, plain, personality-free copy; playful copy only where the user is relaxed and succeeding — and it must survive the 500th viewing.
  • Style guides worth studying (all live as of mid-2026): Mailchimp Content Style Guide; Shopify Polaris content guidelines (voice/tone, grammar, alt text, error messages); Microsoft Writing Style Guide ("warm and relaxed, crisp and clear" — bigger ideas, fewer words); GOV.UK content design guidance + A-to-Z style guide (the plain-English benchmark); Google developer documentation style guide (word list).

Content design as a discipline

  • Content-first design: draft the words (the conversation) before high-fidelity layout — lorem ipsum hides broken flows (Podmajersky; GOV.UK's framing: start from user needs, not pages). Content audits: inventory existing copy, score against voice/terms/accuracy, kill duplicates. Terminology governance: a shared glossary with an owner; new terms require a decision, not a whim.
  • Localization-ready writing: no idioms, puns, or culture-bound metaphors; never build sentences by concatenating fragments (word order, gender, pluralization differ — use full parameterized strings with plural rules); leave room for expansion — English → many European languages runs ~30–35% longer (German is the classic case; W3C's "Text size in translation" notes short strings expand far more, so buttons and labels need the most slack).
  • Inclusive language: people-first or identity-first per community preference, no gendered defaults, no ableist idioms ("sanity check"); Microsoft's and Google's style guides carry bias-free word lists.

Accessibility overlap

  • Link text must make sense out of context — screen-reader users pull up link lists; "click here" ×12 is unusable (WCAG 2.4.4).
  • Alt text is writing: convey the image's purpose in context, not its pixels ("Revenue rose steadily to $2M by June," not "chart"); empty alt="" for decoration (W3C alt decision tree; Polaris's applied guide).
  • Headings are navigation: descriptive, front-loaded, hierarchical — screen-reader users jump by heading, so vague headings hide content.
  • Accessible names: visible label and programmatic label must match (WCAG 2.5.3 label-in-name, so voice-control users can say what they see); icon-only buttons need real names ("Search," not "magnifier").

Sources

↑↓ to navigate · Enter to open · Esc to close