#08 Every design system conversation I've had this year has the same gap.

Three different clients. Three different design system conversations. All stuck in exactly the same place.

Client one is a fintech company building their first system. They have been shipping product for four years with no shared library. The conversation is about where to start. Which components first, how many to include, how to handle versioning across a web app and two mobile platforms.

Client two is a SaaS company with an existing system that, by their own description, nobody uses. The conversation is about documentation. The system is comprehensive. The components are good. But teams are building their own versions of the same elements anyway, and nobody can explain clearly why.

Client three is a scale-up where each product team has built their own component library. The teams have diverged over three years. The conversation is about consolidation. Whose button is the button. Which team’s modal becomes the standard.

Three different problems. Three different conversations. All, when I looked closely, about the wrong thing.

A design system is not a UI library.

It is a decision-making protocol.

It exists to answer: who can make this change, when, and with what level of alignment required. The components are the artifact of that protocol. They are not the protocol itself.

This distinction matters enormously in practice. A team that has excellent components and no protocol will diverge. Different teams will make different decisions about when to use the component as specified versus when to deviate. Some teams will treat the system as law. Others will treat it as a suggestion. Over time, the system fragments not because the components were wrong but because there was never an agreement about when following them was mandatory.

This is exactly what happened to client three. The product teams were not rogue. They were rational. Each team had a set of requirements that the shared library did not cleanly accommodate. In the absence of a protocol that defined what to do in that situation, each team made its own call. Four years later, there are four libraries.

Client two’s “nobody uses it” problem is the most common design system failure mode I see.

The usual diagnosis: the documentation is insufficient. The components are not well explained. The examples do not cover enough cases. Teams do not know how to use the system.

This is almost always wrong.

The actual problem is that teams know how to use the system and have decided not to, because using it creates friction that not using it does not. They have a deadline. The system component does not do exactly what they need. The workaround is faster. They take the workaround.

In a world with a clear decision protocol, the team escalates: this component does not serve the need, here is what we need instead. The protocol answers: here is how to request a change, here is the timeline, here is how we decide whether to add it. The team either waits for the system or understands that what they are building is a one-off, not a contribution.

Without the protocol, the team makes the only rational decision available to them: they ship.

The documentation was never the problem. The documentation describes what to do when you use the system. It does not tell you what happens when the system does not serve the need. That is the gap.

Before asking which components to build, ask: what decisions does this system need to make clear?

Who can change a component? Under what circumstances? With whose sign-off?

When a product team’s requirement is not met by the existing library, what is the process?

When two teams want the same component to behave differently, who decides?

These are governance questions, not design questions. Most design teams treat them as secondary to the component work. They are not secondary. They are the reason the component work holds together or does not.

Client one is building a component library. They should be building a decision protocol first. The components will follow from the protocol in a way that makes the later governance conversations much shorter.

Client two has a documentation problem in the same way that a company with a broken HR process has an employee handbook problem. The document is fine. The underlying protocol is missing. More documentation will not create it.

Client three’s consolidation project will produce a single library that, without a protocol, will begin diverging again within a year. The consolidation is necessary. It is not sufficient.

The system fails when teams cannot answer the governance questions. The components are downstream of that.

×××