Northwind · Platform · 2023
A design system four teams actually used
Adoption, not components, was the hard part
- Role
- Design lead, systems
- Team
- 1 designer, 2 engineers, part-time
- Duration
- 2 quarters
- Year
- 2023
The company's third attempt at a design system. The first two failed the same way: beautiful libraries nobody imported.
Why the first two failed
Both previous attempts started with a Figma library and a launch email. Neither started with a team that needed something.
I read every PR that touched a shared component for a month. Product teams weren't ignoring the system — they were forking it, quietly, because it never fit their edge cases.
Shipping to one team first
We picked the team shipping fastest and built only what they needed that sprint. Eleven components. No documentation site.
When a second team asked for the same button, we made it a real API. The system grew from demand instead of speculation.
- Every component shipped in code and Figma the same week
- Contribution took a PR, not a proposal
- We tracked forks as a bug, not a violation
The governance question
Systems die from either too much process or none. We landed on one rule: anyone can add, but adding means owning the migration.
That single constraint kept the surface small without me being a bottleneck.
A design system isn't a library. It's a set of agreements that happens to ship as code.
What changed
- component adoption across 4 teams
- 91%
- time from design handoff to merged PR
- −40%
- button implementations in the codebase
- 3 → 1
component adoption across 4 teams
time from design handoff to merged PR
button implementations in the codebase
What I’d do differently
I should have measured adoption from day one. We spent a month arguing from anecdote because we hadn't instrumented anything.