A design system is not a component library.

How it decays, and when

The trajectory is recognizable. A team produces a careful library: buttons, fields, cards, tables, documentation. Adoption starts well, because new screens benefit immediately.

Then a team needs a table with a frozen column. The standard component does not support it. They build a local variant, which is entirely reasonable. Six months later four table variants coexist, two of them fix the same accessibility defect in different ways, and nobody can say which one a new screen should use.

The system did not fail technically. It failed because no path existed for a legitimate need to travel back into it. An exception that cannot become an evolution of the system necessarily becomes a divergence from it.

The timing is worth noticing. Decay does not begin when the library is weak; it begins when the library is good enough to be adopted widely and the team that built it has moved on to something else. Wide adoption is precisely what generates the volume of edge cases a single delivery could never anticipate, which is why a successful launch and an unmanaged system produce the same outcome eighteen months later.

A system is a set of decisions first

The Nielsen Norman Group's work on the subject stresses exactly this distinction: a component library is a deliverable, while a design system is a practice that includes principles, documentation, governance and people who carry it.

The decisions in question are concrete and rarely written down: when do we use a modal rather than a page? how is a form error announced? what spacing values are allowed? what does the interface show during a long load? Those answers are worth more than the code implementing them, because they are what a new team needs in order to stay coherent.

A library answers "what should I use". A system answers "what do I do when nothing fits".

Tokens as the contract between design and code

Between mockups and implementation, the most mundane source of divergence remains the raw value: a colour typed by hand, a spacing rounded by eye, a font size nudged locally. Design tokens — named, shared, versioned values — remove that entire category of disagreement.

A W3C community group is working precisely on standardizing the exchange format for these tokens, so design tools and codebases can rely on one definition. The point is not the naming convention. The point is that changing a value stops being a negotiation between two teams and becomes a single, traceable update.

The minimum governance that actually suffices

Many organizations flinch at the word governance, picturing a committee. That is not what is needed. Four elements are enough, and their absence explains most of the failures worth studying.

None of this requires a large team. In most organizations the owner is one person with a few hours a week, a clear mandate to say no, and a documented way for anyone to propose a change and receive an answer within a predictable delay. The cost of that arrangement is modest. The cost of skipping it is four competing table variants.

The last one deserves particular attention, because it changes the conversation with leadership. The number of published components is an activity metric, not a value metric. The share of real screens built with the system tells you whether the investment is producing consistency — and makes it visible the moment adoption stops growing.

A useful design system therefore looks less like a catalogue than like a working agreement: a small number of owned decisions, a clear way to evolve them, and someone whose job it is. The components come afterwards, and they follow.