Design systems that scale (and the ones that do not)

Every company we meet has, at some point, tried to build a design system. Most of them have a graveyard of half-finished ones to prove it. The difference between a system that compounds in value and one that becomes shelfware is almost never the quality of the components. It is everything around them.

A design system is a product

The most important mindset shift: your design system has users — the engineers and designers building on top of it. That means it needs a roadmap, release notes, documentation, a support channel and someone accountable for it. A component library dumped into a repo with no owner is not a system; it is a liability with nice spacing.

Tokens are the foundation

Underneath every durable system is a layer of design tokens — named values for colour, spacing, typography and elevation. Components reference tokens, never raw values. Get this right and a single change — a new brand colour, a dark theme, a density setting — cascades through the entire product automatically.

We build tokens as semantic layers: a raw palette (indigo-600), mapped to intent (--primary), consumed by components. Designers change the map; engineers never touch a hex code.

Adoption is the only metric

You can measure a design system a hundred ways, but only one matters: what percentage of the product is actually built with it? A pristine library used by nobody is a failure. A slightly messy one used everywhere is a triumph.

This reframes the work. Instead of polishing the 120th component, you spend your time removing adoption friction — better docs, codemods that migrate old code, and being genuinely helpful when a team hits a gap.

Governance keeps it alive

Systems decay. Without governance — a lightweight process for proposing changes, deprecating patterns and reviewing contributions — entropy wins within a quarter. The best governance is not a committee; it is a clear contribution path and one or two people who care enough to keep the bar high.

Build it as a product, ground it in tokens, chase adoption over perfection, and govern it like it matters. Do that and the system stops being a cost centre and starts being the reason your team ships three times faster.