01
Context
The organization already had a Corporate Style Guide. A PDF, maintained by the brand team, defining the corporate palette, typography, iconography, and visual rules for every employee, vendor, and partner who ever touched a customer-facing surface. Brand had its source of truth.
What the development team had was the same PDF. Five product teams interpreting type ramps and color tokens by hand, each one translating the guide into its own Figma files and its own CSS — five times over, slightly differently, every release. Buttons looked similar but behaved differently. Modals were re-implemented four ways. Engineering velocity bled into reconciliation, not features.
“The drift wasn't a brand problem. It was a translation problem.”
Designers and engineers didn't need new visual rules; they needed a machine-readable derivative of the rules that already existed — one their build pipeline could consume directly, instead of one they had to re-key out of a PDF.
01
1
Corporate Style Guide (PDF) — brand source of truth
02
5
independent translations of it in product code
03
3
platforms — web, iOS, Android
04
140+
screens audited in discovery
02
Discovery
I started where the dissonance was loudest: in the components people argued about. A surface audit catalogued every variant of every primitive across the products — and then, for each variant, traced it back to the page of the Corporate Style Guide it was attempting to honor.
What the audit revealed
- —Eleven distinct button treatments — most of them sincere attempts to render the same Style Guide page, slightly differently.
- —Six ways to communicate error states — all referencing the same corporate red, none of them screen-reader compatible.
- —Design tokens existed informally inside three Figma files, each a hand-converted snapshot of the PDF, each drifting on its own clock.
- —Engineering had stopped trusting design specs and was inventing components inline — because a PDF couldn't be imported into their build pipeline.
“The brand decisions were already made. They just weren't available in a form anyone could ship.”
I interviewed designers, front-end engineers, and product managers across the five teams. The theme was unanimous: people weren't asking for new rules. They were asking for the existing rules to arrive in a format their tools could actually consume.
03
System architecture
The Design System wasn't going to replace the Corporate Style Guide. The PDF remained the brand's source of truth — owned by the brand team, governing every customer touchpoint the engineering org didn't own. The Design System was its development-facing derivative: the same decisions, expressed as code.
Two artifacts, one source
Corporate Style Guide (PDF) — for the organization at large: brand, marketing, vendors, partners. Design System (tokens + components + docs) — for product engineering. The latter derives from the former; the former never needed to change.
Three layers, each with a clear contract:
- 01Tokens — color, type, spacing, radius, and motion, derived directly from the Style Guide and expressed as a single semantic vocabulary. Platform-agnostic. Each platform consumed them through its own build pipeline; the PDF was no longer the integration point.
- 02Components — accessibility-tested, composable, theme-aware. Documented with usage rules, anti-patterns, and the rationale behind each decision.
- 03Patterns — opinionated assemblies that solved recurring problems (filtering, bulk actions, empty states, progressive disclosure).
Every component shipped with three things: a Figma library entry, a coded implementation (React on web, native on iOS/Android), and a documentation page that explained *when not* to use it. The third was the most important — and the one the PDF could never have provided.
04
Rollout & contribution model
A design system that ships and dies is a familiar story. To avoid it, I treated rollout as a product launch — staged, instrumented, and explicitly co-owned with the teams adopting it.
The model
- —Each product team named a system champion — a designer or engineer accountable for adoption and feedback.
- —Contributions flowed through a lightweight RFC process. Anyone could propose; a rotating council reviewed.
- —Breaking changes were rare, telegraphed, and accompanied by a migration codemod where possible.
- —Adoption was tracked the same way feature adoption was tracked — dashboards, not goodwill.
“The contribution model was the design system. The components were just its current state.”
05
Outcomes
01
30–35%
reduction in front-end development time
02
11 → 3
button variants across the surface
03
100%
WCAG 2.1 AA on shipped components
04
40+
contributions in the first year
The numbers mattered. What mattered more was that designers and engineers stopped arguing about primitives and started arguing about product. That is what a working system buys you.
Three years on, the system is still maintained by the same teams that built it — not by the original author. That is the only outcome that ever really counts.
