$npx -y skills add cuellarfr/design-skills --skill ux-writingCreate 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 sof
| 1 | # UX Writing |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | ## When to Use This Skill |
| 6 | |
| 7 | Use this skill when: |
| 8 | - Writing interface copy (buttons, labels, titles, messages, forms) |
| 9 | - Editing existing UX text for clarity and effectiveness |
| 10 | - Creating error messages, notifications, or success messages |
| 11 | - Designing conversational flows or onboarding experiences |
| 12 | - Establishing voice and tone for a product |
| 13 | - Auditing product content for consistency and usability |
| 14 | |
| 15 | ## Core UX Writing Principles |
| 16 | |
| 17 | ### The Four Quality Standards |
| 18 | |
| 19 | Every piece of UX text should be: |
| 20 | |
| 21 | 1. **Purposeful** — Helps users or the business achieve goals |
| 22 | 2. **Concise** — Uses the fewest words possible without losing meaning |
| 23 | 3. **Conversational** — Sounds natural and human, not robotic |
| 24 | 4. **Clear** — Unambiguous, accurate, and easy to understand |
| 25 | |
| 26 | ### Key Best Practices |
| 27 | |
| 28 | **Conciseness** |
| 29 | - Use 40-60 characters per line maximum |
| 30 | - Every word must have a job |
| 31 | - Break dense text into scannable chunks |
| 32 | - Front-load important information |
| 33 | - Eliminate deadwood phrases ("in order to" → "to", "due to the fact that" → "because", "at this point in time" → "now") |
| 34 | - Replace phrasal verbs with direct verbs ("find out" → "discover", "set up" → "configure", "carry out" → "perform") |
| 35 | - Avoid stacking modifiers — one adjective is usually enough |
| 36 | |
| 37 | **Clarity** |
| 38 | - Use plain language (7th grade reading level for general, 10th for professional) |
| 39 | - Avoid jargon, idioms, and technical terms |
| 40 | - Use consistent terminology throughout |
| 41 | - Choose meaningful, specific verbs |
| 42 | - Avoid discriminatory or exclusionary language (gendered defaults, ableist idioms, culturally specific metaphors) |
| 43 | |
| 44 | **Conversational Tone** |
| 45 | - Write how you speak |
| 46 | - Use active voice 85% of the time |
| 47 | - Include prepositions and articles |
| 48 | - Avoid robotic phrasing |
| 49 | |
| 50 | **User-Centered** |
| 51 | - Focus on user benefits, not features |
| 52 | - Anticipate and answer user questions |
| 53 | - Use second-person ("you") language |
| 54 | - Match user's language and mental models |
| 55 | |
| 56 | ## UX Text Patterns |
| 57 | |
| 58 | Apply these common patterns for interface elements. |
| 59 | |
| 60 | ### Titles |
| 61 | - **Purpose**: Orient users to where they are |
| 62 | - **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.** |
| 63 | - **Types**: Brand titles, content titles, category titles, task titles |
| 64 | - **Examples**: |
| 65 | - Page title (title case): "Account Settings", "Your Library", "Run Payroll" |
| 66 | - Lower-level heading (sentence case): "Recent activity", "Bank account details", "Tax withholdings" |
| 67 | |
| 68 | ### Buttons and Links |
| 69 | - **Purpose**: Enable users to take action |
| 70 | - **Format**: Active imperative verbs, sentence case |
| 71 | - **Pattern**: `[Verb] [object]` |
| 72 | - **Examples**: "Save changes", "Delete account", "View details" |
| 73 | - **Avoid**: Generic labels like "OK", "Submit", "Click here" |
| 74 | |
| 75 | ### Error Messages |
| 76 | - **Purpose**: Explain problem and provide solution |
| 77 | - **Format**: Empathetic, clear, actionable |
| 78 | - **Pattern**: `[What failed]. [Why/context]. [What to do].` |
| 79 | |
| 80 | **Error Message Types** |
| 81 | |
| 82 | **Validation Errors (Inline)** |
| 83 | - Show as user completes field or on blur |
| 84 | - Brief, specific guidance to correct input |
| 85 | - Pattern: `[Field] [specific requirement]` |
| 86 | - Examples: |
| 87 | - "Email must include @" |
| 88 | - "Password must be at least 8 characters" |
| 89 | - "Choose a date in the future" |
| 90 | - Timing: Real-time or on field exit |
| 91 | - Location: Below or beside the field |
| 92 | |
| 93 | **System Errors (Modal/Banner)** |
| 94 | - Show when backend operations fail |
| 95 | - Explain what happened and why |
| 96 | - Pattern: `[Action failed]. [Likely cause]. [Recovery step].` |
| 97 | - Examples: |
| 98 | - "Payment failed. Your card was declined. Try a different payment method." |
| 99 | - "Couldn't save changes. Connection lost. Reconnect and try again." |
| 100 | - "Upload failed. File is too large. Choose a file under 10MB." |
| 101 | - Timing: Immediately after failure |
| 102 | - Location: Modal dialog or prominent banner |
| 103 | |
| 104 | **Blocking Errors (Full-screen)** |
| 105 | - Prevent continued |