What content in design systems covers
Design systems typically govern visual components — buttons, cards, modals — but leave content to individual judgment. This creates inconsistency: one team's error messages blame the user, another's are empathetic. Feature names vary across surfaces. Help text ranges from detailed to nonexistent. Content integration means making content as systematic as visual design: defined patterns, documented guidelines, and reusable components that ensure consistency without requiring every writer to reinvent every string.
The gap is revealing. Most design systems define exactly which shade of red to use for an error state but say nothing about what the error message should say, what tone to strike, or how long it should be. The result is products that look consistent but sound inconsistent — the visual equivalent of a building with a unified exterior and chaotic interior signage. Content in design systems closes this gap.
Content pattern library
Content Pattern Library Core Method
Use when: documenting reusable content patterns for common UI situations across your product.
A content pattern library defines the standard content for recurring interface situations, just as a component library defines the standard UI for recurring interactions. Error messages: Template for each error type (validation, system, permission, not found) with tone guidelines, character limits, and examples. Error messages should tell users what happened, why it happened, and what to do next. Empty states: Patterns for first-use empty states (welcoming, instructional), cleared/completed states (celebratory, next-step oriented), no-results states (helpful, suggesting alternatives), and error empty states (reassuring, actionable). Confirmation dialogs: Title, body, and button label patterns for destructive actions ("Delete this project?"), irreversible actions ("This can't be undone"), and high-stakes actions ("Publish to all users?"). Success messages: Patterns for inline confirmation ("Saved"), toast notifications ("Email sent to 3 recipients"), and completion screens (onboarding complete, purchase confirmed). Loading and waiting: Patterns for skeleton screens, progress indicators, and status messages during long operations. Each pattern includes: the situation it covers, the content template with placeholder slots, 2–3 real examples, and anti-examples showing what not to write.
Error Message Pattern Library Technique
Use when: standardizing error messages across your product so users get consistent, helpful feedback.
Error messages are the most common content consistency failure. Build a dedicated pattern library. Validation errors: Describe the requirement, not the failure. "Enter an email address" not "Invalid input." Show the error next to the field, not in a generic banner. System errors: Acknowledge the problem, avoid blame, offer a path forward. "Something went wrong on our end. Try again, or contact support if this continues." Never expose technical details (stack traces, error codes) to non-technical users. Permission errors: Explain why access is denied and how to get it. "You need editor access to make changes. Ask [Owner Name] to update your permissions." Not-found errors: Suggest alternatives. "This page doesn't exist. Try searching, or start from the homepage." Rate/limit errors: Be specific about the constraint. "You've reached the 5-project limit on your plan. Upgrade to create more projects." Never just say "limit reached."
Voice and tone
Voice & Tone Token System Core Method
Use when: making voice and tone as systematic and enforceable as design tokens.
Just as design tokens define colors and spacing as named values that enforce visual consistency, voice and tone tokens define content attributes as reusable guidelines. Voice tokens are permanent brand attributes that never change by context: your brand is always "direct, warm, knowledgeable" (or whatever you define). Voice tokens answer "who are we?" — the consistent personality across all touchpoints. Tone tokens adapt to context: error messages are "reassuring and helpful," success messages are "brief and celebratory," onboarding is "encouraging and clear," security alerts are "serious and urgent." Tone tokens answer "how do we sound right now?" Document tone tokens per UI context with before/after examples showing the same information delivered in wrong tone vs. right tone. Implementation: Map tone tokens to component states. A button component has visual states (default, hover, active, disabled); its associated label should have content tone states (standard, encouraging, cautionary). This mapping makes content guidance discoverable alongside the visual component it applies to.
Content Contribution Guidelines for Design Systems Technique
Use when: enabling non-writers (designers, engineers, PMs) to contribute content that meets quality standards.
Most product content is written by people who aren't content designers. Contribution guidelines reduce the inconsistency that creates. Decision trees: Provide simple decision trees for common content decisions. "Is this a confirmation or a success message?" → if confirmation: use this template; if success: use that template. Do/don't examples: For each content type, show 2–3 examples of good content and 2–3 examples of common mistakes, with explanations of why. People learn patterns faster from examples than from rules. Self-review checklist: A quick checklist contributors can run before submitting content: Is it clear without context? Does it tell the user what to do? Is it under the character limit? Does it match the tone for this context? Review workflow: Define when content needs content design review (new patterns, high-visibility surfaces, error flows) and when the contribution guidelines are sufficient (minor label changes, internal tools).
Naming conventions
Naming Convention Framework Core Method
Use when: creating consistent names for features, actions, and navigation labels across your product.
Inconsistent naming is one of the most common usability problems in products — and one of the easiest to prevent with a system. Feature names: Choose one name per feature and enforce it everywhere — UI, docs, marketing, support, internal communication. If engineering calls it "Workflows" and marketing calls it "Automations," users will be confused by both. Document the canonical name and all rejected alternatives. Action labels: Define standard verbs and use them consistently. Choose between Create/New, Edit/Modify, Delete/Remove, Save/Submit, and document the choice. Map verbs to action severity: "Delete" for destructive, "Remove" for reversible, "Cancel" for aborting. Navigation labels: Match labels to user mental models, not internal team names. "Settings" not "Configuration." "Help" not "Knowledge Base." Test navigation labels with card sorts to verify they match user expectations. Terminology glossary: Maintain a living glossary of all named concepts in your product. Include: the canonical name, definition, where it appears, related terms, and any localization guidance. Review when new features launch.
Content components
Content Component Design Technique
Use when: creating content blocks that can be reused across product surfaces like visual components.
Content components are reusable blocks of content with defined structure, constraints, and variation rules. Anatomy: Define the structural elements of each content component. A notification component has: icon, title (max 60 chars), body (max 120 chars), action link (max 25 chars). Constraints prevent content from breaking layouts. Variants: Like visual component variants (primary, secondary, destructive), content components have contextual variants. A help tooltip has variants for: feature explanation, keyboard shortcut, contextual tip, and external link. Each variant has different content structure and character limits. Slots: Content components have fillable slots where teams insert context-specific content. Provide guidelines for each slot — not just character limits but content expectations. The slot for "feature name" should contain the canonical feature name from the glossary, not a description. Composition: Show how content components combine. An onboarding step might compose a heading component, a body component, and an action component — each with independent content rules.
Content Linting Rules Technique
Use when: automating content quality checks to catch inconsistencies before they ship.
Content linting applies automated rules to catch common content problems. Terminology enforcement: Flag when a writer uses "delete" where the system standard is "remove," or uses a deprecated feature name. Character limits: Warn when content exceeds component character limits. Tone violations: Flag language that contradicts tone guidelines — exclamation points in error messages, passive voice in CTAs, jargon in consumer-facing copy. Inclusive language: Flag terms that violate inclusive language guidelines. Implementation: Integrate linting into the content workflow — ideally in the CMS or writing tool, not as a separate step. Linting should catch mechanical issues; human review should focus on meaning and tone.
Templates and checklists
- Every component page includes content guidelines alongside visual specs
- Voice tokens (permanent brand attributes) are documented with examples
- Tone tokens (contextual adaptations) are mapped to component states
- Error, empty state, confirmation, and success message patterns are documented
- Naming conventions are defined for features, actions, and navigation
- Character limits are set for each content slot in every component
- Content contribution guidelines exist for non-writer contributors
- A terminology glossary is maintained and linked from component pages
- Content linting rules are integrated into the authoring workflow
- Content patterns are updated when visual components are updated
Real-world examples
Case study
Shopify Polaris: content as a first-class design system citizen
Shopify's Polaris design system includes extensive content guidelines alongside visual components. Every component page includes content guidelines: what the component should say, what tone to use, character limits, and real examples from the product. The voice and tone documentation defines Polaris's content principles (be real, be proactive, be better every day) with examples per context — how the voice sounds in error messages vs. success messages vs. onboarding. Content guidelines are reviewed and updated alongside component updates, ensuring visual and content standards evolve together.
Why it works: Content guidelines are discoverable at the point of need — on the same page as the visual component spec. Writers don't have to hunt for guidelines in a separate document.
Case study
Atlassian: content patterns as components
Atlassian's design system treats content patterns with the same rigor as UI components. Error messages, empty states, and onboarding flows have documented patterns with templates, examples, and guidelines for when to use each variant. Their "writing guidelines" section is organized by component, not by content type — so a designer looking at the modal component finds the content pattern for modals right there, not in a separate content guide. They also maintain a "words we use" glossary that maps internal jargon to user-facing terminology.
Why it works: Content patterns are component-scoped, making them immediately actionable for designers and engineers who are building with the design system.
Common pitfalls
Content guidelines nobody reads
Writing extensive content guidelines that sit in a separate document nobody references is waste. Integrate guidelines where writers work: on component pages in the design system, in CMS field hints, in Figma file annotations. Guidelines should be discoverable at the point of need, not in a document that requires a separate search.
Voice guidelines too abstract to apply
"We're friendly, professional, and innovative" describes 90% of brands and helps nobody write a better error message. Voice guidelines need specificity: concrete examples of how the voice sounds in different contexts, before/after rewrites showing the guidelines in action, and decision trees for common tone questions ("When do we use humor? Never in error messages, sparingly in empty states, freely in marketing").
Content standards without content review
Documenting content patterns is necessary but not sufficient. Without a review process that catches deviations, standards erode within months. Define which content changes require content design review and which can self-serve through contribution guidelines.
Connected topics in your library
Cross-discipline connections
UX.2.11 Design Systems covers design systems from a visual/component perspective. UX.2.10 UX Writing & Content Design covers the individual craft of writing for interfaces. This topic covers the systematic integration of content into design infrastructure.