How we ship a design system
Every product team eventually reaches the same moment. Screens start diverging, buttons get five different heights, and every new page reopens a debate that should have been settled once. The fix is not another Figma library. It is a shared way of shipping.
What we call the system
A design system is not a component library. Component libraries are the deliverable. The system itself is the set of decisions about how a product looks and behaves, made once, held to, and updated on purpose. The library is where those decisions get expressed.
We keep the system in three layers. The first layer is tokens: colour, type, spacing, radius, shadow. The second is components: the pieces built out of those tokens. The third is patterns: how those components combine to solve real jobs.
The team that owns it
One designer and one engineer, half time each. That is enough for a system serving forty people. More than that and you start optimising for the team rather than the product.
Their job is not to make every component. Their job is to keep the system honest. They review PRs, kill duplicates, and answer the questions that would otherwise become quiet drift.
How we know it is working
Three signals we watch. Designers stop asking each other what colour to use. Engineers stop wrapping our components in one-off styles. And the design review meeting shrinks from an hour to twenty minutes.
- Every new screen ships with system components only
- Token changes propagate to every product surface within a day
- Newcomers get to their first shipped screen in under a week