After a decade of design-systems thinking, the same three failure modes keep showing up. They aren't tooling problems. They are organizational ones.
We have audited or built design systems for clients off and on for about a decade now, and the same handful of failure modes keep showing up. They are not tooling problems. The tooling has gotten genuinely good. They are organizational problems, and they tend to wear technical clothing.
The thing worth saying first is that a design system is not a component library. The library is the artifact. The system is the agreement between the people who make the library and the people who use it. Most of the failed systems we have walked into have a working library and a broken agreement.
Three patterns we see over and over
The first pattern is a design-systems team that owns the artifact but does not own the contract for how it changes. Components ship. Apps adopt them and pin to a specific version. New versions land in the library, and nobody upgrades. Six months later, the design system is a museum: the components exist, the apps are running older versions of them, and no one is sure anymore which is canonical.
The second pattern is a system that lives as "principles" rather than "decisions." Principles are easy to agree with and impossible to enforce. "We care about accessibility" is a principle. "We do not ship a button without a focus state" is a decision. The decision can be checked at PR time. The principle ends up as a slide in a deck.
The third pattern is a system funded as a project rather than as a function. Project funding produces a launch and a press release. Then the team disperses to other priorities, and the system enters a slow decay that no one is staffed to fight. The components are still there. The trust in them is not. The next product team that gets a deadline quietly rebuilds what they need from scratch.
What the systems that survive have in common
The systems that hold up past three years share two pretty boring things. They have a written contract for what counts as a breaking change, and they have a small permanent team whose job is to keep that contract honest.
The contract creates predictability for the product teams that depend on the library. The team makes sure the contract is real and not aspirational. Everything else — the tokens, the docs, the Figma plugins, the lint rules — is downstream of those two. Most of the time, when we are asked to fix a broken design system, those are the two things that are missing.
A short note on AI-generated UI
We get asked about AI generators for component code on almost every design-systems engagement now. The honest answer is that the generator doesn't change the question. A strong design system gets faster with a good generator. A weak one gets noisier. The discipline underneath is still what determines the outcome.