What UX writing is and why words are interface
UX writing is the practice of crafting the text that appears within a product's interface — button labels, form field labels, error messages, tooltips, onboarding instructions, empty states, confirmation dialogs, loading messages, navigation labels, and notification copy. It's not marketing copy (which persuades people to use the product) or documentation (which explains how the product works after the fact). UX writing is the text that is the interface. In many interactions, words are the primary way the product communicates.
Every unclear label, every confusing error message, every vague tooltip is a micro-failure of design. When a button says "Submit" instead of "Place order," users hesitate. When an error says "Invalid input" instead of "Phone number needs 10 digits," users get stuck. When an empty state says "No items found" instead of "You haven't added any recipes yet — start by browsing popular collections," users don't know what to do next. These small text decisions compound into the overall feeling of a product — clear, helpful, and trustworthy, or confusing, cold, and frustrating.
Content design vs. UX writing
UX writing typically refers to crafting the specific text strings within an interface. Content design is broader — it includes deciding what content should exist, what format it should take (text? video? interactive?), and how content is structured across the product. A content designer might decide that an onboarding flow needs a progress indicator with short descriptions at each step; a UX writer crafts those specific descriptions. In practice, one person often does both.
Voice and tone frameworks
Voice & Tone Framework Core Method
Use when: establishing or documenting how your product communicates.
Voice is your product's personality — it stays consistent across all contexts. Is your product friendly or formal? Playful or serious? Expert or approachable? Voice is like a person's character: it doesn't change based on the situation. Tone adjusts to context while maintaining the same voice. A friendly product has a celebratory tone when a user completes a milestone, a reassuring tone when something goes wrong, and a straightforward tone during critical tasks like payment. Define 3–5 voice attributes (e.g., "Clear, confident, warm, and occasionally witty") and document how tone shifts across contexts (success, error, onboarding, routine use, sensitive moments).
The "this but not that" method
Define voice attributes as pairs: "Friendly but not casual. Confident but not arrogant. Helpful but not patronizing. Concise but not curt." This prevents misinterpretation. "Playful" alone could mean anything from dad jokes to irreverent sarcasm. "Playful but not silly — we use humor to reduce friction, not to perform" gives writers a clear boundary.
Microcopy patterns
Button Labels Core Method
Use when: writing text for any clickable action.
Button labels should describe what happens when clicked, from the user's perspective. Be specific: "Save changes" not "Submit." "Add to cart" not "Continue." "Send message" not "OK." Start with a verb: "Create project," "Download report," "Cancel subscription." Match the action to the consequence: If clicking deletes something permanently, "Delete forever" is clearer than "Remove." Avoid ambiguity in paired buttons: "Save / Discard" is clearer than "Yes / No" because users don't have to re-read the dialog to remember what "Yes" means. Never use "Click here" — it's both inaccessible (screen readers) and meaningless.
Form Labels and Help Text Core Method
Use when: designing form fields with labels, placeholders, and instructions.
Labels should be short and unambiguous: "Full name" not "Please enter your full name as it appears on your ID." Placeholder text is not a substitute for labels — it disappears when users start typing, removing the very instruction they need. Use placeholders for format examples only: "e.g., jane@company.com." Help text goes below the field: "Must be at least 8 characters with one number." Only add help text when the label isn't self-explanatory. Optional vs. required: Mark the minority — if most fields are required, mark optional ones "(optional)." If most are optional, mark required ones "(required)" or with an asterisk.
Tooltips and Contextual Help Technique
Use when: a brief explanation can prevent user confusion without cluttering the interface.
Tooltips should answer one question the user might have at that moment. Keep them under 150 characters — if you need more, use an expandable section or link to documentation. Write for the confused user, not the expert: "Messages older than 30 days will be permanently deleted" not "Retention policy: 30d TTL." Avoid tooltips on mobile (hover doesn't exist on touch) — use inline help text instead. Don't hide critical information in tooltips; if users need it to complete a task, it should be visible by default.
Error messages that help
Error Message Framework Core Method
Use when: writing error messages for any failure state.
Every error message should answer three questions: What happened? (The problem, in plain language.) Why did it happen? (The cause, if it helps the user understand.) What can the user do about it? (The fix, as a specific action.) Bad: "Error 403." Better: "You don't have access to this file." Best: "You don't have access to this file. Ask the file owner for permission, or try a different account." Tone matters too: avoid blaming the user ("You entered an invalid email") — reframe as the system's responsibility ("We didn't recognize that email format. Try name@company.com").
Error messages people actually see
The most critical error messages are often the least considered. 404 pages, payment failures, expired sessions, rate limits, and server errors are frequently left as developer defaults. These are exactly the moments when clear, helpful copy matters most — the user is already frustrated, and a cold technical message makes it worse. Audit every error state in your product and write specific, actionable copy for each one.
Empty states and zero-data screens
Empty State Design Core Method
Use when: a screen has no content to display — on first use, after deletion, or when search returns nothing.
An empty state is a teaching moment disguised as nothing. There are three types: First-use empty (the user hasn't created anything yet) — explain what this area is for and provide a clear CTA to get started. "This is where your projects live. Create your first project to get started." Cleared empty (the user deleted or completed everything) — congratulate or confirm. "All caught up! No pending reviews." No-results empty (a search or filter returned nothing) — suggest alternatives. "No results for 'wirefrme.' Did you mean 'wireframe'? Or try browsing all templates." Never show a blank page with no explanation. Empty states are prime real estate for onboarding, education, and encouraging the next action.
Onboarding copy
Progressive Onboarding Copy Technique
Use when: guiding new users through their first experience with your product.
Onboarding copy should be as short as possible and as long as necessary. Front-load the value proposition: tell users what they'll gain, not what they need to do. "Track your fitness progress in one place" is more motivating than "Step 1: Create a profile." Use progressive disclosure — don't dump all instructions at once. Teach features at the moment of first use, not in a pre-emptive tutorial. Keep instructional text scannable: one idea per screen, one action per step. Avoid jargon — new users don't know your product's vocabulary yet. "Boards" means nothing until users see one; call it "a board for organizing your tasks" the first time.
Content-first design process
Content-First Wireframing Technique
Use when: designing a new screen or flow and wanting to ensure copy and layout work together.
Instead of designing layouts with "Lorem ipsum" and filling in copy later, start with the content. Write the actual heading, body text, button labels, help text, and error messages before opening a design tool. Put the real content into the wireframe. This reveals problems early: the heading is too long for the header, the help text doesn't fit below the field, the button label creates an awkward layout at certain widths. Content-first design also prevents the common problem of final copy being squeezed into spaces designed for placeholder text that was conveniently short.
Stress-test with real content
Always test your designs with the longest reasonable content. A name field works with "Jane" — does it work with "Alexandra Konstantinidou-Papageorgiou"? An error message fits when it's "Invalid email" — does it fit when it's "This email is already associated with an account. Try signing in instead, or use a different email address"? Design for the longest case, celebrate the short one.
Writing for accessibility and localization
Accessible Content Checklist Technique
Use when: ensuring your copy works for all users, including those using assistive technology.
Link text: "Read the accessibility guidelines" not "Click here." Screen readers navigate by links — "click here" tells them nothing. Alt text: Describe the image's content and purpose, not its appearance: "Bar chart showing sales growth from $1M to $3M over 2023–2025" not "Image of a chart." Heading hierarchy: Use h1 → h2 → h3 in order; don't skip levels. Plain language: Write at an 8th-grade reading level when possible. Avoid idioms, metaphors, and culture-specific references that don't translate. Error identification: Errors must be described in text, not just color — "Required field" not just a red border.
Localization-Ready Copy Technique
Use when: your product will be translated or already serves multilingual users.
Translated text is often 30–50% longer than English. German and French expand significantly; Japanese and Chinese may contract. Design layouts with expansion room. Avoid embedding text in images — it can't be translated. Don't concatenate strings ("You have " + count + " messages") — word order changes across languages. Use complete sentences with variables: "You have {count} messages." Avoid puns, idioms, and cultural references that don't translate: "piece of cake" is meaningless in many languages. Date formats, number formats, currency symbols, and reading direction all vary — never hardcode these.
GenAI content design
AI-Generated Content Standards Framework
Use when: your product uses AI to generate user-facing text — summaries, suggestions, explanations, chat responses — and you need to ensure quality and consistency.
AI-generated content needs to follow the same writing principles as human-written interface copy, but it introduces new challenges. Apply web writing best practices: AI outputs should be scannable (front-load key information), concise (no padding or filler phrases), and action-oriented (tell users what to do, not just what happened). Prompt engineering should enforce these standards at generation time, not rely on post-processing. Voice consistency: AI outputs must match your product's established voice and tone. Without explicit guardrails, AI defaults to its own voice — often more formal, more verbose, and less distinctive than your brand voice. Build voice attributes (word lists, tone guidelines, banned phrases) into system prompts. Error transparency: When AI generates content, users need to know it's AI-generated, especially for factual claims, recommendations, or decisions. Design clear attribution labels and confidence signals. Content review workflows: Define which AI outputs ship without human review (low-stakes, templated) and which require editorial oversight (customer-facing, high-stakes, novel situations).
Content strategy vs. UX writing
UX writing is the craft of interface copy — microcopy, error messages, button labels, onboarding text. Content strategy is the organizational discipline of how content is structured, governed, and maintained. Both are essential; they're different skills. If you're solving content problems at the system level (governance, content models, editorial workflow, AI content pipelines), see CS.1.04 Content Design & Readability for the content strategy perspective. For integrating content patterns into design systems, see CS.2.07 Content & Design Systems.
Templates and checklists
- Button labels start with a verb and describe what happens when clicked
- Error messages explain what happened, why, and what to do next
- No placeholder text is used as a substitute for labels
- Empty states explain what the area is for and provide a next action
- Tooltips are under 150 characters and answer one specific question
- Loading messages set expectations about wait time when possible
- Confirmation dialogs state the consequence, not just "Are you sure?"
- Success messages confirm what happened and what comes next
- All link text is descriptive (no "click here" or "learn more" in isolation)
- Copy is tested at maximum reasonable length in all layouts
- Tone matches the emotional context (celebration, error, routine, sensitive)
[3–5 adjectives, e.g., "Clear, warm, confident, occasionally witty"]
[e.g., "Friendly but not casual. Confident but not arrogant."]
[e.g., "Celebratory but brief. Acknowledge the win, suggest next step."]
[e.g., "Calm and helpful. Never blame the user. Always offer a fix."]
[e.g., "Respectful, no humor. Account deletion, billing issues, personal data."]
Real-world examples
Case study
Stripe: developer-friendly error messages
Stripe's API error messages are a masterclass in helpful copy for a technical audience. Instead of generic HTTP status codes, every error includes: a human-readable message, the specific parameter that caused the issue, a machine-readable error code, and a link to documentation with examples. The dashboard extends this to non-technical users: payment failure emails explain what happened in plain language, suggest common fixes, and provide a direct link to retry. Even decline reasons are translated from bank codes into actionable guidance.
Why it works: Each error message reduces support tickets by answering the question before the user asks it. The tone is informative without being condescending, matching Stripe's voice of confident expertise.
Case study
Mailchimp: voice and tone at scale
Mailchimp's Content Style Guide (publicly available) is one of the most referenced voice and tone documents in the industry. It defines voice attributes ("fun but not childish, confident but not cocky"), provides tone guidance for specific situations (compliance alerts are serious and direct; campaign success is celebratory), and includes a searchable library of word choices ("log in" not "log on," "email" not "e-mail"). The guide covers everything from button labels to legal text, ensuring consistency across hundreds of screens.
Why it works: By documenting voice and tone in detail, Mailchimp maintains consistent copy across a large product team. New writers can produce on-brand copy without guessing.
Case study
Slack: empty states that teach
Slack's empty states do double duty as onboarding. A new channel shows "This is the very beginning of the #design channel" with suggestions to set a topic, add people, or start a conversation. The search empty state suggests search tips. The file browser empty state explains how files shared in messages appear there. Each empty state treats the blank space as an opportunity to educate rather than leaving users looking at nothing.
Why it works: Empty states turn "there's nothing here" into "here's what this will become." Users learn the product's capabilities at the moment they're most relevant.
Common pitfalls
Copy as an afterthought
Designing with Lorem ipsum and writing copy at the end leads to text that doesn't fit, labels that are too long, and error messages written by engineers in the codebase. Involve a writer from the wireframe stage. If you don't have a dedicated writer, the designer writes the copy — but it must be real copy from the start.
Trying too hard to be clever
Witty 404 pages are fine. Witty error messages during payment failures are not. Humor in microcopy should reduce friction, not create it. If the user has to decode a joke to understand what happened, you've prioritized personality over clarity. Cleverness is a seasoning, not the main course.
Inconsistent terminology
Calling it "Projects" in the sidebar, "Workspaces" in settings, and "Your stuff" in the empty state destroys user confidence. Create a product vocabulary — a single canonical term for each concept — and enforce it everywhere. A content glossary shared between design, engineering, and marketing prevents drift.