Every design team reaches a point where their component library is theoretically complete, yet engineers are still writing one-off styles and designers are duplicating components. The system exists. Nobody uses it. Why?
Adoption is a product problem
A design system is a product whose users are designers and engineers. Like any product, it fails if it doesn't solve real problems for real users. The most common mistake teams make is building a system in isolation and then announcing it. By then, the teams it's meant to serve have already built their own solutions.
The documentation trap
Most design system documentation answers the question "what does this component look like?" The more useful question is "when should I use this component, and when should I not?" Usage guidelines, anti-patterns, and decision trees are far more valuable than pixel-perfect Figma specs that duplicate what's already visible.
Governance models that work
Three models are common:
- Centralised: A dedicated team owns and publishes the system. High consistency, slow velocity.
- Federated: Each product team contributes. High velocity, risk of fragmentation.
- Hybrid: A small core team maintains foundations (tokens, base components); product teams own page-level patterns.
The hybrid model works best for organisations above ~20 designers. It balances stability with the flexibility product teams need.
