What we've learned shipping design systems for fast-moving teams — the patterns that work, the traps that don't, and the metrics that matter.
After 50+ system launches, one truth holds: a design system is an organization, not a Figma file. The tokens and components are the easy part. The hard part is building the social and technical scaffolding that keeps a system alive when the team that made it moves on.
Tokens before components
Every system that failed us started with components. Every system that survived started with tokens — color, space, type, motion — encoded once and consumed everywhere. Tokens are the contract between design and engineering. Get them right and components almost write themselves; skip them and you'll be reconciling hex codes for years.
Contribution is the killer feature
A system nobody can contribute to is a system that will die. We design contribution flows before we design anything else: how a team proposes a component, how it gets reviewed, how it ships. The best systems we've built feel less like a library and more like a product with users who are also its makers.
Measure adoption, not elegance
A gorgeous system nobody uses is a failure. We track adoption religiously: what percentage of new screens are built from system primitives, how often teams fork instead of contribute, where the drift happens. Adoption metrics surface the real problems — usually governance and docs, never aesthetics.
Version like a product, not a library
Semantic versioning is table stakes. The teams that thrive treat the system changelog like a product release notes — with migration guides, deprecation windows, and a human voice. Your system's biggest fans are the engineers who rely on it; treat them like customers.