Design systems that survive real teams
01A design system dies the day it's perfect
Most design systems fail not because they have too few components, but because they have too many and nobody trusts them. The team forks, builds shadow components, and within a quarter the system is a museum nobody visits.
The fix is boring but reliable: ship the 20 components that cover 90% of your screens, make them impossibly easy to import, and let the edge cases be code, not tokens.
“Complexity isn't the enemy of a design system. Momentum after launch is.”
02Governance is the actual product
Tokens for colour, spacing and type survive because they're cheap to adopt. Components survive because they're convenient. Anything beyond that needs a named owner and a change process that takes minutes, not meetings.
Write the rules down in the same place you commit code, so the 'system' is versioned, reviewed and commented on — just like the product itself.
03Measure adoption, not polish
Two numbers tell you if it's working: the ratio of screens built with system components, and the median time from request to merged component. If either one slips, fix the process before you add another component. Adoption is the metric a design system exists to move.
