Every pixel on your screen tells a story, but it’s the words that guide users through it. A single word change can dramatically shift how people experience your product. Whether you’re building an app, designing a website, or crafting a digital service, the text users encounter shapes their entire journey.
This guide covers UX writing from foundational concepts to practical application: how users actually read on screens, which words to embrace or avoid, and how to craft copy that helps people accomplish their goals with confidence.
Table of Contents
- 1. UX Writing Basics: Definition, Examples, and Where It Fits
- 2. UX Voice and Tone: How to Sound Consistent Across the Product
- 3. How Users Read Online: Scanning Patterns and Cognitive Load
- 4. UX Writing Principles: Clear, Specific Microcopy That Users Trust
- 1) The 2 Golden Rules: Remove Filler and Replace Vague Words
- 2) Clarity Over Cleverness: When Brand Personality Helps (and When It Hurts)
- 3) Be Specific: Turn Features into User Benefits
- 4) Write for Context: What Happened, How Users Feel, and What They Do Next
- 5) Consistency Builds Trust: Terms, Labels, and Actions Users Learn Once
- 5. UX Writing Mistakes to Avoid: Filler, Buzzwords, Excessive Politeness, Unhelpful Error Messages, and Empty New Announcements
- 6. UX Microcopy Checklist: Buttons, Errors, Empty States, Forms, and Notifications
- 1) Button Text: Action Verbs, Outcomes, and Clear CTAs
- 2) Error Message: Tone by Severity and Recovery Steps
- 3) Empty State: Explain Why It’s Empty and What to Do Next
- 4) Onboarding and Tooltip: Progressive Disclosure and Quick Guidance
- 5) Notifications and Alerts: When to Interrupt and What to Say
- 6) Form Labels and Placeholders: Labels vs. Placeholders, Formats, and Inline Help
- 7) Confirmation and Success Messages: Clear Outcomes, Next Steps, and Reassurance
- 7. UX Writing Process: Research, Drafting, Reviews, and Team Handoff
- 8. UX Writing for Localization and Accessibility: Inclusive, Translation-Ready Copy
- 9. Conclusion: Words Are Part of the Product
1. UX Writing Basics: Definition, Examples, and Where It Fits
1) UX Writing Definition: Scope, Microcopy, and Interface Content
| Discipline | Primary Goal | Typical Context | Example |
|---|---|---|---|
| UX Writing | Guide users through tasks | Product interfaces | “Your password must include at least 8 characters” |
| Copywriting | Persuade and convert | Marketing materials, ads | “Join millions who’ve transformed their mornings” |
| Content Writing | Inform and educate | Blog posts, help articles | A 1,500-word guide on account security best practices |
UX writing refers to the craft of creating all text within a digital product. This includes button labels, error messages, onboarding flows, tooltips, notifications, menu items, confirmation dialogs, and every piece of text users encounter while interacting with an interface.
The primary goal is to guide users through a product experience clearly and efficiently. Unlike marketing copywriting (which aims to persuade) or content writing (which involves longer-form educational pieces), UX writing focuses on microcopy at critical decision points.
The emergence of dedicated UX Writer and Content Designer roles reflects growing recognition that product text deserves the same careful attention as visual design or interaction patterns. Many companies now treat words as a core component of user experience rather than an afterthought to fill in once designs are “finished.”
2) Why UX Writing Matters: Clarity, Trust, and Task Completion
The impact of UX writing extends far beyond aesthetics. Words directly influence whether users complete tasks, trust your product, and return for future interactions.
Even the most thoughtfully designed product can fail if poor text obscures its value. A beautifully crafted feature means nothing if users can’t understand what it does or why they should care.
What Effective UX Writing Achieves
| Outcome | How UX Writing Helps |
|---|---|
| Reduces friction | Clear instructions help users move through tasks without hesitation |
| Builds trust | Consistent, honest language makes products feel reliable |
| Communicates value | Specific wording helps users understand what they gain from features |
| Creates connection | Text that speaks to users’ actual situations makes them feel understood |
That last point deserves emphasis. Great UX writing makes users feel recognized and valued. Rather than generic messages that could apply to anyone, thoughtful copy acknowledges the user’s context and speaks directly to their needs.
3) Who Needs UX Writing Skills: PMs, Designers, Devs, and Support
UX writing isn’t solely the domain of specialized writers. In many organizations, product managers, designers, developers, and marketers all contribute to the text users see.
How Different Roles Engage with UX Writing
| Role | Typical Involvement |
|---|---|
| Product Managers | Define messaging strategy, ensure consistency with product vision, review copy for alignment with user needs |
| UX/Product Designers | Integrate copy into interface designs, ensure text fits spatial constraints, collaborate on microcopy decisions |
| Developers | Implement text strings, flag missing copy states, raise concerns about technical accuracy |
| Marketers | Align product messaging with brand voice, ensure consistency between marketing and in-product experiences |
| Customer Support | Provide insights on user confusion points, suggest improvements based on common questions |
In teams without dedicated UX writers, these responsibilities distribute across roles. A designer might draft initial button labels while a product manager refines error messages based on user feedback. The key is establishing clear ownership and review processes so copy doesn’t become an afterthought.
Even when a specialized UX writer joins the team, collaboration remains essential. Writers need input from designers about spatial constraints, from developers about technical possibilities, and from product managers about strategic priorities.
2. UX Voice and Tone: How to Sound Consistent Across the Product
1) Voice vs. Tone Definitions
Voice and tone are related but distinct concepts. Understanding the difference helps you maintain consistency while adapting to different situations.
(1) Voice: Your Brand’s Personality
Voice is the consistent character of your product’s communication. It doesn’t change based on situation. Think of it as your brand’s personality traits.
A brand voice might be: confident, friendly, and straightforward.
(2) Tone: Situational Adaptation
Tone is how you express your voice in different contexts. The same personality adjusts its emotional delivery based on the situation.
Think of a person you know well. They have a consistent personality (voice), but they speak differently at a funeral versus a birthday party (tone). They’re still the same person, but they adapt their emotional register to the moment.
| Voice (Constant) | Tone (Variable) |
|---|---|
| Friendly | Celebratory (success states) |
| Friendly | Sympathetic (error states) |
| Friendly | Calm (sensitive requests) |
| Friendly | Encouraging (onboarding) |
2) 4 Tone Dimensions in UX Writing: Humor, Formality, Respect, Enthusiasm
Nielsen Norman Group identifies four dimensions that define tone in UX writing. Each dimension exists on a spectrum, and your choices position your brand’s voice.
(1) Dimension 1: Humor
Spectrum: Funny ←→ Serious
| More Humorous | More Serious |
|---|---|
| Consumer apps, games | Healthcare, finance |
| Low-stakes interactions | High-stakes decisions |
| Success states | Error states involving data loss |
(2) Dimension 2: Formality
Spectrum: Formal ←→ Casual
| More Formal | More Casual |
|---|---|
| Enterprise software | Consumer apps |
| Legal or compliance contexts | Social features |
| Professional audiences | Younger demographics |
(3) Dimension 3: Respectfulness
Spectrum: Respectful/Deferential ←→ Direct/Assertive
| More Respectful | More Direct |
|---|---|
| Asking for personal information | Guiding routine actions |
| Delivering bad news | Confirming simple success |
| New user interactions | Power user features |
(4) Dimension 4: Enthusiasm
Spectrum: Enthusiastic ←→ Matter-of-fact
| More Enthusiastic | More Matter-of-fact |
|---|---|
| Achievement celebrations | Routine confirmations |
| Feature announcements | Settings and preferences |
| Onboarding | Error recovery |
3) Tone by Scenario: Success, Errors, Loading, Onboarding, and Sensitive Moments
Your voice stays constant, but tone should shift based on what users are experiencing.
(1) Tone by User Situation
| Situation | User Emotion | Appropriate Tone | Example |
|---|---|---|---|
| Success/achievement | Happy, satisfied | Celebratory, warm | “You did it! Your first project is live.” |
| Error/failure | Frustrated, worried | Calm, helpful | “That didn’t work. Here’s how to fix it.” |
| Waiting/loading | Impatient, uncertain | Reassuring, informative | “Saving your changes… This takes about 10 seconds.” |
| Sensitive request | Cautious, vulnerable | Respectful, trustworthy | “We ask for this to protect your account. Here’s how we use it.” |
| Learning something new | Curious, possibly confused | Encouraging, clear | “Great start! Next, try adding a team member.” |
(2) Tone Matrix Template
Map your tone choices across situations and emotions:
| Dimension | Happy | Neutral | Frustrated | Anxious |
|---|---|---|---|---|
| Success | Celebratory | Confirming | — | Reassuring |
| In Progress | Encouraging | Informative | Patient | Calming |
| Error | — | Helpful | Empathetic, solution-focused | Reassuring, clear |
| Request | Enthusiastic | Direct | Understanding | Trustworthy |
4) How to Create a Voice & Tone Style Guide for UX Writing
A documented Voice and Tone guide ensures consistency across teams and over time. Here’s how to structure one.
(1) Guide Components
| Section | What to Include |
|---|---|
| Brand personality | 3-5 adjectives that define your voice |
| Voice principles | Explanations of what each trait means in practice |
| Tone guidance | How voice adapts across different contexts |
| Examples | Do’s and don’ts for common scenarios |
| Word lists | Preferred terms vs. terms to avoid |
(2) Defining Brand Personality
Choose 3-5 adjectives that describe how your product communicates. For each adjective, explain what it means and doesn’t mean.
Example:
Confident
- We state things directly without hedging
- We don’t use “perhaps,” “maybe,” or “we think”
- This doesn’t mean arrogant; we still acknowledge limitations honestly
(3) Creating Do’s and Don’ts
For each voice principle, provide concrete examples:
| Principle | Do | Don’t |
|---|---|---|
| Friendly | “Need help? We’re here.” | “Contact support for assistance.” |
| Clear | “Save up to $50/month” | “Significant savings potential” |
| Confident | “Your data is encrypted” | “We try to keep your data secure” |
(4) Documenting Situational Tone
For key product moments, specify how tone should adjust:
| Scenario | Tone Guidance | Example |
|---|---|---|
| First-time user | Welcoming, encouraging, not overwhelming | “Welcome! Let’s set up your workspace. This takes about 2 minutes.” |
| Payment failure | Calm, non-blaming, solution-oriented | “Your payment didn’t go through. This usually means the card needs to be updated.” |
| Account deletion | Respectful, clear about consequences, no guilt-tripping | “Deleting your account removes all your data permanently. This can’t be undone.” |
3. How Users Read Online: Scanning Patterns and Cognitive Load
1) Reading Behavior on Screens: Why Users Scan Instead of Reading
People don’t read digital content the way they read books. Research consistently shows that online reading involves shorter attention spans, rapid scanning, and selective focus.
According to Nielsen Norman Group’s research, users typically read only about 20-28% of the text on a webpage. The longer the content appears, the harder it is to hold attention. On mobile screens, this challenge intensifies since a single line fits perhaps five words at most.
This creates a fundamental constraint for UX writing: every word must earn its place. Text that looks manageable on desktop can feel overwhelming on mobile, where the same paragraph stretches across multiple screens.
What This Means for UX Writers
- Assume users will scan, not read
- Front-load important information
- Keep sentences and paragraphs short
- Test how copy appears across device sizes
2) Common Scanning Patterns (F-Pattern, Layer-Cake, Spotted) and How to Write for Them
Eye-tracking studies have identified consistent patterns in how people scan digital content. Understanding these patterns helps you place critical information where users actually look.
| Pattern | User Behavior | Writing Strategy |
|---|---|---|
| F-Pattern | Read first lines, then scan left side | Put key terms at the start of lines |
| Layer-Cake | Read headings, skip body text | Make headings specific and descriptive |
| Spotted | Jump to links, bold text, numbers | Highlight critical information visually |
(1) The F-Pattern
Users often read in an F-shaped pattern:
- First, they scan horizontally across the top of the content
- Then they move down and scan a shorter horizontal line
- Finally, they scan vertically down the left side
This means users see the first few words of each line most reliably. Important information should appear at the beginning of headings and paragraphs, not buried at the end.
(2) The Layer-Cake Pattern
When content has clear headings, users often read only the headings and skip the body text entirely. They’re looking for the section that answers their specific question.
This pattern actually benefits users when headings are descriptive. It allows them to quickly locate relevant information without reading everything.
(3) The Spotted Pattern
Users often jump directly to visually distinct elements: links, bold text, numbers, and buttons. Their eyes skip over plain paragraph text and land on whatever stands out.
This pattern means strategic formatting can guide attention. But overusing bold text or links dilutes the effect. When everything is highlighted, nothing stands out.
3) Cognitive Load in UX Writing: Chunking, Working Memory, and Simpler Instructions
Every piece of text requires mental effort to process. When that effort exceeds users’ available attention, comprehension drops and frustration rises.
Miller’s Law and Information Chunking
| High Cognitive Load | Lower Cognitive Load |
|---|---|
| “Please enter your 16-digit card number, the 3-digit security code on the back, and the expiration date in MM/YY format” | Three separate fields with individual labels: “Card number,” “Security code (3 digits on back),” “Expiration (MM/YY)” |
| Long paragraphs explaining multiple features | Short paragraphs focused on one feature each |
| Technical jargon mixed with instructions | Plain language with technical terms explained |
Psychologist George Miller’s research suggests humans can hold roughly 7 (plus or minus 2) items in working memory at once. This principle applies directly to UX writing:
- Break complex information into smaller chunks
- Group related items together
- Present one concept at a time in sequential flows
The principle is straightforward: shorter, well-organized text reduces the mental effort required to understand and act.
4. UX Writing Principles: Clear, Specific Microcopy That Users Trust
1) The 2 Golden Rules: Remove Filler and Replace Vague Words
Effective UX writing follows two fundamental rules that apply across every context and component.
Rule 1: Eliminate Useless Words
Useless words occupy space without adding meaning or value. They make text longer without making it clearer. The goal is achieving maximum clarity with minimum text.
Consider this example:
| Before | After |
|---|---|
| “We are excited to announce that you can now customize your dashboard” | “Customize your dashboard” |
The first version includes filler (“we are excited to announce”) and unnecessary structure (“you can now”). The second version communicates the same information in three words.
Rule 2: Replace Vague Words with Specific Ones
Vague words create an illusion of communication without actually informing users. When you write “improved experience” or “better performance,” users don’t know what changed or how it benefits them.
| Vague | Specific |
|---|---|
| “Enhanced viewing experience” | “Dark mode reduces eye strain in low light” |
| “Faster performance” | “Pages load in under 2 seconds” |
| “Seamless integration” | “Connect your calendar in one click” |
Specificity builds trust. When you tell users exactly what they get, they can evaluate whether it matters to them.
2) Clarity Over Cleverness: When Brand Personality Helps (and When It Hurts)
It’s tempting to write clever, witty copy that showcases personality. But in UX writing, clarity always comes first.
Users arrive at your interface with a goal. They want to complete a task, find information, or solve a problem. Clever wordplay that requires interpretation slows them down.
The “Don’t Make Me Think” Principle, Steve Krug’s famous usability principle, applies directly to UX writing. Every moment users spend deciphering your text is a moment they’re not accomplishing their goal.
| Text Type | Purpose | Example |
|---|---|---|
| Supporting copy | Sets tone, builds personality, provides context | “Ready to take the plunge?” |
| Action text (CTAs, buttons) | Tells users exactly what will happen | “Create your account” |
Both serve important roles, but they shouldn’t be confused. Supporting copy can be playful and expressive. Action text must be immediately clear using the principle.
Where Personality Belongs
| Location | Can Be Playful? | Example |
|---|---|---|
| Headlines and subheadings | Yes | “Ready to take the plunge?” |
| Button labels | No, clarity first | “Create your account” |
| Onboarding welcome screens | Yes | “Let’s get you set up” |
| Error message solutions | No, be direct | “Check your card details and try again” |
| Empty state descriptions | Yes | “It’s quiet here… for now” |
| Form field labels | No, be clear | “Email address” |
The best UX writing uses personality in supporting copy while keeping action text crystal clear.
This way, users enjoy the brand personality without confusion about what action they’re taking.
3) Be Specific: Turn Features into User Benefits
Vague writing often results from focusing on features rather than benefits. Product teams know what they built, so they describe the feature. But users care about what they gain.
After writing any copy, ask yourself: “So what? What changes for the user?”
If you can’t answer specifically, your copy is too vague.
| Fails the Test | Passes the Test |
|---|---|
| “New and improved search” | “Find files by content, not just file name” |
| “Redesigned settings page” | “Adjust notification preferences in half the steps” |
| “Better collaboration features” | “Comment directly on any image or document” |
Specificity requires understanding your users’ actual problems. “Better collaboration” means nothing until you identify which collaboration pain point you’ve solved.
4) Write for Context: What Happened, How Users Feel, and What They Do Next
The same word can be perfect in one situation and confusing in another. Effective UX writing considers not just what you’re saying, but when and where users encounter it.
Before writing any piece of copy, consider:
- What just happened? Did the user succeed, fail, or take a specific action?
- How might they feel? Frustrated, confused, excited, anxious?
- What do they need to know? Only essential information for this moment
- What should they do next? The logical next step from here
Consider a “Delete” button. The appropriate copy changes based on context:
| Context | Better Copy | Why |
|---|---|---|
| Deleting a draft email | “Delete draft” | Low stakes, simple confirmation |
| Deleting an account | “Delete my account permanently” | High stakes, needs explicit clarity |
| Deleting a shared file | “Delete for everyone” | Others affected, needs scope clarity |
The action is the same, but what users need to understand differs significantly.
5) Consistency Builds Trust: Terms, Labels, and Actions Users Learn Once
When the same action uses different words in different places, users lose confidence. They wonder if “Cancel,” “Cancel subscription,” and “End membership” do the same thing or something different.
Why Consistency Matters
- Reduces cognitive load (users learn your patterns once)
- Builds familiarity and confidence
- Prevents confusion about functionality
- Creates a sense of product quality and reliability
Example
| Inconsistent | Consistent |
|---|---|
| “Save” / “Save changes” / “Update” for the same action | “Save” everywhere |
| “Sign in” / “Log in” / “Login” | Pick one and use it throughout |
| “Delete” / “Remove” / “Trash” | Define when each term applies |
5. UX Writing Mistakes to Avoid: Filler, Buzzwords, Excessive Politeness, Unhelpful Error Messages, and Empty New Announcements
| Category | Generic Copy Pattern to Avoid | Core Problem |
|---|---|---|
| Useless Filler Words | Announcements led by emotion or padding words instead of information | Adds length without adding meaning |
| Vague Buzzwords | Abstract, impressive-sounding language that avoids specifics | Obscures what actually changed |
| Excessive Politeness | Overly polite or apologetic UI instructions | Weakens clarity and confidence |
| Unhelpful Error Messages | Errors that state failure without cause or guidance | Leaves users unable to recover |
| Empty “New” Announcements | Announcing change without explaining value or impact | Creates confusion and resistance |
1) Useless Filler Words
Some words appear constantly in product copy despite adding no value. Removing them makes text cleaner without losing meaning.
(1) “We’re thrilled / excited / delighted”
Users don’t care how you feel about your announcement. They care what changed and how it affects them.
| Before | After |
|---|---|
| “We’re thrilled to announce our new dashboard!” | “New dashboard: see all your metrics in one view” |
(2) Words to Delete When Found
The following words can often be removed with no change in meaning:
- Actually
- Really
- Very
- Just
- Simply
- Easily
- Basically
- In order to (replace with “to”)
Try removing these words from your copy. If the meaning stays the same, leave them out.
2) Vague Buzzwords
Buzzwords sound impressive while communicating nothing specific. They’re especially common in feature announcements and marketing-influenced product copy.
(1) The Worst Offender: “Experience”
“Experience” tops the list of vague words because it obscures what actually changes for users. “Improved experience” could mean anything from faster load times to a completely redesigned interface.
| Vague | Specific |
|---|---|
| “Enhanced reading experience” | “Adjustable font size and dark mode” |
| “Smoother checkout experience” | “Check out in 3 steps instead of 7” |
| “Better mobile experience” | “Full functionality now available on mobile” |
(2) Other Buzzwords to Replace
| Buzzword | The Problem | Better Approach |
|---|---|---|
| Seamless | What friction was removed? | Describe the specific improvement |
| Intuitive | Users decide what’s intuitive | Show, don’t tell |
| Robust | What capabilities does it have? | List specific features |
| Leverage | Corporate jargon | Use “use” instead |
| Cutting-edge | Meaningless superlative | Describe what makes it advanced |
| Streamlined | What became simpler? | Explain the simplification |
3) Excessive Politeness
Adding “please” and polite phrases everywhere might seem courteous, but it often weakens your copy and clutters the interface.
(1) The Problem with Over-Politeness
Excessive politeness creates several issues:
- Makes instructions longer without adding clarity
- Can make your product sound uncertain or apologetic
- Turns confident guidance into hesitant requests
- Adds friction to every interaction
| Over-Polite | Direct and Clear |
|---|---|
| “Please click the button below to continue” | “Continue” |
| “Would you mind entering your email address?” | “Email address” |
| “Please wait while we process your request” | “Processing…” |
Users don’t perceive directness as rude. They perceive it as efficient. Clear instructions feel helpful, not impolite.
(2) When Politeness Actually Helps
There are situations where softer language is appropriate:
- Requesting sensitive information: “We need your phone number to verify your identity” feels better than a bare field
- After errors caused by your system: “Sorry, something went wrong on our end” acknowledges responsibility
- Asking users to do extra work: “Could you help us improve? Take a 2-minute survey” respects their time
The key distinction: use polite language when you’re asking something of users, not when you’re helping them accomplish their goals.
4) Unhelpful Error Messages
Few things frustrate users more than error messages that don’t explain what went wrong or how to fix it.
What Makes Error Messages Fail
| Bad Error | Why It Fails |
|---|---|
| “Error” | No information at all |
| “Something went wrong” | No cause, no solution |
| “Invalid input” | Doesn’t specify which input or why |
| “Authentication failed. Please try again.” | Doesn’t explain why it failed |
| “Error code: 5023” | Technical jargon meaningless to users |
These messages leave users guessing. They don’t know what they did wrong, so they can’t fix it.
(2) The Error Message Formula
Effective error messages follow a simple structure:
[What went wrong] + [Why it went wrong] + [How to fix it]Code language: CSS (css)Examples Using the Formula
| Component | Example 1 | Example 2 |
|---|---|---|
| What | “Couldn’t send message” | “Payment declined” |
| Why | “File size exceeds 25MB limit” | “Card expired” |
| How to fix | “Try compressing the image or sending a smaller file” | “Update your card in Settings > Payment methods” |
| Full message | “Couldn’t send message. File size exceeds 25MB limit. Try compressing the image or sending a smaller file.” | “Payment declined because your card has expired. Update your card in Settings > Payment methods.” |
Before shipping any error message, verify:
- Does it avoid blaming the user? (“Invalid email” → “Enter an email address like [email protected]“)
- Is it free of technical jargon? (No error codes, no developer terminology)
- Does it include a clear next step?
- Is the tone appropriate to the severity?
5) Empty “New” Announcements
When products launch redesigns or new features, teams often announce them with vague excitement rather than clear value.
In update announcements, “now” is redundant. You’re telling them now because it’s available now. The same applies to “new” in product contexts where newness is already obvious.
Messages like “Check out our new homepage!” or “Explore our redesigned app!” tell users something changed but not:
- What specifically changed
- Why it changed
- How it benefits them
- What they should do differently
This creates confusion. Users land on unfamiliar interfaces without understanding the intention behind the changes. The common response: “I liked it better before.”
Bad vs. Good Redesign Announcements
| Unhelpful | Helpful |
|---|---|
| “Welcome to the new dashboard!” | “Your dashboard now shows weekly trends. Find your most important metrics at the top.” |
| “We’ve redesigned Settings” | “Settings now has three sections: Account, Privacy, and Notifications. Find what you need faster.” |
| “Experience our fresh new look” | “New navigation puts your most-used features one tap away” |
When announcing changes, structure your message as:
- What changed: Specific feature or area
- User benefit: What improves for them
- Next action: What to do or where to look
Example: “New search filters let you find files by date and type. Try the filter icon next to the search bar.”
6) UX Writing Examples: Bad vs. Good vs. Best (Feature Announcement Case Study)
To illustrate these principles, let’s examine how the same feature announcement can range from poor to excellent.
Scenario: A note-taking app adds voice memo functionality
Version 1: Worst
“We’re incredibly excited to share a groundbreaking new addition to your note-taking journey! After months of hard work, our dedicated team is proud to introduce an innovative, state-of-the-art voice recording capability that will transform how you capture your thoughts. Experience the seamless, next-generation way to create notes with our enhanced audio integration!”
Problems: Filler phrases (“incredibly excited,” “proud to introduce”), buzzwords (“groundbreaking,” “state-of-the-art,” “seamless,” “next-generation”), buries the actual feature, no user benefit.
Version 2: Still Poor
“New: Voice memos are here! This enhanced feature lets you record audio for a better note-taking experience.”
Problems: “Enhanced feature” and “better experience” add nothing. Doesn’t explain when to use it or how it helps.
Version 3: Acceptable
“Voice memos now available. Record audio directly in any note.”
Better: Direct and clear. Users understand what the feature does.
Version 4: Good
“Capture ideas without typing. Tap the microphone icon to record voice memos in any note.”
Better still: Leads with the user benefit, includes how to access the feature.
Version 5: Best
“Capture ideas without typing. Tap the mic icon in any note to start recording. Your memos sync across all devices automatically.”
Best: Clear benefit, simple instructions, addresses a likely follow-up question (will it sync?).
What Improves Across Versions
| Version | Word Count | Clarity | User Benefit | Actionable |
|---|---|---|---|---|
| 1 | 62 | Low | None | No |
| 2 | 19 | Medium | Vague | No |
| 3 | 10 | High | Implied | Partially |
| 4 | 16 | High | Clear | Yes |
| 5 | 22 | High | Clear | Yes |
Notice that Version 5 isn’t the shortest. Good UX writing isn’t about minimum word count. It’s about including exactly what users need to understand and act.
6. UX Microcopy Checklist: Buttons, Errors, Empty States, Forms, and Notifications
1) Button Text: Action Verbs, Outcomes, and Clear CTAs
Buttons are among the highest-impact text in your product. They appear at decision points and directly influence whether users take action.
(1) Core Principles for Button Text
| Principle | Explanation | Example |
|---|---|---|
| Start with a verb | Buttons trigger actions | “Create,” “Send,” “Download” |
| Specify the outcome | Tell users what happens | “Create account” not “Submit” |
| Keep it short | 1-4 words ideal | “Save changes” not “Click here to save your changes” |
| Match user intent | Reflect what users want to accomplish | “Find flights” not “Search” |
(2) Common Button Problems and Fixes
| Generic | Specific |
|---|---|
| Submit | Create account / Send message / Place order |
| Click here | View pricing / Read more about security |
| Yes / No | Delete file / Keep file |
| OK | Got it / Continue |
(3) Button Text Decision Guide
Ask yourself:
- What will happen when the user clicks this?
- What does the user want to accomplish?
- Can I describe the outcome in 1-4 words?
2) Error Message: Tone by Severity and Recovery Steps
We covered error message problems in the previous section. Here’s a practical framework for writing them well.
(1) Tone Considerations by Severity
| Error Type | Tone | Example |
|---|---|---|
| Minor / easily fixed | Neutral, instructive | “Enter a valid phone number (e.g., 555-123-4567)” |
| User action failed | Helpful, solution-focused | “Message not sent. Check your connection and try again.” |
| System error | Apologetic, reassuring | “Something went wrong on our end. Your data is safe. Please try again in a few minutes.” |
| Serious / data at risk | Calm, clear, urgent | “Your session expired. Sign in again to avoid losing unsaved changes.” |
(2) Words to Avoid in Error Messages
- “Invalid” (feels judgmental)
- “Illegal” (alarming)
- “Failed” alone (needs context)
- “Oops” (can feel dismissive for serious errors)
- Technical terms (error codes, exceptions)
3) Empty State: Explain Why It’s Empty and What to Do Next
Empty states occur when a screen has no content to display. These moments are opportunities to guide users rather than simply stating “No data.”
(1) Empty State Components
A complete empty state includes:
- Current status: What the user is looking at
- Why it’s empty: Context for the lack of content
- How to fill it: Action the user can take
- CTA button: Direct path to that action
(2) Empty State Examples
| Screen | Poor Empty State | Better Empty State |
|---|---|---|
| Inbox | “No messages” | “No messages yet. Conversations with your team will appear here. Start a conversation →” |
| Search results | “No results found” | “No results for ‘prodct.’ Did you mean ‘product’? Or try browsing categories →” |
| Favorites | “Nothing here” | “Items you favorite will appear here for quick access. Browse items →” |
| Activity feed | “No activity” | “When teammates comment on your work, you’ll see it here.” |
4) Onboarding and Tooltip: Progressive Disclosure and Quick Guidance
First-time users need guidance, but too much information overwhelms them. The key is progressive disclosure: reveal information as users need it.
(1) Onboarding Principles
| Principle | Application |
|---|---|
| One concept at a time | Each screen or tooltip covers one thing |
| Show, don’t tell | Point to UI elements rather than describing them abstractly |
| Let users escape | Always offer “Skip” or “Do this later” |
| Focus on value | Explain what users can accomplish, not how features work |
(2) Tooltip Best Practices
Tooltips work best when they:
- Appear at the moment of need (not preemptively)
- Explain one element or action
- Stay brief (1-2 sentences max)
- Disappear easily without blocking interaction
| Too Long | Right Length |
|---|---|
| “This button allows you to export your data in various formats including CSV, Excel, and PDF. You can choose which columns to include and set filters before exporting.” | “Export your data as CSV, Excel, or PDF” |
5) Notifications and Alerts: When to Interrupt and What to Say
Notifications interrupt users, so they must earn that interruption with clear value.
(1) Notification Types and Tones
| Type | Purpose | Tone | Example |
|---|---|---|---|
| Success | Confirm completed action | Positive, brief | “Message sent” |
| Info | Provide useful update | Neutral, clear | “New comment on your post” |
| Warning | Prevent potential problem | Calm, helpful | “Your subscription renews in 3 days” |
| Error | Alert to problem | Urgent but constructive | “Payment failed. Update card →” |
(2) Writing Notification Copy
For each notification, answer:
- Why now? What triggered this notification?
- What should they do? Clear action if one is needed
- How urgent is it? Does this need immediate attention?
- Can they ignore it? Is this informational or action-required?
6) Form Labels and Placeholders: Labels vs. Placeholders, Formats, and Inline Help
Forms are where users input data, and poor labels create friction and errors.
(1) Labels vs. Placeholders
| Element | Purpose | Visibility | Example |
|---|---|---|---|
| Label | Identify what to enter | Always visible | “Email address” |
| Placeholder | Show format or example | Disappears on input | “[email protected]“ |
Critical Rule: Never use placeholder text as the only label. Once users start typing, the placeholder disappears, and they can’t remember what the field wanted.
(2) Form Writing Checklist
- Every field has a visible label (not just placeholder)
- Required vs. optional is clear
- Format expectations are shown (e.g., “MM/DD/YYYY”)
- Character limits are visible before users exceed them
- Error messages appear next to the relevant field
7) Confirmation and Success Messages: Clear Outcomes, Next Steps, and Reassurance
After users complete an action, confirmation messages close the loop. Vague confirmations leave users uncertain.
(1) Beyond “Done” and “Success”
| Generic | Specific |
|---|---|
| “Success!” | “Order placed. Confirmation sent to your email.” |
| “Done” | “Changes saved. Your new settings are active.” |
| “Complete” | “Account created. Start by setting up your profile →” |
(2) Confirmation Message Structure
- What completed: Name the specific action
- Result or impact: What happens now
- Next step (optional): Related action they might want
Example: “Payment received. Your Pro plan is now active. Explore Pro features →”
7. UX Writing Process: Research, Drafting, Reviews, and Team Handoff
1) Before You Write: User Intent, Context, and Copy Requirements
Good UX writing starts before you type a single word. Understanding who you’re writing for and what they need makes the actual writing faster and more effective.
(1) Define Your Target User
Every piece of copy has an audience. Before writing, clarify:
- Who will see this text?
- What’s their familiarity with the product?
- What vocabulary do they use?
- What’s their technical comfort level?
Copy for first-time users differs from copy for power users. Copy for developers differs from copy for marketers. Knowing your audience shapes every word choice.
(2) Understand the Context
The same user might need different copy depending on their situation. Consider:
| Context Factor | Questions to Answer |
|---|---|
| Emotional state | Are they stressed? Excited? Confused? Impatient? |
| Previous action | What did they just do to arrive here? |
| Next expected action | What should they do after reading this? |
| Environment | Mobile or desktop? Public or private? Time-pressured? |
(3) Pre-Writing Checklist
Before drafting any copy, answer these questions:
- Who is the user for this screen/message?
- What situation are they in?
- How might they be feeling?
- What’s the goal of this text?
- What action should they take next?
- What’s the minimum they need to know?
2) During Writing: The 3-Draft Method, Cutting, and Versioning
The first draft is rarely the final draft. Effective UX writers use a deliberate process to refine their copy.
(1) The Three-Draft Method
| Draft | Goal | What to Do |
|---|---|---|
| First | Get everything down | Write all the information you might need to convey. Don’t worry about length. |
| Second | Cut ruthlessly | Remove everything that isn’t essential. Aim to cut 30-50%. |
| Third | Polish and tighten | Simplify word choices, improve flow, check for consistency. |
(2) Example: Three-Draft Process
Scenario: Empty state for a team chat feature
First Draft (All Information)
“Welcome to Team Chat! This is where you and your team members can have conversations about projects, share updates, and stay connected. To get started with Team Chat, you can either create a new channel for a specific topic or project, or you can send a direct message to a specific team member. Channels are great for group discussions where everyone can participate, while direct messages are better for one-on-one conversations. You can also add files, images, and links to your messages.”
Second Draft (Essential Only)
“Team Chat is where your team communicates. Create channels for group discussions or send direct messages for one-on-one conversations. You can share files and links in any message.”
Third Draft (Polished)
“Your team conversations live here. Start a channel for group discussions, or message someone directly. Create your first channel →”
(3) Read Aloud
Reading copy aloud reveals problems that silent reading misses:
- Awkward phrasing becomes obvious
- Overly long sentences make you run out of breath
- Unnatural word choices stand out
- Missing rhythm or flow becomes apparent
If it sounds strange when spoken, it will feel strange when read.
(4) Write Multiple Versions
For important copy, write 3-5 versions before choosing. This prevents settling for the first adequate option when a better one exists.
| Version | Approach |
|---|---|
| Version A | Shortest possible |
| Version B | Focus on benefit |
| Version C | Focus on action |
| Version D | More conversational |
| Version E | More direct |
Comparing versions often reveals the best elements of each, which you can combine.
3) After Writing: Checklist, Peer Review, and In-UI Testing
Writing is only part of the process. Review and testing ensure your copy works in the real world.
(1) Self-Review Questions
Before sharing your copy with others, check it against these questions:
| Question | If No, Then… |
|---|---|
| Is this understood on first read? | Simplify language and structure |
| Can I cut any words without losing meaning? | Remove the unnecessary words |
| Are there any vague words? | Replace with specific alternatives |
| Is the next action clear? | Add or clarify the CTA |
| Does this match our voice and tone? | Adjust to align with guidelines |
| Would this work on a small screen? | Shorten or restructure |
(2) Peer Review
Fresh eyes catch problems you’ve become blind to. When asking colleagues to review:
- Share the context (who’s the user, what’s the situation)
- Ask specific questions (“Is the next step clear?” rather than “What do you think?”)
- Don’t explain your copy verbally; it should work without explanation
(3) Testing in Context
Copy that works in a document may fail in the actual product. Always test copy:
- In the real UI or a realistic prototype
- On mobile as well as desktop
- In sequence (not just the single screen)
- With actual target users when possible
4) Collaborating on UX Copy: Designers, Developers, States, and Specs
UX writing doesn’t happen in isolation. Effective collaboration with designers and developers improves both the copy and the overall experience.
Common Design-Copy Tensions
| Issue | Solution |
|---|---|
| Text doesn’t fit the space | Negotiate: can design accommodate, or must copy shorten? |
| Placeholder text went to production | Use realistic copy from the start, not Lorem Ipsum |
| Copy added last minute | Advocate for earlier involvement in process |
(1) Working with Designers
| Stage | Collaboration Point |
|---|---|
| Early exploration | Discuss content needs before layouts are fixed |
| Wireframes | Draft copy for wireframes, even if rough |
| Visual design | Refine copy as visual constraints become clear |
| Final review | Ensure text fits and reads well in final designs |
(2) Working with Developers
Developers need complete copy specifications to implement correctly. This includes:
- All states (default, hover, active, disabled)
- Error messages for each failure case
- Empty states
- Loading states
- Success confirmations
- Character limits if applicable
Before handing off to development, verify all text is defined:
| Component | States to Cover |
|---|---|
| Buttons | Default, hover, loading, disabled |
| Forms | Labels, placeholders, helper text, error messages, success messages |
| Lists | Populated state, empty state, loading state |
| Modals | Title, body, all buttons, any error states |
| Notifications | All variations and related actions |
(3) Internationalization Considerations
If your product will be translated:
- Avoid idioms and culturally specific references
- Leave room for text expansion (German averages 30% longer than English)
- Don’t embed text in images
- Avoid concatenating strings (“You have ” + count + ” messages”)
8. UX Writing for Localization and Accessibility: Inclusive, Translation-Ready Copy
1) Translation-Friendly UX Writing: Clear Grammar, Fewer Idioms, and Locale Formats
Copy that will be translated needs special consideration during the original writing process. What works in English may confuse translators or produce awkward results in other languages.
(1) Principles for Translation-Friendly Writing
| Principle | Why It Matters | Example |
|---|---|---|
| Use short sentences | Easier to translate accurately | One idea per sentence |
| Include clear subjects | Some languages require explicit subjects | “Save your file” not “Save it” |
| Avoid idioms | Idioms don’t translate literally | “Get started” not “Hit the ground running” |
| Be careful with humor | Humor often doesn’t cross cultures | Keep it straightforward for UI copy |
| Watch date/number formats | Formats vary by region | Use localization libraries, not hardcoded formats |
(2) Words That Cause Translation Problems
| English Issue | Problem | Solution |
|---|---|---|
| “You” (ambiguous) | Some languages have formal/informal “you” | Define which to use per locale |
| Contractions | Don’t exist in some languages | “Do not” may be clearer than “Don’t” |
| Noun strings | Hard to parse in other languages | “User account settings” → “Settings for your account” |
| Phrasal verbs | Don’t translate well | “Set up” → “Configure” or “Create” |
2) Inclusive UX Writing: Gender-Neutral and Identity-Respectful Language
Inclusive language ensures your copy doesn’t exclude or alienate users based on their identity or characteristics.
(1) Gender-Neutral Writing
| Instead of | Use |
|---|---|
| “He or she” | “They” (singular) |
| “Mankind” | “Humanity” or “People” |
| “Man-hours” | “Person-hours” or “Work hours” |
| “Guys” (addressing groups) | “Everyone,” “Team,” or “Folks” |
(2) Avoiding Ability Assumptions
| Problematic | Better |
|---|---|
| “See the results below” | “The results are below” (some users don’t “see”) |
| “Simply click the button” | “Select the button” (it’s not simple for everyone) |
| “Easy to use” | Describe specific benefits instead |
| “Normal users” | “Most users” or “Typical users” |
3) Accessible UX Copy: Link Text, Instructions, and Alt Text Basics
Accessible writing helps all users, including those using assistive technologies like screen readers.
(1) Link Text
Screen reader users often navigate by jumping between links. Each link should make sense out of context.
| Inaccessible | Accessible |
|---|---|
| “Click here” | “View your order history” |
| “Learn more” | “Learn more about pricing plans” |
| “Read more” | “Read the full case study” |
(2) Clear Instructions
Don’t rely on visual cues alone to convey meaning.
| Visual-Dependent | Clear for Everyone |
|---|---|
| “Click the red button” | “Click ‘Delete’” |
| “See the chart on the right” | “See the monthly revenue chart” |
| “Fill in the fields below” | “Enter your name and email address” |
(3) Alt Text Principles
When writing alt text for images:
- Describe the content and function, not the appearance
- Keep it concise (typically under 125 characters)
- Don’t start with “Image of…” (screen readers already announce it’s an image)
- For decorative images, use empty alt text (alt=””)
| Image Type | Alt Text Approach |
|---|---|
| Informative | Describe the essential information |
| Functional (buttons, links) | Describe the action, not the image |
| Decorative | Empty alt text |
| Complex (charts, diagrams) | Brief alt + detailed description nearby |
9. Conclusion: Words Are Part of the Product
UX writing isn’t decoration added after the “real” product work is done. Words are a fundamental part of how users experience what you build. A confusing label undermines elegant design. A helpful error message can save an otherwise frustrating interaction.
Transforming all your product copy overnight isn’t realistic. But small improvements compound.
Three things you can do this week:
- Review one screen: Pick a screen in your product and apply the self-review checklist. How many improvements can you find?
- Hunt for vague words: Search your product for “experience,” “seamless,” “new,” and “enhanced.” Replace each with something specific.
- Improve one error message: Find an error message that just says something failed. Rewrite it to explain what went wrong and how to fix it.
These small actions build the habit of treating words as seriously as any other product decision. Over time, that habit transforms the entire user experience.
Words guide users through your product. They explain, reassure, direct, and connect. When chosen carefully, they make complex things feel simple and unfamiliar things feel approachable.
That’s the craft of UX writing: helping users accomplish their goals with clarity and confidence, one word at a time.