1---
  2name: clarify
  3description: Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.
  4version: 2.1.1
  5---
  6
  7Identify and improve unclear, confusing, or poorly written interface text to make the product easier to understand and use.
  8
  9## MANDATORY PREPARATION
 10
 11Invoke /impeccable — it contains design principles, anti-patterns, and the **Context Gathering Protocol**. Follow the protocol before proceeding — if no design context exists yet, you MUST run /impeccable teach first. Additionally gather: audience technical level and users' mental state in context.
 12
 13---
 14
 15## Assess Current Copy
 16
 17Identify what makes the text unclear or ineffective:
 18
 191. **Find clarity problems**:
 20   - **Jargon**: Technical terms users won't understand
 21   - **Ambiguity**: Multiple interpretations possible
 22   - **Passive voice**: "Your file has been uploaded" vs "We uploaded your file"
 23   - **Length**: Too wordy or too terse
 24   - **Assumptions**: Assuming user knowledge they don't have
 25   - **Missing context**: Users don't know what to do or why
 26   - **Tone mismatch**: Too formal, too casual, or inappropriate for situation
 27
 282. **Understand the context**:
 29   - Who's the audience? (Technical? General? First-time users?)
 30   - What's the user's mental state? (Stressed during error? Confident during success?)
 31   - What's the action? (What do we want users to do?)
 32   - What's the constraint? (Character limits? Space limitations?)
 33
 34**CRITICAL**: Clear copy helps users succeed. Unclear copy creates frustration, errors, and support tickets.
 35
 36## Plan Copy Improvements
 37
 38Create a strategy for clearer communication:
 39
 40- **Primary message**: What's the ONE thing users need to know?
 41- **Action needed**: What should users do next (if anything)?
 42- **Tone**: How should this feel? (Helpful? Apologetic? Encouraging?)
 43- **Constraints**: Length limits, brand voice, localization considerations
 44
 45**IMPORTANT**: Good UX writing is invisible. Users should understand immediately without noticing the words.
 46
 47## Improve Copy Systematically
 48
 49Refine text across these common areas:
 50
 51### Error Messages
 52**Bad**: "Error 403: Forbidden"
 53**Good**: "You don't have permission to view this page. Contact your admin for access."
 54
 55**Bad**: "Invalid input"
 56**Good**: "Email addresses need an @ symbol. Try: name@example.com"
 57
 58**Principles**:
 59- Explain what went wrong in plain language
 60- Suggest how to fix it
 61- Don't blame the user
 62- Include examples when helpful
 63- Link to help/support if applicable
 64
 65### Form Labels & Instructions
 66**Bad**: "DOB (MM/DD/YYYY)"
 67**Good**: "Date of birth" (with placeholder showing format)
 68
 69**Bad**: "Enter value here"
 70**Good**: "Your email address" or "Company name"
 71
 72**Principles**:
 73- Use clear, specific labels (not generic placeholders)
 74- Show format expectations with examples
 75- Explain why you're asking (when not obvious)
 76- Put instructions before the field, not after
 77- Keep required field indicators clear
 78
 79### Button & CTA Text
 80**Bad**: "Click here" | "Submit" | "OK"
 81**Good**: "Create account" | "Save changes" | "Got it, thanks"
 82
 83**Principles**:
 84- Describe the action specifically
 85- Use active voice (verb + noun)
 86- Match user's mental model
 87- Be specific ("Save" is better than "OK")
 88
 89### Help Text & Tooltips
 90**Bad**: "This is the username field"
 91**Good**: "Choose a username. You can change this later in Settings."
 92
 93**Principles**:
 94- Add value (don't just repeat the label)
 95- Answer the implicit question ("What is this?" or "Why do you need this?")
 96- Keep it brief but complete
 97- Link to detailed docs if needed
 98
 99### Empty States
100**Bad**: "No items"
101**Good**: "No projects yet. Create your first project to get started."
102
103**Principles**:
104- Explain why it's empty (if not obvious)
105- Show next action clearly
106- Make it welcoming, not dead-end
107
108### Success Messages
109**Bad**: "Success"
110**Good**: "Settings saved! Your changes will take effect immediately."
111
112**Principles**:
113- Confirm what happened
114- Explain what happens next (if relevant)
115- Be brief but complete
116- Match the user's emotional moment (celebrate big wins)
117
118### Loading States
119**Bad**: "Loading..." (for 30+ seconds)
120**Good**: "Analyzing your data... this usually takes 30-60 seconds"
121
122**Principles**:
123- Set expectations (how long?)
124- Explain what's happening (when it's not obvious)
125- Show progress when possible
126- Offer escape hatch if appropriate ("Cancel")
127
128### Confirmation Dialogs
129**Bad**: "Are you sure?"
130**Good**: "Delete 'Project Alpha'? This can't be undone."
131
132**Principles**:
133- State the specific action
134- Explain consequences (especially for destructive actions)
135- Use clear button labels ("Delete project" not "Yes")
136- Don't overuse confirmations (only for risky actions)
137
138### Navigation & Wayfinding
139**Bad**: Generic labels like "Items" | "Things" | "Stuff"
140**Good**: Specific labels like "Your projects" | "Team members" | "Settings"
141
142**Principles**:
143- Be specific and descriptive
144- Use language users understand (not internal jargon)
145- Make hierarchy clear
146- Consider information scent (breadcrumbs, current location)
147
148## Apply Clarity Principles
149
150Every piece of copy should follow these rules:
151
1521. **Be specific**: "Enter email" not "Enter value"
1532. **Be concise**: Cut unnecessary words (but don't sacrifice clarity)
1543. **Be active**: "Save changes" not "Changes will be saved"
1554. **Be human**: "Oops, something went wrong" not "System error encountered"
1565. **Be helpful**: Tell users what to do, not just what happened
1576. **Be consistent**: Use same terms throughout (don't vary for variety)
158
159**NEVER**:
160- Use jargon without explanation
161- Blame users ("You made an error" → "This field is required")
162- Be vague ("Something went wrong" without explanation)
163- Use passive voice unnecessarily
164- Write overly long explanations (be concise)
165- Use humor for errors (be empathetic instead)
166- Assume technical knowledge
167- Vary terminology (pick one term and stick with it)
168- Repeat information (headers restating intros, redundant explanations)
169- Use placeholders as the only labels (they disappear when users type)
170
171## Verify Improvements
172
173Test that copy improvements work:
174
175- **Comprehension**: Can users understand without context?
176- **Actionability**: Do users know what to do next?
177- **Brevity**: Is it as short as possible while remaining clear?
178- **Consistency**: Does it match terminology elsewhere?
179- **Tone**: Is it appropriate for the situation?
180
181Remember: You're a clarity expert with excellent communication skills. Write like you're explaining to a smart friend who's unfamiliar with the product. Be clear, be helpful, be human.