A design system is a promise

Clients increasingly ask for a design system at the start of a product project, often before anyone knows what the product will look like. We understand why. A system promises speed: build a button once and every team uses it. But a design system is not a file, and it is not mainly a set of components. It is a promise to every designer and engineer who relies on it that those components will be maintained, documented and still working next year. A library that breaks that promise is worse than none, because teams stop trusting it and quietly start building their own again.

Start smaller than feels right

The first version of a system should be almost embarrassingly small. On a recent app we launched with twenty-two components: type styles, colour tokens, spacing, buttons, inputs, a card, a list row, a sheet and a handful of others. The product team had asked for sixty. We agreed to add the rest only when a second screen needed them, a rule we now use everywhere: nothing becomes a component until it has been used twice. A year later, more than half of the original sixty still had not been.

Write the promise down

Before we draw anything, we agree a one-page charter with the client. It is short enough to pin above a desk, and it makes the commitments explicit for both sides.

• Who owns the system, by name, and how much time it gets. Our minimum is one designer and one engineer, a day a week each.
• How changes are proposed, reviewed and released, and how long a team waits for an answer. Ours is five working days.
• How breaking changes are announced: in writing, one full release ahead, with a note on exactly what to do.
• What the system will not cover. Campaign pages, one-off experiments and anything still being tested live outside it.

Every component you publish is a promise to the team that uses it. Publish fewer, and keep them.

Tokens before components

The most durable part of any system is the least visible one: the tokens. Colour, type, spacing, radius and motion, each named for its purpose rather than its value, so a button uses action-primary rather than blue-500. When a brand changes, as brands do, the tokens change and the components follow without anyone redrawing them. We build tokens in the design tool and in code at the same time, and hold a fifteen-minute check every fortnight to make sure the two have not drifted apart. It is tedious work, and it is the main reason a system is still trusted in its third year.

Checking the promise is kept

After handover we ask clients to track three numbers each quarter. How many screens in production use system components rather than local copies, which should rise steadily. How long a change request waits for a decision. And how many detached or overridden components turn up in the design files, which is the most honest measure of whether designers trust what they have been given. When that third number climbs, the promise is being broken somewhere, and in our experience it is rarely a design problem. It is usually that nobody’s job description says they look after the system.