Stats
Actions
Tags
From ios-skills
Use when someone asks to write, rewrite, review, or improve text that appears inside a product or interface. Examples: "review the UX copy", "is there a better way to phrase this", "rewrite this error message", "write copy for this screen/flow/page", reviewing button labels, improving CLI output messages, writing onboarding copy, settings descriptions, or confirmation dialogs. Trigger whenever the request involves wording shown to end users inside software — apps, web, CLI, email notifications, modals, tooltips, empty states, or alerts. Also trigger for vague requests like "review the UX" where interface copy review is implied. Do NOT trigger for content marketing, blog posts, app store listings, API docs, brand guides, cover letters, or interview questions — this is a technical writing skill for interface language.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ios-skills:andrewgleave--writing-for-interfacesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Good interface writing is invisible. When words work seamlessly with design, people don't
Good interface writing is invisible. When words work seamlessly with design, people don't notice them.
Writing should be part of the design process from the start, not something filled in at the end. When words are considered alongside layout, interaction, and visual design, the result feels seamless. When they're an afterthought, product experiences feel stitched together.
Every piece of text in an interface is a small act of communication: it should respect the person's time, meet them where they are, and help them move forward.
Voice is the foundation. All copy decisions — what to say, how to say it, what to leave out — flow from a clear understanding of who this product is, who it's for, and how it should sound. Without a defined voice, copy becomes inconsistent and the product loses coherency.
Search for an existing voice definition. Check for:
CLAUDE.md, AGENTS.md, or similar project config that defines voice and/or toneIf a voice definition exists, use it as the lens for all copy work. If the copy you're working on drifts from it, flag the inconsistency.
If no voice definition exists, infer the current voice from existing copy. Look for patterns: formal or casual? Technical or plain? Warm or matter-of-fact? If the copy is inconsistent or insufficient to infer from, help the user establish a voice before writing.
Walk the user through these questions:
What does the product do and who is it for? A banking app for professionals and a savings app for kids serve similar purposes but should sound completely different. The audience determines vocabulary, complexity, and register.
Why do people use it, and where? Someone using a health app during a crisis needs calm clarity. Someone browsing a game at home can handle playfulness. The context of use — physical environment, emotional state, competing attention — shapes how much text people can absorb and what tone is appropriate.
Imagine the product as a person. What 3–4 personality traits make them unique? Brainstorm freely, group similar words into themes, discard table-stakes traits ("not confusing"), and keep the ones that genuinely differentiate the product's personality.
Look for productive tensions. The best voice definitions have qualities that push against each other. "Friendly" and "concise" create a useful tension — these become the dials you turn when adjusting tone for different situations.
Capture it. Suggest the user persist the voice definition somewhere durable
(AGENTS.md, CLAUDE.md or style guide document) so it persists across sessions. A word list pairs well with this and should be stored in the same file.
Identify what kind of copy work is needed:
Then identify which interface patterns are involved
and consult references/patterns.md for the relevant sections.
For every piece of copy, work in this order:
The ordering is deliberate and encodes a precedence chain: clarity > voice > craft rules. Clarity always wins — if voice gets in the way of someone understanding what to do, strip it back. Voice comes next — it shapes how things sound, and a craft rule should never cut a word or restructure a phrase in a way that undermines the established voice. Craft rules are voice-filtered heuristics, not absolutes. Always cross-check craft edits against the voice before committing them.
Work through the copy element by element — title, body, buttons, labels — showing the original, then the rewrite, with a brief rationale tied to voice and principles. Prioritise changes that confuse or block users before polish. When reviewing across a flow, flag terminology inconsistencies and suggest word list entries at the end.
Voice is the consistent personality of the product — the 3–4 qualities that define how it always sounds. These don't change.
Tone is how the voice adapts to the situation. Think of each voice quality as a dial you can turn up or down depending on the moment:
For each situation, decide which voice qualities need emphasis and which should recede.
Example: For an error where someone can't connect to the network, clarity and helpfulness go way up. Simplicity stays moderate because they need the most important details. Friendliness dials back because getting them unstuck matters more than sounding warm.
Personality shines in moments where there's room for it — welcome screens, milestones, empty states. In error messages, destructive actions, and critical flows, dial voice back and let clarity lead. The precedence chain from Step 3 applies: clarity first, always.
Purpose, Anticipation, Context, Empathy — a framework for what to write, how to write it, and when. Apply through the lens of your voice.
Before writing, answer: what is the single most important thing the person needs to know right now?
Think of the interface as a conversation. In any good conversation there's a natural back and forth — listening, responding, anticipating what the other person needs to hear next.
People use products in wildly different circumstances. The usage context shapes the writing.
Write for everyone who might use this product — different abilities, languages, cultures, technical fluency, and emotional states.
Practical editing moves that tighten copy. Apply after confirming voice and tone are right.
Interface text has no minimum word count. Every word must earn its place. But before cutting a word, check whether it's doing voice work. A word that's "filler" by general craft rules may be load-bearing for the voice — "yet" in "Nothing here yet" carries warmth and calm, and removing it makes the empty state blunter. The test: remove the word; if neither meaning nor intentional tone changes, cut it.
Combine overlapping ideas into one clear statement. Each element on screen should add new information. When headline and body say the same thing in different words, collapse them.
"We're running late. Your delivery driver won't make it on time. They'll be there in 10 minutes." → "Delivery delayed 10 minutes. Check the app for your driver's location."
Decide what you call things and stick to it. If it's "alias" on one screen, don't use "username" on another. A word list is a simple table: Use / Don't use / Definition. Button labels are especially good entries — if "Next" advances through a flow, use "Next" everywhere.
"Favorites" conveys the same message as "Your Favorites." Avoid "we" — it obscures what actually happened ("We're having trouble..." → "Unable to load content").
Correct spelling, grammar, and punctuation build trust. Adopt capitalisation rules aligned with the voice (title case = formal, sentence case = casual) and apply consistently. Write for the space available — if copy needs to be short, write a short sentence, don't compress a long one.
Templated strings ("${count} items selected") are interface copy too. Write them so every
possible output reads naturally:
Define patterns for common moments — how flows begin ("Get Started"), advance ("Next" or "Continue" — pick one), and end ("Done"). Use them consistently.
Read your writing out loud. If it sounds like how you'd explain something to a friend — clear, natural, no filler — it's probably good. If it sounds like a robot, a legal document, or an essay, keep refining.
For detailed guidance on alerts, errors, empty states, onboarding, notifications,
accessibility labels, destructive actions, buttons, and instructional copy — see
references/patterns.md.
npx claudepluginhub jordancoin/ios-skills-collection --plugin ios-skillsWrites clear UI copy for microcopy, error messages, empty states, CTAs, onboarding, and confirmations with voice, tone, and best practices.
Produces UX writing deliverables: voice and tone guides, microcopy for features, and content audits of existing product copy.
Designs and reviews product copy — labels, errors, empty states, onboarding, tooltips, CTAs, and voice/tone frameworks. Trigger when user-facing text needs writing or editing.