cuellarfr/design-skills/ux-writing

UX Writing

Write clear, concise, user-centered interface copy (UX text/microcopy) for digital products and experiences. This skill provides frameworks, patterns, and best practices for creating text that helps users accomplish their goals.

When to Use This Skill

Use this skill when:

• Writing interface copy (buttons, labels, titles, messages, forms)
• Editing existing UX text for clarity and effectiveness
• Creating error messages, notifications, or success messages
• Designing conversational flows or onboarding experiences
• Establishing voice and tone for a product
• Auditing product content for consistency and usability

Core UX Writing Principles

The Four Quality Standards

Every piece of UX text should be:

1. Purposeful — Helps users or the business achieve goals
2. Concise — Uses the fewest words possible without losing meaning
3. Conversational — Sounds natural and human, not robotic
4. Clear — Unambiguous, accurate, and easy to understand

Key Best Practices

Conciseness

• Use 40-60 characters per line maximum
• Every word must have a job
• Break dense text into scannable chunks
• Front-load important information
• Eliminate deadwood phrases ("in order to" → "to", "due to the fact that" → "because", "at this point in time" → "now")
• Replace phrasal verbs with direct verbs ("find out" → "discover", "set up" → "configure", "carry out" → "perform")
• Avoid stacking modifiers — one adjective is usually enough

Clarity

• Use plain language (7th grade reading level for general, 10th for professional)
• Avoid jargon, idioms, and technical terms
• Use consistent terminology throughout
• Choose meaningful, specific verbs
• Avoid discriminatory or exclusionary language (gendered defaults, ableist idioms, culturally specific metaphors)

Conversational Tone

• Write how you speak
• Use active voice 85% of the time
• Include prepositions and articles
• Avoid robotic phrasing

User-Centered

• Focus on user benefits, not features
• Anticipate and answer user questions
• Use second-person ("you") language
• Match user's language and mental models

UX Text Patterns

Apply these common patterns for interface elements.

Titles

• Purpose: Orient users to where they are
• Format: Noun phrases. Page titles, modal/dialog titles, and menu/navigation items use title case (see Capitalization below for title-case mechanics). Lower-level headings (H3+), figure captions, callouts, and table titles use sentence case.
• Types: Brand titles, content titles, category titles, task titles
• Examples:
• Page title (title case): "Account Settings", "Your Library", "Run Payroll"
• Lower-level heading (sentence case): "Recent activity", "Bank account details", "Tax withholdings"

Buttons and Links

• Purpose: Enable users to take action
• Format: Active imperative verbs, sentence case
• Pattern: [Verb] [object]
• Examples: "Save changes", "Delete account", "View details"
• Avoid: Generic labels like "OK", "Submit", "Click here"

Error Messages

• Purpose: Explain problem and provide solution
• Format: Empathetic, clear, actionable
• Pattern: [What failed]. [Why/context]. [What to do].

Error Message Types

Validation Errors (Inline)

• Show as user completes field or on blur
• Brief, specific guidance to correct input
• Pattern: [Field] [specific requirement]
• Examples:
• "Email must include @"
• "Password must be at least 8 characters"
• "Choose a date in the future"
• Timing: Real-time or on field exit
• Location: Below or beside the field

System Errors (Modal/Banner)

• Show when backend operations fail
• Explain what happened and why
• Pattern: [Action failed]. [Likely cause]. [Recovery step].
• Examples:
• "Payment failed. Your card was declined. Try a different payment method."
• "Couldn't save changes. Connection lost. Reconnect and try again."
• "Upload failed. File is too large. Choose a file under 10MB."
• Timing: Immediately after failure
• Location: Modal dialog or prominent banner

Blocking Errors (Full-screen)

• Prevent continued use until resolved
• Clear explanation of blocker and resolution
• Pattern: [What's blocked]. [Why]. [Specific action needed].
• Examples:
• "Update required. This version is no longer supported. Update now to continue."
• "Subscription expired. Your account is paused. Renew subscription to restore access."
• "Verification needed. Confirm your email to access features. Check your inbox."
• Timing: On app launch or feature access
• Location: Full screen or large modal

Permission Errors

• Explain benefit before requesting permission
• Pattern: [User benefit]. [Permission needed].
• Examples:
• "Get notified when orders ship. Enable notifications."
• "Find nearby stores. Allow location access."
• "Back up your photos. Grant storage permission."
• Timing: When feature is first used
• Location: In context of the feature

What to Avoid

• Technical codes without explanation ("Error 403")
• Blame language ("invalid input", "illegal character")
• Robotic tone ("An error has occurred")
• Dead ends (error with no recovery path)
• Vague causes ("Something went wrong")

Success Messages

• Purpose: Confirm action completion
• Format: Past tense, specific, encouraging
• Pattern: [Action] [result/benefit]
• Examples: "Changes saved", "Email sent", "Profile updated"

Empty States

• Purpose: Guide users when content is absent
• Types: First-use, user-cleared, error/no results
• Format: Explanation + CTA to populate
• Example: "No messages yet. Start a conversation to connect with your team."

Form Fields

• Labels: Clear noun phrases describing input ("Email address", "Phone number")
• Instructions: Verb-first, explain why information is needed
• Placeholder: Use sparingly, only for standard inputs like "name@example.com"
• Helper text: Static, on-demand, or automatic based on importance

Notifications

• Purpose: Deliver timely, valuable information
• Types: Action-required (intrusive), Passive (less intrusive)
• Format: Verb-first title + contextual description
• Example: "Update required. Install the latest version to continue."

Formatting & Style Conventions

Capitalization

• Sentence case (default): Body text, descriptions, helper text, error messages, success messages, tooltips, placeholder text, button labels, lower-level (H3+) headings, figure captions, callouts, table titles
• Title case: Page titles, modal/dialog titles, menu and navigation items, form field labels
• All-caps: Reserved for short overline / eyebrow labels (≤3 words) that sit above a heading or metric — e.g., stat-card section headers like EMPLOYEES, TOTAL PAY, LAST UPDATED, category tags over KPI values — and for acronyms (PDF, URL, API, EIN, SSN). For short category overlines it's an intentional typographic signal, not shouting. Do not use all-caps for prose, button labels, error messages, page titles, tabs/menu labels, or any string longer than ~3 words — beyond that length readability drops sharply and it reads as shouting.

Title case mechanics (applies wherever title case is used):

• Capitalize the first and last word of the title regardless of part of speech.
• Capitalize all adjectives, adverbs, and nouns.
• Capitalize all pronouns (including "it").
• Capitalize all verbs, including the verb "to be" in all forms (is, are, was, has been, etc.).
• Capitalize "no", "not", and the interjection "O".
• Do not capitalize articles ("a", "an", "the") unless first or last in the title.
• Do not capitalize coordinating conjunctions ("and", "or", "nor", "but", "for", "yet", "so") unless first or last in the title.
• Do not capitalize "to" (with or without an infinitive) unless first or last in the title.
• Do not capitalize prepositions (e.g., "in", "on", "at", "by", "of", "with") unless first or last in the title.

Examples:

• "Run Payroll for the Pay Period"
• "Add a New Employee"
• "How to File Quarterly Taxes"

Edge cases:

• "Coming soon" is the canonical future-feature label everywhere it appears (badges, callouts, copy). Even when used in a title-cased context, write it sentence case. Do not expose milestone granularity ("Coming at Beta", "Coming at GA") in user-facing strings.
• Dropdown action items (imperative-verb items inside a button-triggered menu, e.g. "Add employee", "See payroll runs", "Export report") are treated as buttons → sentence case, not as static navigation menu items. The "menu items use title case" rule applies to navigational menus (side nav, breadcrumbs, top-level nav links pointing to pages), not action menus.
• Buttons that reference a named page (e.g. "Go to Setup Wizard", "Back to Payroll Hub", "Open Time Review") preserve the page name's title case while the surrounding button copy stays sentence case. The page name is a proper noun in this context.

Numbers and Dates

• Use numerals, not words ("12" not "twelve") — saves space and scans faster.
• Spell out the month in dates: "August 5, 2025" or "5 August 2025" — never "8/5/2025" or "8.5.2025" (ambiguous across locales).
• Spell out day of the week and month; abbreviate only when space is constrained (e.g., tables, mobile): "Sat., Jan. 24".
• Avoid ordinal suffixes in dates: write "August 5", not "August 5th"; write "May 1", not "May 1st".
• Year ranges use a hyphen with the full year on both sides: "2015-2016", not "2015-16" and not "2015 to 2016".

Tense

• Prefer past tense over present perfect for status messages: "File uploaded" not "File has been uploaded"
• Present perfect adds words without adding meaning in most UI contexts

Abbreviations

• Only use abbreviations your users will immediately understand (common: PDF, URL, ID)
• Spell out on first use if there's any doubt, then abbreviate after: "application programming interface (API)"
• Latin abbreviations (e.g., i.e., etc.) — use proper punctuation: period after each letter, comma before and after in a sentence
• When in doubt, spell it out

Voice and Tone

Voice (Consistent Brand Personality)

Voice is the consistent personality of the product. Establish voice using:

• Concepts: 3-5 key brand principles/values
• Voice characteristics: Descriptive adjectives for each concept
• Do/Don't examples: Concrete examples showing voice in action

See references/voice-chart-template.md for creating a voice chart.

Tone (Adaptive to Context)

Tone is how voice adapts to specific situations. While voice remains constant, tone shifts based on user context and emotional state.

Tone Variables

• Purpose: Why user is seeing this text (information, action, confirmation)
• Context: What user is trying to do (learning, completing task, recovering from error)
• Emotional state: How user likely feels (frustrated, excited, confused, cautious)
• Stakes: Impact of the action (low: changing theme, high: deleting account)

Tone Adaptation by User Emotional State

Frustrated (errors, failures, blockers)

• Empathetic and solution-focused
• Acknowledge the problem without blame
• Provide clear recovery path
• Example: "Payment failed. Your card was declined. Try a different payment method."

Confused (first use, complex features)

• Patient and explanatory
• Break down steps clearly
• Provide context and guidance
• Example: "Connect your bank to see spending insights. We'll guide you through it."

Confident (routine tasks, return visits)

• Efficient and direct
• Minimal explanation
• Quick confirmation
• Example: "Saved"

Cautious (high-stakes actions, data loss)

• Serious and transparent
• Clear consequences
• Respectful of user's decision
• Example: "Delete account? You'll lose all data and this can't be undone."