Enterprise
Design System.
Tokens, primitives, and a component library shipped to engineering. Documentation site, governance model, and an adoption playbook — the parts most design systems forget.
- Discipline
- Design system · Tokens
- Output
- Tokens · library · docs site
- Adoption
- Org-wide
- Stack
- Style Dictionary · React
• 01 · The brief
The brief.
The brief: build a design system that survives. Most enterprise systems ship beautiful Figma libraries that don't survive contact with engineering, plus a docs site nobody updates. The result is drift — six months in, the system is a memory.
• 02 · Context
Context.
The organisation has multiple product teams, several front-end stacks, and a design org that's grown faster than its tooling. Previous attempts at a system stalled at the “beautiful Figma” stage and were quietly forked by every team that needed to ship.
• 03 · The approach
The approach.
We treat a design system as three artefacts, each with its own owner and update cadence: tokens (single source of truth, generated from one file), primitives (the small set of building blocks engineering composes), and components (the assembled, opinionated pieces). The documentation site is generated from the same source — if the source diverges, the docs visibly break.
• 04 · What we shipped
What we shipped.
- Token system — colour, type, space, motion, all generated.
- Primitive library — box, stack, cluster, text, icon.
- Component library — opinionated pieces, owned by design.
- Docs site — auto-generated, with live examples and copyable code.
- Governance — a one-page RFC process for changes.
- Adoption playbook — how to migrate a team in two sprints.
• 05 · Outcome
What changed.
The system survives because it has fewer moving parts than the systems it replaces. Engineering can read the tokens. Designers can read the components. The docs are generated, not written. The RFC process is short enough that people use it.
