Design systems that earn their keep

Somewhere out there is a beautiful design system that took eight months to build, covers every conceivable component in four themes and two densities, has documentation that would shame a national archive - and is used, in production, by almost nobody. Its team maintains it the way one maintains a museum: with reverence, on a schedule, for visitors who never quite arrive. I've watched this happen more than once, from close enough to feel implicated, and this piece is about the habits we've adopted so it doesn't happen to the systems we build.

The uncomfortable diagnosis is that museum systems fail precisely because they were treated as products in their own right. The problem begins the moment a system develops a life independent of the thing it serves: its own speculative roadmap, its own definitions of progress, and its own work that can be completed in full without improving a single real screen. A design system is infrastructure, and infrastructure is judged by the traffic it carries.

So this piece isn't an argument about the correct way to design or build a system, and it isn't a claim that ours is the right shape. It's a narrower point about where a system lives. It should emerge from the product work, move with it, and stay embedded in it, rather than sitting alongside as a separate artefact that has to be finished before meaningful design can begin.

In practice that means we don't pause product work to maintain the system, because the system is maintained through the product work. When a heading scale changes in a review, it changes everywhere. When a component fails on a real page, the component evolves with the page. A review is never only checking the screen in front of it; it's continuously testing and refining the shared rules behind that screen, which is the only way those rules stay true.

Start from shipped screens, not abstract atoms

The museum path usually starts at the bottom of the atomic-design diagram: months spent perfecting buttons, inputs and tokens in a vacuum, on the theory that pages will assemble themselves once the atoms are right. The theory is tidy and the vacuum is the problem - components designed without the pressure of a real screen are always subtly wrong, and the corrections arrive precisely when the team has run out of patience for the system. We don't design a library in isolation and apply it to pages later. We design the page and the system at the same time, because a screen gives the rules something real to solve and the shared rules keep the next screen from starting at zero, so each review improves both.

We build in the opposite direction: ship real screens first, then harvest. The system grows by extraction, which is to say repeated visual and behavioural decisions become system rules - when a pattern has proven itself on two or three shipped surfaces, it gets promoted into the library with its variants and rules attached, which means every component in the system has already survived production at least twice, and none of them are speculative. The library stays small, slightly scruffy at the edges, and completely trustworthy, which is the correct trade in every case we've seen.

Every component in the system should have survived production twice before it's allowed in.

One source of truth, and it's the code

A design system that lives in a design tool and gets re-implemented in code isn't one system, it's two systems with a diplomatic relationship, and the drift between them is where the value leaks. Our rule is that the code is canonical: tokens are defined once in a form both Figma and the codebase consume, components in the design file mirror the built ones (names, props, variants) rather than aspiring past them, and when the two disagree, the shipped one wins the argument by default.

This sounds like a technical preference and is actually a political one, because it changes what 'done' means. A component isn't done when it's approved in a review; it's done when it renders in production and its accessibility stays intact - and holding that line is what keeps the system a delivery tool rather than a gallery of intentions.

The deeper reason to insist on one source is that the alternative quietly splits a system in two: a static one that represents the design, and a living one that happens through it. Those aren't two artefacts to keep in sync, they're the same thing seen from different rooms, and every hour spent reconciling them is an hour the system cost you rather than saved you.

Govern lightly, measure honestly

Museum systems tend to accrete governance - review boards, contribution ceremonies, RFC templates - until proposing a new button variant carries the administrative weight of a zoning application, at which point teams quietly stop proposing and start forking. We keep governance to a single working session: bring the shipped screen where the system didn't serve you, and either the system grows a variant or your screen adopts the existing one, decided that day by the people who do the work.

Measurement is the other half of staying honest, and the metric worth watching is adoption - what fraction of new screens ship on system components versus bespoke ones. Falling adoption is never solved by mandate (mandates produce malicious compliance and secret forks); it's a signal the system has drifted from what teams actually need, and the fix is harvesting whatever they're building bespoke. The system serves the screens. It's never the other way around.

Prune like you mean it

The least practised system skill is deletion. Components nobody has used in six months are inventory, not investment - they cost maintenance, they pad the documentation, and they make the library harder to trust ('is this the current card, or one of the other three?'). We audit usage quarterly and retire the dead weight without sentiment, because a fifty-component system where everything is current beats a two-hundred-component archive where a quarter of it is a trap.

None of this produces a system that photographs well at conferences, and that's rather the point. The systems that earn their keep are lean, slightly boring, ruthlessly current and invisible in the best way - present in every shipped screen, absent from every status meeting. If your system has a fan page and a backlog longer than the product's, it may be time to ask which one is serving which - and the answer is allowed to be uncomfortable.