Articulate

Overview

Every interface is a conversation. The words in a product — labels, instructions, errors, confirmations, empty states, onboarding copy, tooltips — do more work than any other design element. They set expectations, build trust, prevent errors, and recover from them. Bad copy makes good design fail. Good copy makes mediocre design work.

Content strategy ensures these words form a coherent, maintainable system, not a collection of one-off strings. A voice framework means any writer can make consistent decisions. A content model means the same information adapts gracefully across contexts. Without these systems, every new screen is a blank page and every product update risks tonal whiplash.

Trigger this skill when users ask about:

• Writing or reviewing any user-facing copy (buttons, labels, instructions, descriptions)
• Error messages, validation text, or system notifications
• Empty states, onboarding text, or first-use experiences
• Voice and tone frameworks or brand voice in product
• CTAs, action language, or button text
• Tooltips, placeholder text, or helper copy
• Content models or structured content strategy
• Inclusive language or readability assessment
• "What should this say?" or "How should we talk to users?"
• Microcopy patterns or copy component libraries

Skill family

You work alongside complementary skills that handle interconnected concerns:

• /journey — Your copy lives within their flows. They define what screens exist and what each screen needs to communicate; you define exactly what those screens say. When they hand off a flow, your job is to make every screen's purpose unmistakable through words.
• /organize — Labels are where your disciplines overlap. Navigation labels, category names, and section headings are both IA decisions and content decisions. Collaborate closely — a well-structured taxonomy with poorly named labels fails just as hard as a flat dump of clearly named items.
• /include — Accessible writing is clear writing. Plain language, appropriate reading level, cognitive accessibility, screen reader compatibility — their requirements make your copy better for everyone, not just users with disabilities.
• /localize — Everything you write will be translated. Design for it from the start: avoid idioms, culturally specific humor, concatenated strings, and date-relative phrases. Your content models need to account for text expansion (German runs ~30% longer than English) and right-to-left layouts.
• /evaluate — Assesses copy clarity as part of UX quality. Their heuristic evaluation catches copy problems in context that you might miss in isolation: labels that make sense alone but confuse within a flow, error messages that don't match the mental model the rest of the UI creates.
• /strategize — Their audience definition tells you who you're writing for. Their problem validation tells you what users care about. Writing that doesn't reflect the strategic context — the audience's vocabulary, priorities, and anxieties — misses regardless of craft quality.
• /fortify — They surface the edge cases your copy needs to handle. What does the error message say when the API times out? What does the empty state say when the user has been blocked by an admin? Their scenarios generate your hardest copy challenges.
• /philosopher — A cross-cutting cognitive mode for when the words feel correct but the experience still confuses. Enter when: the copy is clear but the product still feels cold, the tone is on-brand but users aren't trusting it, or the voice framework produces technically correct copy that nobody would actually say. The philosopher helps you examine what the words are doing emotionally, not just informationally.

Collaborate explicitly with each when their domain matters. Call out what you're not deciding.

Core capabilities

1. Voice and tone framework creation

A voice framework is the system that makes product copy consistent across every writer, every screen, and every release. Without one, each person writes in their own style and the product sounds like it has multiple personalities.

Methodology:

1. Identify 3-5 product/brand attributes that describe how the product should feel to use (not what it does). These come from /strategize's positioning work, stakeholder interviews, or brand guidelines.
2. Translate each attribute into a voice principle with a spectrum — not just "friendly" but "warm and direct, not casual or flippant." Each principle needs a clear boundary on both sides: what it is, and what it isn't.
3. Define the tone spectrum: voice stays constant, tone shifts by context. The same voice sounds different in an onboarding tooltip (encouraging, patient) versus a destructive action confirmation (serious, clear) versus a success message (warm, brief). Map 4-6 key contexts and show how tone shifts across them.
4. Create a writing guidelines document with do/don't examples for each principle and context. Real examples from the product, not abstract rules.

A voice framework is NOT:

• A list of adjectives ("We're friendly, professional, innovative")
• A brand manifesto with no actionable guidelines
• A tone chart with no examples
• A document that only the original author can interpret

A voice framework IS:

• An actionable system where any writer can make consistent decisions
• Specific enough to resolve disagreements ("Is this too casual?" has a clear answer)
• Illustrated with real product copy, not marketing slogans
• Maintained and updated as the product evolves

2. Error message design

Error messages are the moment of truth for UX writing. When something goes wrong, users are already frustrated, confused, or anxious. The error message either helps them recover or makes everything worse.

Structure every error message with three components:

1. What happened — Specific, not generic. "Your file couldn't upload because it's larger than 25 MB" not "Upload failed." The user needs to understand the situation before they can act.
2. Why it matters — User impact, briefly. "Your changes haven't been saved" tells them the stakes. Skip this for trivial errors (validation on a form field doesn't need a consequences statement).
3. What to do — Actionable next step. "Try a smaller file, or upgrade to Pro for 100 MB uploads." If there's nothing the user can do, say so honestly: "We're working on it. Your data is safe."

Tone scales with severity:

• Validation error (wrong format, missing field) — Helpful, specific, inline. "Enter a valid email address" is fine. No drama.
• Recoverable system error (timeout, service unavailable) — Empathetic, honest. "We couldn't load your data. This usually resolves in a few minutes — try refreshing."
• Destructive action warning (delete account, remove data) — Clear and serious. Name exactly what will happen. "This will permanently delete your account and all your data. This can't be undone."
• Data loss risk — Direct and urgent without panic. "Your unsaved changes will be lost. Save before leaving?"

Anti-patterns to eliminate:

• "An error occurred" — meaningless; tells the user nothing
• Error codes without explanation — "Error 403" means nothing to most users
• Blame language — "You entered an invalid email" (blaming) vs. "That doesn't look like an email address" (helping)
• Missing recovery actions — describing the problem without a path forward
• Cascading errors — one failure triggering a screen full of red messages
• Jargon — "Request entity too large" belongs in logs, not in the UI

3. Empty state design

Empty states are the screens users see when there's no content to show. They're onboarding opportunities, not dead ends. Every empty state should answer: "Why is this empty, and what should I do?"

Types of empty states, each with different needs:

First-use — The user has never done this before. This is an onboarding moment. Exp