A system your team keeps using after we leave.

The library was built.
Nobody used it.

Colour, type, space, radius and elevation as a three-tier structure — primitive, semantic, component — so a rebrand is a token change rather than a redraw.

Every component with every state and variant, built in Figma with variables and in code as the same contract, not two interpretations of one sketch.

Tokens exported to your stack automatically, so a design change reaches production without anyone retyping a hex value.

When to use each component, when not to, and what it does at every breakpoint. Written short, kept beside the component rather than in a wiki.

Who can add, who reviews, how a variant gets promoted from one team to everyone. This is what decides whether the system is alive in a year.

Which screens migrate first, how the old and new coexist, and how you measure how much of the product is actually on the system.

Teams shipping in parallel have each solved the same component differently, and the product now looks like three products.

Changing colour and type across an unsystematised product is a manual sweep of hundreds of files. With tokens it is an afternoon.

Nothing is reusable, so each feature starts from scratch. The velocity cost is invisible until someone measures it.

Contrast and focus states are decided per screen. Fixing it once at component level is the only version that holds.

Retrofitting a second theme without semantic tokens means touching every component by hand.

Half of every review is spacing and colour corrections that a system would have made impossible to get wrong.

Forty-one greys,found in an afternoon.

Every value in the product, counted

Codebase and design files scanned for every colour, size, spacing and radius in use, clustered by similarity. The result is a factual inventory rather than a sample.

Where the system is being bypassed

Continuous checks on which screens use tokens and which hard-code values, so adoption is a number on a dashboard rather than an assumption.

First drafts of the boring pages

Prop tables, usage notes and change logs drafted from the component source, then edited by a designer. Documentation debt is why systems stop being trusted.

It counts the greys.A designer picks the five.

Clustering finds what exists. Deciding what the scale should be is a judgement about hierarchy and brand, and no model has a defensible opinion about that.

When a system
costs more than it saves

A single person shipping one surface is already consistent. A documented system adds process overhead to a problem that does not exist yet.

Systematising an interface that is mid-pivot fixes decisions you are about to reverse. Wait until the shape settles.

A system without a named maintainer decays into a stale library within two quarters, and teams route around it. The owner matters more than the components.

System work pays back over quarters, not sprints. If there is a hard near-term deadline, ship the screens and systematise afterwards.

Share of production screens built from system components rather than one-off code. The single number this work exists to move.

Proportion of colour, spacing and type values coming from tokens versus hard-coded. Tracks whether the system is holding or leaking.

How long a new screen takes now against the pre-system baseline. This is where the investment repays itself.

Components added or extended by your team rather than by us. A system nobody contributes to is already dying.

Contrast, focus and keyboard behaviour at component level, so every screen inherits compliance rather than earning it individually.

Changes caught by automated review before release. Rising numbers usually mean the system is being used more, not less carefully.

What feeds a system,
and what it feeds