From Fragmented Voices to a Single System
Unified Language, One Shared Source of Truth
ROLE
UX Writer / Content Designer
COMPANY
Poly / HP Device Products
AUDIENCE
Designers, developers & content writers
DELIVERABLE
First-ever content matrix + style guide
DEFINING THE PROBLEM
Four teams. One product. Zero shared voice.
Across the Poly product suite, designers were writing UI copy, developers were writing error strings, marketing was writing channel content, and technical writers were documenting features — all independently, with no shared reference for tone, terminology, or standards. The product spoke in four different voices depending on where you looked.
The absence of a content matrix meant the same feature could be named differently across the app, the quick start guide, the support site, and the marketing page. Users who encountered "Acoustic Fence" in one place and "noise cancellation" in another had no way to know they were the same thing. And every new writer who joined the team started from scratch — re-solving problems the team had already solved, or worse, solving them differently.
Inconsistent tone across channels
App copy felt clinical. Marketing felt warm. Documentation felt academic. No throughline connecting them.
Writers duplicating work
Every new piece of content reinvented decisions already made elsewhere. No single source of truth meant constant re-work.
No shared vocabulary
Feature names, button labels, and error terms varied by author — creating confusion for users and reviewers alike.
Stakeholders writing off-brand
Without a reference document, anyone who touched copy defaulted to their own voice — diluting the product's identity.
HIGH- LEVEL TIMELINE
Built to be in place before the next major product release cycle, so all new content — UI, docs, marketing — could be written from a shared foundation from day one.
MAIN GOAL
Create the first comprehensive content matrix and writing style guide for the Poly product team — a single, living document that designers, developers, and writers could all reference, trust, and contribute to.
THE BIGGER PICTURE
Hypothesis
If every person who touches product content — regardless of their role — has access to a single, clear reference for how the brand writes, what it calls things, and how it speaks in different contexts, the product will communicate with one voice, new team members will ramp faster, and the time spent reviewing and revising off-brand content will decrease significantly.
Consistency
A shared style guide eliminates the guesswork that leads to four versions of the same feature name — and the user confusion that follows when they encounter all four.
Efficiency
When decisions are documented, they don't have to be re-made. A content matrix means writers spend time writing — not debating whether to use "pair" or "connect" for the fifth time.
Scale
A living style guide grows with the product. New features, new channels, and new team members all benefit from a foundation that was built to be extended — not replaced.
Why this had never been done before: Style guides get deprioritized. They don't ship as a feature. They don't move a sprint forward. But the cost of not having one compounds quietly — in review cycles, in user confusion, in off-brand copy that's faster to write than to fix. This project made the invisible cost visible, then fixed it.
The content matrix was the more novel of the two deliverables — mapping every content type across every surface of the product (UI, onboarding, error states, documentation, marketing, support) against the tone, vocabulary, and ownership guidelines specific to that context. It became the team's content architecture in a single view.
UNDERSTANDING THE MARKET & USERS
Who the guide was designed for
A style guide is only as useful as its least-familiar reader. The guide had to be immediately actionable for a developer writing an error string at 5pm, a designer choosing button label copy in Figma, and a content writer drafting a new feature's marketing blurb — all without needing to read it end to end first.
UX designers
Software developers
Content writers
Marketing stakeholders
CONSTRAINT
The guide had to be detailed enough to resolve ambiguous content decisions — but scannable enough that no one needed to read the whole thing to find what they needed. A style guide no one opens is worth nothing. Usability of the document itself was a first-class design concern.
ADOPTION CHALLENGE
Existing teams had already developed their own informal patterns. The guide needed to document and validate what was working, establish clear standards where there was conflict, and do both without feeling prescriptive or punishing to the people already doing the work.
BRAINSTORMING
Breaking down the process
Building the first content matrix and style guide for a product team is an audit, an architecture exercise, and a writing project all at once. The process moved in four distinct phases — each one feeding directly into the next.
1
Content audit across every surface
Conducted a full audit of existing product content — UI strings, error messages, onboarding copy, in-box documentation, support articles, and marketing materials — cataloguing every instance of inconsistent terminology, conflicting tone, and missing standards. This audit was the foundation of both deliverables: the matrix mapped what existed, the style guide resolved what was broken.
2
Build the content matrix — content type by surface
Mapped every content type (UI labels, error states, onboarding, documentation, marketing, support) against every product surface, defining the tone, ownership, vocabulary rules, and character guidance specific to each cell. The matrix became a visual overview of the entire product's content architecture — something no one on the team had ever seen in one place before.
3
Write the style guide — decisions, not rules
Structured the style guide around decisions the team actually faced — not abstract principles. Every section answered a real question: "Do we say 'pair' or 'connect'?" "How do we write an error message when the cause is unknown?" "What's our tone in onboarding vs. in support?" Framing each entry as a decision — with context for why — made the guide feel like a teammate, not a rulebook.
4
Validate with cross-functional stakeholders and establish ownership
Shared drafts with designers, developers, and marketing leads — not for sign-off, but for gap-finding. Every piece of feedback that revealed a missing standard was folded back in. Established a clear ownership model so the guide could be maintained and extended after handoff, with named contributors responsible for specific sections as the product evolved.
MINI STYLE GUIDE
Conversation design principles applied
Decisions, not decrees
Every standard in the guide explains the reasoning behind it. "Use 'pair' not 'connect' because users associate 'connect' with internet — not Bluetooth" is more useful than a bare rule. When people understand why, they apply it correctly even in edge cases the guide didn't anticipate.
Living, not locked
A style guide written once and filed away is a historical document, not a working tool. Every section includes a clear owner and a versioning note. New features, new surfaces, and new team decisions get folded in — keeping the guide current rather than aspirational.
Scannable by role
A developer looking up error message standards shouldn't have to read the marketing tone section first. The guide was structured so each role could jump directly to the section most relevant to their work — with a content matrix overview at the top as the shared entry point.
Examples over explanations
Every principle is paired with a concrete example — a right-wrong pair showing the standard in context. Abstract guidance produces inconsistent application. A "write like this, not like that" example produces consistency even when the writer isn't sure which rule applies.
BREAKING DOWN THE PROCESS
The document transformation
Below is a representative comparison of how content decisions were captured before the style guide existed — scattered, inconsistent, and undocumented — versus how they're structured in the matrix and guide.
BEFORE - TERMINOLOGY IN THE WILD
Feature: Bluetooth pairing
UI copy: "Connect your device"
Quick start guide: "Pair your headset"
Support article: "Link the headset to your phone"
Marketing: "Seamlessly sync with any device"
Four terms. One feature. Zero consistency.
BEFORE - ERROR MESSAGE (NO STANDARD)
Developer-written error string
Error: Connection timeout. Code 408. Please check your network configuration and retry the operation."
Technical. Code-forward. No recovery action in plain language.
AFTER - STYLE GUIDE ENTRY
Bluetooth pairing — vocabulary standard
Always use: "pair" / "pairing"
Never use: connect, sync, link, bond
Why: "Connect" implies internet. "Sync" implies data transfer. "Pair" is the correct Bluetooth term and what users see in their device's Bluetooth settings — using the same word removes a translation step.
Owner: UX Writing · Last updated: Q3
AFTER - STYLE GUIDE ERROR TEMPLATE
Error message standard — connection failures
Pattern: [What happened] + [What to do next]
"Your headset lost connection. Move closer to your device and tap Reconnect."
No error codes in user-facing copy. One recovery action. Calm, not technical.
Owner: UX Writing + Engineering · Applies to: all app error states
BEFORE - SCATTERED DOCS
AFTER - CONTENT MARIX
KEY MOMENTS
Where the content work had the most impact
Building a style guide is a project that delivers its value gradually — through every review cycle it shortens, every debate it eliminates, every new hire it onboards faster. But three moments defined the work's highest-leverage impact.
The first time a developer used it instead of guessing
The earliest signal that the guide was working wasn't a metric — it was a Slack message. A developer writing an error state referenced the guide, used the correct pattern, and shipped it without a content review. That was the guide functioning exactly as designed: reducing the need for a content writer to be in the room for every decision.
01
The audit finding that changed a product decision
During the content audit, a feature was discovered that used three different names across four surfaces — including one that contradicted how the feature worked technically. Surfacing that finding in the style guide process led to a product-level rename before launch, preventing user-facing confusion at scale.
02
The new hire who onboarded without a content handoff
The real test of a style guide is whether someone new to the team can use it without explanation. When a new marketing writer joined mid-project and produced on-brand content without a dedicated content walkthrough — citing specific sections of the guide in their review notes — the document proved its value as infrastructure, not just reference material.
03
CONCLUSION
Deliverables & Outcomes
1 Voice
Unified product tone across UI, documentation, marketing, and support — for the first time
Rework
Reduced off-brand copy revisions in review cycles as shared standards replaced individual judgment calls
Speed
Faster content decisions and faster new-hire onboarding — with the guide as the first reference, not a content writer
SUMMARY
One guide. Every surface. Every writer.
-
Built the first comprehensive content matrix and writing style guide for the Poly product team.
-
Mapping content types, tone standards, approved vocabulary, and ownership across every surface the product touched, from UI strings and error messages to in-box documentation and marketing copy.
-
Delivered a living document with clear ownership, versioning structure, and a contribution model designed to grow with the product.
-
The guide became the team's single source of truth for content decisions — ending the cycle of re-made decisions, off-brand copy, and inconsistent product voice that had accumulated without one.
Future Outlook
The content matrix and style guide were built to scale. As the product line expands — new devices, new surfaces, new markets — the framework accommodates new content types without requiring a rebuild.
Finally in the same room
The next phase involves integrating the style guide into the team's design system, so vocabulary standards and tone guidance live alongside component documentation in a single, cross-functional reference. Content and design, finally in the same room.
THANK YOU!
NIKITA KING
