A design system is a governance problem

I have watched several design systems die. None of them died because the buttons were badly drawn.

The deaths follow a pattern you start recognising. A team needs a component that does not exist. They cannot get it added within their deadline, so they build their own and ship it. Six months later four versions of the same thing live in production and the system has become one option among several. Sometimes the story is simpler: the system was one person, and the person left. Or the process around it was so tight that using the system took longer than ignoring it, so people ignored it and never came back.

In every one of these cases the components themselves were competent. The failure was organisational. And honestly, it was visible from day one to anyone looking at the right layer.

The real product is the process for changing it

A component library is an artefact. 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 does not provide, what happens next?

Only a few answers exist, and whichever one is true in practice decides the system’s fate.

If the answer is “they wait, for an unknown length of time”, teams will route around the system. They have deadlines. The system does not.

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

If the answer is “they build their own from system primitives, in the open, and the good ones get promoted through a defined path”, that is the only version I have seen survive contact with reality.

Most organisations never answer the question out loud. They answer it by accident, through how they respond the first few times somebody asks. The accidental answer then becomes the culture, and cultures are expensive to change.

Contribution has to beat the workaround

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

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

Making contribution cheap mostly means removing coordination, and it does not require lowering standards. Write down what belongs in the system and what does not, so half the debates never start. Name one person who can approve, instead of a committee that has to convene. Set a maximum wait and honour it. Generate documentation from the code, because documentation written separately is the first thing to rot.

The systems I saw work all kept a fast path for the common case and saved the heavyweight process for genuinely structural changes. The ones that died applied the heavyweight process to everything, in the name of quality. What they got for it was fragmentation.

Put the arguments in the token layer

If I could get only one layer right, I would take tokens over components without thinking.

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, one distinction 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 is for. When the brand changes, the first one needs renaming and the second one just keeps working. Even better, the second one exposes misuse. Somebody putting surface-warning on a decorative panel is visibly doing something strange. With yellow-400 the same mistake would sail through review.

Purpose tokens are harder to define, because they force the argument about meaning to happen up front, and that is a good thing. The argument will happen either way. Once, in the token layer, or over and over in every component review for the next three years.

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

Measure adoption first

Teams love 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. Measuring it takes a decision, some tooling, and a bit of courage, because the result is usually humbling. I have 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 will ever get. The components people bypass are the components that do not fit. That list is your real roadmap, and it is far more honest than asking teams what they need. People struggle to describe a missing abstraction, but they are very good at building around one.

What consistency is for

Mature systems tend to fail from the opposite side, so let me cover that too.

Consistency earns its keep in two ways: people carry knowledge from one part of a product 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.

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 daily. A system that cannot express those differences will get abandoned by exactly the teams that needed it most, and it will deserve it.

The stance I recommend: the system owns the vocabulary and the defaults, teams own their specific problems. When a team needs to deviate, help them do it legibly and reversibly 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 minus all the information.

Somebody has to own it

The last part is the one organisations most like to leave implicit. The system needs an owner with allocated time. A volunteer activity on top of a full product role does not count.

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

If the organisation will not fund the maintenance, better to find out early and scale the ambition down. A deliberately small system that is genuinely maintained beats an ambitious one that is quietly rotting. A rotting system is worse than no system at all, because it still carries authority. People keep following it, straight into decisions it is too outdated to make well.