Building a Voice & Tone Guide for a Design System
Creating the content layer of a design system from scratch — a voice and tone guide that designers and engineers actually use.
The Work
The problem
Our design system had components for everything — buttons, forms, modals, cards. But the content layer was missing. Each team wrote UI copy in their own style, which meant the product felt like it had multiple personalities. Marketing wrote punchy headlines. Legal wrote dense disclaimers. Engineers wrote null_state_message.
The design system team invited me to build the content layer. The brief: make it useful enough that teams actually reference it.
What "useful" means here
Most voice & tone guides fail because they're abstract. They say things like "We're warm but professional" without explaining what that means for a button label or an empty state.
I wanted something different: a guide that gave specific, contextual guidance for the places where content decisions are actually made — components, flows, states.
Research
I spent three weeks in discovery:
- Interviewed 12 designers and 6 engineers about their current process for writing UI copy
- Ran a card sort to understand how teams currently thought about "voice" — whether they had shared mental models at all
- Audited 50 screens from across the product, tagging the tone of each piece of copy
The card sort was revelatory. When I showed the word "friendly" to different people, some thought it meant emoji and exclamation marks; others thought it meant clear and jargon-free. We had no shared language for talking about tone.
Building the guide
The guide has three layers:
Layer 1: Principles (the why) Four principles that describe our voice — what we value and why. These are stable; they don't change with product context.
Layer 2: Tone spectrum (the how) A dial from "professional" to "warm" with descriptions of when to use each register, and examples from real product screens. The key insight: the dial is a spectrum, not a binary. We're not always warm or always professional — we shift based on context.
Layer 3: Component-level guidance (the what) Specific guidance for every major component in the design system: buttons, tooltips, empty states, error messages, modals, notifications. Each section includes:
- The job of this component
- Dos and don'ts
- Before/after rewrites
- A checklist
This is where most of the value lives. A designer building an empty state can go straight to the empty state section and get specific help.
Rollout
I presented the guide at a company all-hands and published it in Notion alongside the design system documentation. I ran four workshops with product squads in the following month — not to teach the guide, but to use it on real problems together.
Adoption was gradual but real. The component-level guidance was the most-used section by far. Designers would screenshot the "before/after" examples and share them in Slack.
Outcome
- Teams referencing the guide weekly: from 0 to 11 (out of 14)
- "Inconsistent tone" as a design review comment: down 67% over 6 months
- New designer onboarding time to "writing in voice": cut from ~3 months to ~3 weeks
The best measure of success: a year later, the guide was still being updated and referenced — not abandoned like most documentation.