Design Systems Are Infrastructure.
Stop Treating Them Like Side Projects

The Failure Pattern

Every design system project starts with the same energy: the team is aligned, the tokens are clean, the component library is documented, and there’s a shared Figma workspace everyone agrees to treat as the source of truth. Then three months pass. The engineering team has moved on to shipping features. The Figma file has seventeen versions of the button component because someone made “a quick fix” and forgot to propagate it.

Governance is the Hard Part

We now treat design system governance as a prerequisite, not an afterthought. The tooling matters less than the process: who owns the system, how changes get proposed, how drift gets caught, and how new contributors get onboarded without breaking things. A design system without governance is just a documentation project waiting to become stale.

A design system is only as good as its adoption. And adoption requires governance, not just good components.

Tokens as the Canonical Source

Design tokens the named values for colour, spacing, typography, and elevation should be the canonical source of truth, not the Figma file. When tokens live in a version-controlled JSON or YAML file that feeds both the Figma library and the production CSS, drift becomes detectable. Any divergence between the token definition and the rendered UI is a bug that can be caught automatically.

Driving Adoption

A design system nobody uses is worthless regardless of how well-designed it is. Adoption requires that using the system is easier than not using it. That means IDE plugins, Figma integrations, code snippets, and clear migration guides. It also means being responsive to feedback: if a team is consistently working around a component, that’s a signal the component needs improving, not that the team is wrong.