content-strategy
Content Strategy defines what content a product needs, how it should be structured and governed, and who owns it. Use this skill to audit existing content, establish content types and models, document voice and tone guidelines, clarify ownership and approval workflows, and ensure consistent communication across all user touchpoints. Essential for products with multiple content creators, complex information architecture, or inconsistent messaging.
git clone --depth 1 https://github.com/Owl-Listener/designer-skills /tmp/content-strategy && cp -r /tmp/content-strategy/ux-strategy/skills/content-strategy ~/.claude/skills/content-strategySKILL.md
# Content Strategy You are an expert in planning and governing the content that makes a product useful and trustworthy. ## What You Do You define what content a product needs, where it lives, who creates and maintains it, and how it should be written and structured — so the product communicates consistently and serves user needs at every touchpoint. ## Content Strategy Components ### Content Audit - Inventory of all existing content by type, location, owner, age, and performance - Classification: keep, revise, consolidate, or remove - Identifies gaps (content users need that doesn't exist) and redundancy (same content in multiple places) ### Content Model - Defines content types and their attributes (e.g. an "article" has: title, summary, body, author, tags, publish date) - Maps relationships between content types - Drives both design decisions (what fields a form needs) and engineering decisions (data structure) - A good content model enables reuse: one piece of content rendered in multiple contexts ### Voice & Tone - **Voice**: the consistent personality of the product's writing (helpful, direct, expert, warm…) - **Tone**: how voice adjusts to context (reassuring in error states, celebratory in success states, neutral in legal content) - Documented with examples and counter-examples for each register ### Content Governance - Who creates content (product, marketing, legal, users)? - Who reviews and approves it? - How often is it reviewed for accuracy and freshness? - Where is the source of truth? - What is the deprecation process for outdated content? ### Content Hierarchy - Primary content: the main thing users come to do or read - Secondary content: supporting context (descriptions, labels, help text) - Tertiary content: metadata, timestamps, attribution - Design should reflect this hierarchy visually; content strategy defines it semantically ## Relationship to Adjacent Disciplines - **UX writing**: content strategy defines the framework; UX writing executes at the component level - **Information architecture**: IA structures where content lives; content strategy defines what content exists and its attributes - **SEO**: content strategy decisions (topics, titles, depth) drive findability in search - **Brand**: voice and tone guidelines connect content strategy to brand identity ## Process 1. Audit existing content and identify gaps, redundancy, and orphaned material 2. Interview users and stakeholders to understand content needs and vocabulary 3. Define content types and models 4. Establish voice, tone, and writing principles 5. Define governance: owners, workflows, review cycles 6. Document and socialize — content strategy only works if writers follow it ## Best Practices - Start with a content audit before designing new structures — you often need less than you think - Involve legal and compliance early in voice and tone decisions - Make the content model drive component design, not the reverse - Revisit governance quarterly — content rots when ownership is unclear - Measure content performance (findability, task completion, search queries) to drive revisions
Facilitate a structured team critique — framing, feedback rules, and actionable outcomes. Use when running a session with people in the room. For a solo expert review, use `heuristic-evaluation` (prototyping-testing).
Inventory and prioritise accumulated design inconsistencies across a product. Use when drift has built up over time. For token coverage specifically use `design-token-audit` (designer-toolkit); for WCAG gaps use `accessibility-audit` (design-systems).
Communicate design's contribution to business and user outcomes in stakeholder language. Use when reporting results upward. For choosing the metrics in the first place, use `metrics-definition` (ux-strategy).
Build a QA checklist for verifying that a build matches the design. Use at implementation review. For the spec engineers build from, use `handoff-spec`.
Establish review gates — criteria, checkpoints, and approval flow. Use when work ships without consistent review. For running one individual session, use `design-critique`.
Plan and facilitate a design sprint from challenge framing through prototype testing. Use when compressing discovery into days. For ongoing team cadence, use `team-workflow`.
Write the implementation handoff — measurements, behaviours, assets, states, and edge cases. Use when engineering picks up the work. For verifying the result afterwards use `design-qa-checklist`; for reusable library components use `component-spec` (design-systems).
Design the team's operating rhythm — task management, collaboration rituals, and tooling. Use when the day-to-day cadence needs structure. For a time-boxed sprint, use `design-sprint-plan`.