My first week at Meridian, I opened the design system documentation and found four hundred components. My second week, I learned that about a third of new screens used it. My third week, I stopped being surprised.
The library was not the problem. The components were good, the documentation was thorough, and someone had clearly cared enough to write the empty-state guidelines. The problem was that nobody had agreed on what the library was for. Every team had a different answer, and all of them were busy shipping.
The library is the artifact; the contract is the product
A design system is not a pile of components. It is a standing agreement among designers and engineers about which decisions are policy, which are shared defaults, and which are local. The components are just where the agreement becomes visible.
That distinction sounds academic until you watch a team argue about a button. One side says the system owns the button. The other says the system owns the button until the flow needs something the button cannot do, which turns out to be most flows. Underneath the argument is a contract question: who has the authority to decide, and how do we handle the case where the answer is “not you, not now”?
Mature systems answer that question explicitly. Immature systems answer it repeatedly, in every sprint, with slightly different outcomes.
What the contract contains
A useful contract has more clauses than a component library, and almost all of them are prose.
Naming. We agree to call it a chip. Not a pill, not a tag, not a badge — a chip. This is not pedantry; shared language is the cheapest interoperability we will ever buy. When the name is contested, the component is contested too, and the argument will reappear in every review.
Ownership. Who can change a token, who reviews a component change, and what counts as breaking are written down. A system where the platform team can silently rename a prop is not a system; it is a dependency with a friendly website.
Versioning. Numbers are promises. A patch fixes, a minor adds, a major breaks. Most teams do this for the API and forget to do it for behavior — and behavior is what designers actually feel.
The right to deviate. There must be a documented path for a team to do something the system does not support. A written exception, reviewed, is a healthy system breathing. A silent fork is the same team building a second system in the dark. The difference between the two is entirely social.
Maintenance, not launch. The moment after a design system ships is the moment the hard part begins. Deprecations need notices, migrations need dates, and the docs need an owner with time on the calendar.
A design system succeeds not when its components are used, but when a new engineer can make a good screen without asking anyone.
Where they actually fail
Design systems rarely fail because the components are wrong. They fail from social debt.
The first kind is review by committee: eight people, four opinions about radius, six weeks per PR. The system becomes slower than building a local copy, and the local copy is rational.
The second is the absence of office hours. If the only way to ask a question is a pull request, people stop asking and start forking.
The third, and the one I see most, is “just this once.” Every system I have watched decay decayed one exception at a time, each exception individually reasonable, none of them documented. The system did not die of a bad decision; it died of a thousand undiscussed ones.
The fix is unglamorous: a weekly half hour where anyone can bring a problem, a written exception log that is opened at those meetings, and a rule that the person who ships a deviation owns the note that explains it.
What to measure
The metrics that matter are social ones. How long does it take a new team to ship a consistent screen? What fraction of UI work uses system components, and is that fraction honest? How many exceptions are we granting per month, and are they converging on a missing component?
If exceptions keep clustering around the same missing thing, the system is not enforcing a standard; it is filing a feature request on your behalf. That is information, not failure.
Contracts get renegotiated
The word contract makes systems sound rigid. The opposite is true. A contract is simply a conversation that has been written down so that it can be reopened, rather than repeated from scratch every sprint.
Write the why in the docs. Retire deprecated components loudly, with dates and a migration guide. Schedule the argument instead of waiting for it to schedule itself. And treat the library as what it is: evidence of the agreement, not the agreement itself.
The best design system I have worked with had fewer components than the worst one. It also had a monthly meeting, a very boring changelog, and a shared understanding that the point was never the buttons.