ux-writing
Skill9 starsChanged 8 months agoMITView on GitHub
Create user-centered, accessible interface copy (microcopy) for digital products including buttons, labels, error messages, notifications, forms, onboarding, empty states, success messages, and help text. Use when writing or editing any text that appears in apps, websites, or software interfaces, designing conversational flows, establishing voice and tone guidelines, auditing product content for consistency and usability, reviewing UI strings, or improving existing interface copy. Applies UX writing best practices based on four quality standards — purposeful, concise, conversational, and clear. Includes accessibility guidelines, research-backed benchmarks (sentence length, comprehension rates, reading levels), expanded error patterns, tone adaptation frameworks, and comprehensive reference materials.
25 other projects use a version of this, 4 of them edited.
Adopted by
Most recently taken up by
- brianciou/ux-writingtheir own version, first seen Nov 8, 2026
- MrMengJ/skillstheir own version, first seen Nov 1, 2026
- WST2002/claude-code-skillstheir own version, first seen Nov 1, 2026
- vediteur/claude-skillstheir own version, first seen Oct 26, 2026
- KMaruthi2002/universal-llm-skillstheir own version, first seen Oct 25, 2026
- toribryan/design-skillstheir own version, first seen Oct 25, 2026
Used with
Projects with it also use design-critique, design-tokens and 1 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
AnthropicSkilldesign-critique
Get structured design feedback on usability, hierarchy, and consistency. Trigger with "review this design", "critique this mockup", "what do you think of this screen?", or when sharing a Figma link or screenshot for feedback at any stage from exploration to final polish.
Also in 5 projects that use this
ilikescienceSkilldesign-tokens
Expert in design tokens using the DTCG specification. Use this skill when users ask about design tokens, DTCG format, token validation, formatting, transformation, color spaces (sRGB, Display P3, OKLCH), references and aliasing, resolvers, theming with modifiers/contexts, multi-platform design systems, accessibility, or working with tools like jq, jsonata, and terrazzo. Helps with token file creation, resolver configuration, structure, naming conventions, and best practices.
Also in 3 projects that use this
GitHubSkillaccessibility-audit
Audits actual components and routes against applicable WCAG 2.2 A/AA criteria using consumer-owned design-system evidence and repository tools. Use when asked for an accessibility audit, a11y check, keyboard or focus review, contrast check, or screen-reader verification.
Also in 3 projects that use this
Other versions25 projects use a version of this.
Word for word · 0
None found.
Edited · 4
- awesomestvi/navet★ 37597% same
- content-designer/ux-writing-skill★ 16197% same
- cuellarfr/design-skills★ 9479% same
- stritar/skills★ 097% same
Wrote their own version · 21
- plugin87/ux-ui-agent-skills★ 3.1ksame name
- scarletkc/agents★ 227same name
- scarletkc/seiso★ 184same name
- nahid-sparktales/agent-dispatcher★ 59same name
- launchapp-dev/animus-cli★ 39same name
- icons8/agent-skills★ 12same name
- BojanKocijan/bk-charterline★ 4same name
- BojanKocijan/design-forge★ 4same name
- WST2002/claude-code-skills★ 4same name
- akashsoti/claude-skills★ 3same name
11 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- Accessibility AuditSkill
- Design Critique & EvaluationSkill
- design-elevationSkill
- design-opsSkill
- Design SystemsSkill
- Interaction DesignSkill
- Journey Mapping & Service DesignSkill
- ux-researchSkill
- UX StrategySkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
35 rules. 0 are common, 35 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 22 edited versions we read keep these.
35
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Write clear, concise, user-centered interface copy (UX text/microcopy) for digital products and experiences.
- Distinctive: line 12
Use this skill when:
- Distinctive: line 24
Every piece of UX text should be:
- Distinctive: line 34
Use 40-60 characters per line maximum
- Distinctive: line 35
Every word must have a job
- Distinctive: line 40
Avoid stacking modifiers — one adjective is usually enough
- Distinctive: line 43
Use plain language (7th grade reading level for general, 10th for professional)
- Distinctive: line 44
Avoid jargon, idioms, and technical terms
- Distinctive: line 45
Use consistent terminology throughout
- Distinctive: line 49
Write how you speak
- Distinctive: line 50
Use active voice 85% of the time
- Distinctive: line 57
Use second-person ("you") language
- Distinctive: line 149
Placeholder: Use sparingly, only for standard inputs like "name@example.com"
- Distinctive: line 164
Never: use all uppercase — it reduces readability and feels like shouting
- Distinctive: line 168
Use numerals, not words ("12" not "twelve") — saves space and scans faster
- Distinctive: line 174
Prefer past tense over present perfect for status messages: "File uploaded" not "File has been uploaded"
- Distinctive: line 179
Only use abbreviations your users will immediately understand (common: PDF, URL, ID)
- Distinctive: line 182
When in doubt, spell it out
- Distinctive: line 280
Ensure every word earns its space
- Distinctive: line 284
Read aloud—would you say this?
- Distinctive: line 285
Use active voice (unless passive is clearer)
- Distinctive: line 290
Use specific, accurate verbs
- Distinctive: line 292
Test readability (Hemingway Editor, Flesch-Kincaid)
- Distinctive: line 304
Start with conversation (what would you say?)
- Distinctive: line 306
Consider voice and tone
- Distinctive: line 317
Test with users when possible
- Distinctive: line 329
Write descriptive link text ("Read pricing details" not "Click here")
- Distinctive: line 331
Use ARIA labels when visual context isn't sufficient
- Distinctive: line 336
Use clear headings and logical hierarchy
- Distinctive: line 340
Don't rely on color alone to convey meaning
- Distinctive: line 343
Ensure sufficient color contrast (WCAG AA minimum: 4.5:1)
- Distinctive: line 348
Avoid idioms, metaphors, and cultural references
- Distinctive: line 349
Use common, everyday words
- Distinctive: line 371
Use these research-backed metrics to create effective UX text.
- Distinctive: line 438
examples/real-world-improvements.md: Before/after transformations with detailed analysis and scoring
“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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:
- Purposeful — Helps users or the business achieve goals
- Concise — Uses the fewest words possible without losing meaning
- Conversational — Sounds natural and human, not robotic
- 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
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, sentence case
- Types: Brand titles, content titles, category titles, task titles
- Examples: "Account settings", "Your library", "Create new post"
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
- Title case: Page titles, modal/dialog titles, menu and navigation items, form field labels
- Never use all uppercase — it reduces readability and feels like shouting
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)
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."
Successful (completions, achievements)
- Positive and encouraging
- Proportional to achievement
- Brief celebration
- Example: "Profile updated. Your changes are live."
Tone Adaptation by Content Type
Error messages: Empathetic, reassuring, solution-focused
- Never blame user
- Explain what happened
- Provide clear next step
Success messages: Positive, specific, encouraging
- Confirm what happened
- Proportional to action importance
- Brief and clear
Instructions: Clear, direct, helpful
- Front-load key action
- Explain why when needed
- Use simple steps
Onboarding: Inviting, encouraging, concise
- Welcome without overwhelming
- Focus on value
- Celebrate early wins
Confirmations: Serious, transparent, respectful
- Clear about consequences
- No manipulation
- Easy to back out
Empty states: Hopeful, actionable, guiding
- Explain why it's empty
- Provide clear next action
- Keep encouraging tone
Editing Process
Edit UX text in four phases:
Phase 1: Purposeful
- Does text help user achieve their goal?
- Does text serve business objectives?
- Is value to user clear?
- Are concerns anticipated and addressed?
Phase 2: Concise
- Remove unnecessary words
- Combine redundant information
- Ensure every word earns its space
- Front-load important concepts
Phase 3: Conversational
- Read aloud—would you say this?
- Use active voice (unless passive is clearer)
- Include natural connecting words
- Avoid corporate jargon
Phase 4: Clear
- Use specific, accurate verbs
- Maintain consistent terminology
- Test readability (Hemingway Editor, Flesch-Kincaid)
- Ensure unambiguous meaning
Workflow
- Understand context
- User goals and needs
- Business objectives
- Technical constraints
- Emotional state of user
- Draft content
- Start with conversation (what would you say?)
- Apply appropriate pattern
- Consider voice and tone
- Front-load important information
- Edit iteratively
- Phase 1: Purposeful
- Phase 2: Concise
- Phase 3: Conversational
- Phase 4: Clear
- Test and measure
- Review with team
- Test with users when possible
- Measure task completion, comprehension
- Iterate based on feedback
Accessibility in UX Writing
Writing accessible content ensures all users, including those using assistive technology, can understand and interact with your product.
Core Accessibility Principles
Screen Reader Optimization
- Label all interactive elements explicitly ("Submit form" not just "Submit")
- Write descriptive link text ("Read pricing details" not "Click here")
- Structure error messages to work with screen readers (error + field label read together)
- Use ARIA labels when visual context isn't sufficient
Cognitive Accessibility
- Target 8-14 words per sentence (8 words = 100% comprehension, 14 words = 90%)
- Break complex information into scannable chunks
- Use clear headings and logical hierarchy
- Provide consistent, predictable patterns
Multi-Modal Communication
- Don't rely on color alone to convey meaning
- Pair visual indicators with text ("Error: Email required" with red icon)
- Provide text alternatives for icons and images
- Ensure sufficient color contrast (WCAG AA minimum: 4.5:1)
Plain Language for All
- Target 7th-8th grade reading level for general audience
- Define technical terms when first used
- Avoid idioms, metaphors, and cultural references
- Use common, everyday words
Accessible Pattern Examples
Buttons
- ❌ Poor: "Submit" (context missing for screen readers)
- ✅ Good: "Submit application"
Links
- ❌ Poor: "Click here for more information"
- ✅ Good: "Read our privacy policy"
Error Messages
- ❌ Poor: Red text showing "Invalid"
- ✅ Good: "Error: Email must include @" (with error icon)
Form Labels
- ❌ Poor: Placeholder-only fields
- ✅ Good: Visible label + optional placeholder
UX Text Benchmarks
Use these research-backed metrics to create effective UX text.
Sentence Length Targets
By Content Type
- Buttons/CTAs: 2-4 words ideal, 6 word maximum
- Titles: 3-6 words, 40 characters maximum
- Error messages: 12-18 words (including solution)
- Instructions: 20 words maximum, 14 ideal
- Body copy: 15-20 words per sentence average
- Notifications: 10-15 words for title + body
Comprehension Rates
- 8 words or fewer: 100% user comprehension
- 14 words or fewer: 90% user comprehension
- 25 words: Maximum before significant comprehension drop
Character and Line Length
Optimal Ranges
- Line length: 40-60 characters for maximum readability
- Button labels: 15-25 characters
- Page titles: 30-50 characters
- Notification titles: 35-45 characters
Reading Level Guidelines
By Audience
- General public: 7th-8th grade (Flesch-Kincaid)
- Professional tools: 9th-10th grade
- Technical products: 10th-11th grade
- Specialized fields: 11th-12th grade (only when necessary)
Testing Tools
- Hemingway Editor: Highlights complex sentences
- Readable.com: Provides multiple readability scores
- Microsoft Word: Built-in Flesch-Kincaid scoring
Common Mistakes to Avoid
- Using passive voice excessively
- Generic button labels ("Submit", "OK")
- Blaming users in error messages
- Overly clever humor in serious contexts
- Inconsistent terminology
- Hidden instructions or explanations
- System-oriented language vs. user language
- Too many words (not concise enough)
- Robotic, corporate tone
- Relying on color alone for meaning
- Writing inaccessible link text ("Click here")
Quick Reference
Sentence case: "Save your changes" (not "Save Your Changes")
Active imperative for buttons: "Delete account" (not "Account deletion")
User-focused: "Save time with shortcuts" (not "We offer shortcuts")
Specific verbs: "Delete" (not "Remove" when permanently deleting)
Front-loaded: "Password must be 8 characters" (not "Must be 8 characters for your password")
Resources
This skill includes:
- references/accessibility-guidelines.md: Comprehensive guide to writing accessible UX text for all users
- references/voice-chart-template.md: Template for creating a product voice chart
- references/content-usability-checklist.md: Comprehensive checklist for evaluating UX text quality
- references/patterns-detailed.md: Extended examples of UX text patterns in different voices
- examples/real-world-improvements.md: Before/after transformations with detailed analysis and scoring
- templates/error-message-template.md: Fillable template for writing effective error messages
- templates/empty-state-template.md: Guide for creating helpful empty states
- templates/onboarding-flow-template.md: Framework for designing clear onboarding experiences
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

