Most design systems I am asked to rescue have the same problem. They are beautiful in Figma and ignored in code. The library has 300 components and the product uses 40 of them, each slightly wrong.

The cause is simple. The system was built for the people who made it. A design system has one customer, and it is the engineer who needs to ship a screen by Friday without asking anyone a question.

Start with a count

At Ledgerloop I began with an audit, not a design. We counted 61 greys, 14 button variants and 9 kinds of modal. Nobody had chosen any of that. It had simply grown.

Nobody chose 61 greys. They grew, one reasonable decision at a time.

The numbers did what opinions could not. Within a week, four teams agreed on a single palette, because the alternative was written on the wall in front of them.

Ship tokens before components

Tokens are small, boring and easy to adopt. They reached production in week four, which meant the system was real before anyone could argue about it. Components followed in an order set by use, not by elegance.

• Colour, type and spacing tokens first, wired into the existing code.

• The ten most used components next, each with a short usage note.

• Rare components last, and only if two teams ask for them.

• A named owner and a weekly half hour for requests.

The audit board at the end of week one. Every dot is a grey somebody shipped.

The usage notes mattered more than I expected. Each one answers three questions: when to use this, when not to, and what to use instead. Engineers read them because they are short.

Ledgerloop now has 212 components in one library, and new screens come together about 40% faster. The number I like best is not measured. The team’s chat no longer contains the question where does this live.