A design system is a governance problem

I’ve watched a few design systems die, and none of them died because the buttons were badly drawn.

There’s a pattern you start to recognise. A team needs a component that doesn’t exist. They can’t get it added before their deadline, so they build their own and ship it. Six months later there are four versions of the same thing in production and the system is one option among several. Sometimes it’s simpler than that: the system was one person, and that person left. Or the process around it was so tight that using it took longer than ignoring it, so people ignored it and never came back.

In every one of these cases the components themselves were fine. What failed was organisational. And you could see it from day one if you were looking at the right layer.

What happens when the system doesn’t have it?

A component library is a thing you can point at. A design system is an agreement between people about how interface decisions get made. The library is the visible half, so it gets all the attention.

The hard half is one question. When a product team needs something the system doesn’t provide, what happens next?

There are only a few possible answers, and whichever one is true in practice is the one that decides how the system ends up.

If the answer is “they wait, and nobody knows how long”, teams will route around the system. They have deadlines and the system doesn’t.

If the answer is “they build their own and it stays theirs forever”, you’re maintaining a library while fragmentation becomes the normal state.

If the answer is “they build their own from system primitives, in the open, and the good ones get promoted through a path everyone knows”, that’s the only version I’ve seen survive contact with real teams.

Most organisations never answer this question out loud. They answer it by accident, through how they react the first few times somebody asks. That accidental answer becomes the culture, and culture is expensive to change later. Which answer is true where you work? It’s worth finding out before the first team hits the gap.

Contributing has to be easier than working around it

Every designer and engineer who runs into a missing component does a quick private calculation. What does it cost me to get this into the system, compared with solving it locally right now?

Now imagine contributing means a written proposal, a review meeting, waiting for the next cycle, documentation requirements, and rounds of feedback from people with strong opinions and no deadline. The local workaround takes an afternoon. How do you expect that calculation to end? People can love the system in principle and the incentive still points the other way, every time.

Making contribution cheap is mostly about removing coordination, and it doesn’t mean lowering standards. Write down what belongs in the system and what doesn’t, so half the debates never start. Name one person who can approve, instead of a committee that has to find a slot. Set a maximum wait and keep to it. Generate the documentation from the code, because documentation written separately is the first thing to rot.

The systems I’ve seen work all kept a fast path for the common case and saved the heavy process for changes that were genuinely structural. The ones that died applied the heavy process to everything, in the name of quality. I understand the instinct, but what it gets you is workarounds.

Get the tokens right first

If I could only get one layer right, I’d take tokens over components without thinking about it.

Components are opinions about specific problems, and specific problems keep changing. Tokens are the vocabulary underneath: spacing, type scale, colour roles, radii, elevation, motion timing. They outlast any component, and they constrain everything built on top of them.

Within tokens there’s one distinction that carries most of the weight. A token can name a value or it can name a purpose. yellow-400 tells you what the colour is. surface-warning tells you what it’s for. When the brand changes, the first one needs renaming and the second one just keeps working. Even better, the second one shows up misuse. If somebody puts surface-warning on a decorative panel, you can see that something odd is going on. With yellow-400 the same mistake sails through review.

Purpose tokens are harder to define, because they force the argument about meaning to happen up front. I think that’s a good thing. The argument is going to happen either way, either once in the token layer or again and again in every component review for the next three years.

Keep the set small. A six step scale people use correctly beats a twenty step scale people pick from at random. Every extra option is a decision you’ve handed to whoever was in the biggest hurry.

Measure adoption properly

Teams like to report adoption as the number of products that say they use the system. That number tells you almost nothing. A product can import the library and still build most of its screens by hand.

The number worth having is the share of the rendered interface that actually comes from system components. Getting it takes a decision, some tooling, and a bit of courage, because the result is usually humbling. I’ve seen products that considered themselves fully adopted running well under half.

The gap between the claimed number and the measured one is the best diagnostic you’ll get. The components people bypass are the components that don’t fit, and that list is your real roadmap. It’s more honest than asking teams what they need, too. People find it hard to describe a missing abstraction, but they’re very good at building around one.

What consistency is for

Mature systems tend to fail from the other side.

Consistency earns its keep in two ways. People carry what they learned in one part of a product over to another, and teams stop re-deciding solved problems. When enforcing it starts blocking teams from solving real user problems, the system has started serving its own metrics instead.

Some divergence is simply correct. A data heavy operational tool needs a different density from a marketing page. A first run experience for a newcomer needs a different pace from a screen an expert lives in all day. A system that can’t express those differences will be abandoned by exactly the teams that needed it most, and I’d say it deserves that.

The stance I’d recommend: the system owns the vocabulary and the defaults, teams own their specific problems. When a team needs to deviate, help them do it in a way that’s visible and reversible instead of forbidding it. A documented deviation is a candidate for the next system feature. A forbidden one turns into an undocumented local hack, which is the same divergence with all the information stripped out. Would you rather know about it or not?

Somebody has to own it

The last part is the one organisations most like to leave unsaid. The system needs an owner with time allocated to it. A volunteer activity on top of a full product role doesn’t count.

A spare-time system works for about a year. That’s roughly how long the founding enthusiasm lasts, and roughly how long the first wave of components stays true to reality. After that it’s either continuous maintenance or decay, because the products around the system never stop moving.

If the organisation won’t fund the maintenance, it’s better to find that out early and scale the ambition down. A deliberately small system that’s genuinely maintained beats an ambitious one that’s rotting. And a rotting system is worse than no system at all, because it still carries authority. People keep following it, straight into decisions it’s too out of date to make well. I’ve watched that happen more than once.