The design system audit worth running before you build one

Why design systems get abandoned

A design system is a product with users, and like any product it fails when it is harder to use than the alternative. The alternative is always available: a designer can draw a new button in ninety seconds and an engineer can write one in five minutes.

So the question that predicts survival is not “is the system well designed”. It is “is the system the path of least resistance”.

Start with an honest inventory

Before proposing anything, count what exists. A mid-size product estate will typically have many distinct button treatments, several input styles and more than one type scale in active production use.

The count is not for shaming anyone. It establishes the scale of the consolidation and reveals why the variants exist. A surprising proportion turn out to be legitimate — a genuine need the system did not serve — and those become requirements rather than violations.

Tag every variant as duplicate, legitimate variant or legacy. The ratio tells you whether you are looking at a governance problem or a coverage problem, and those need different remedies.

Governance is the hard part

The questions that predict survival are largely organisational:

• Who may add a component, and by what process? If the answer is “raise a ticket with a team that has other priorities”, teams will fork instead.
• Who maintains it, and is that time protected? A system maintained in slack capacity decays exactly when the roadmap gets busy.
• How does a breaking change reach consumers? Versioning and migration guidance need to exist before the first breaking change.
• What happens when a team needs something the system does not have, this week?

That last question is answered badly most often. The honest answer is an escape hatch: a documented way to build outside the system, clearly marked, with a route back in. Systems without one do not prevent divergence, they just make it invisible.

Tokens before components, adoption before count

The highest-leverage artefact is the token layer — colour, spacing, type, radius, elevation and motion, defined once and referenced everywhere. Name tokens by role rather than by value, or the first theme change will require renaming everything. Keep the primitive set small: a scale of ten spacing values people actually use beats a scale of thirty they round off.

Finally, measure the right thing. Teams building design systems report component count, which measures supply rather than demand. Measure instead the proportion of production screens built from system components, the number of one-off components created per sprint, and the time from a team needing something to having it.

A system with thirty components at high adoption is healthy. A system with two hundred at low adoption is a museum.