Every design system launches with enthusiasm: a Figma library, a component package, a naming convention everyone promises to respect. Eighteen months later, most are quietly abandoned — the package pinned to an old version, the Figma file diverging from production, new components built ad hoc because "the system did not cover this case."
Having built and rescued a dozen of these, we have stopped believing failure is a tooling problem. It is a governance problem wearing a tooling costume.
Habit one: the system has an owner with a roadmap
Systems survive when exactly one person is accountable for them — not a committee, not "the frontend guild." That owner runs the system like a product: an intake process for requests, a public roadmap, release notes people actually read.
The moment component decisions happen in five different pull requests with five different reviewers, entropy wins. Every surviving system we know routes changes through one door.
Habit two: tokens are the contract, not the components
Teams obsess over component APIs and neglect the token layer. But components churn — tokens endure. Color, spacing, typography and motion tokens are the true interface between design and engineering.
When tokens are the contract, a redesign is a token release, not a rewrite. We have re-skinned entire products in a week because the token layer was disciplined.
Habit three: deletion is a feature
Surviving systems delete components as eagerly as they add them. Every variant kept "just in case" is a maintenance tax and a decision burden for every future consumer.
Our rule: any component unused for two release cycles gets a deprecation notice, then removal. Systems stay credible by staying small.
None of this is glamorous. That is rather the point — design systems are infrastructure, and infrastructure earns trust by being boring, owned and small.