The problem isn't the components. It's the governance model — and the assumption that a Figma library is the same thing as a system.
Every quarter, another team ships a design system. And every quarter, another team is quietly rebuilding their product from scratch six months later because the system broke under real conditions. The library exists. The tokens are named. The documentation is thorough. But nothing actually uses it.
I've watched this happen at enough companies now to be confident it isn't a tooling problem. Figma is fine. Storybook is fine. The token pipeline is fine. What fails is the chain of custody — the moment where a system stops being the designer's responsibility and starts being everyone's.
The real failure mode
Most design systems fail not at launch but at the second major feature. The first feature is built by the team that created the system — people who know where the edges are, what the components can and can't do, and how to file a ticket when something is missing. They navigate it fluently because they built the map.
The second feature is built by someone else. And that person doesn't have the map.
A system that only its creators can navigate is a library. A system is something that survives its creators moving on.
— Parallax Internal, 2024 retrospective
This isn't a documentation problem either. More documentation doesn't fix this. Better documentation might delay it slightly. The fix is structural — who owns the system changes, and you have to design for that transfer explicitly.
Governance, not components
Here's what most system documentation covers: component API, prop tables, usage guidelines, do/don't examples. Here's what it almost never covers: who decides when a component needs to change, how long that decision takes, what happens in the meantime, and who gets to make the emergency call at 11pm before a launch.
Key principle
Document the decision process as rigorously as you document the components. The process is what makes a system durable — not the Figma file.
Governance is the unsexy part of systems work. It doesn't generate Dribbble shots. Nobody puts "RFC process designer" on their portfolio. But it's the thing that determines whether your system is still coherent in eighteen months, or whether it's drifted into twelve slightly different interpretations of the same button.
What survives handoff
When we built the BMW design system, we had a specific constraint: the system had to be operable by engineers who had never met a designer on the team. This wasn't a theoretical future state — it was the reality of how BMW's internal teams were structured. Product teams in Munich didn't have embedded designers for routine feature work.
That constraint forced a useful question: what would a developer need to make a correct decision without asking anyone?
The answer, in practice: every token needs to encode its intent, not just its value. color-action-primary tells you something. blue-500 tells you nothing useful at the point of decision.
The token contract
Tokens are a contract. They say: "when you use this, you're using this in the context we intended." A token named color-feedback-error makes a promise — that this value will only appear in error states, and that if you see it somewhere else, something has gone wrong in the system, not in the design.
Most token architectures don't hold this contract. They use semantic names on the surface but allow the underlying values to be referenced directly in component code. The moment an engineer reaches past the token to the raw value — for any reason, usually a good one — the contract breaks, and the system can no longer guarantee visual consistency without a manual audit.
/* ❌ Breaks the contract */
.btn-error {
background: #D32F2F;
}
/* ✅ Maintains the contract */
.btn-error {
background: var(--color-feedback-error);
}This sounds obvious. It is obvious. And it still gets broken constantly, because the tooling doesn't enforce it. Linters help. Code review helps. But the real fix is making it easier to use the token correctly than to skip it.
Making it stick
Three things that have actually worked, in order of impact:
- A written RFC process for component changes — anyone can propose, specific people decide, decisions are logged. Takes fifteen minutes to set up, saves hours of drift per month.
- A "break glass" protocol for emergencies — explicit permission to bypass process under defined conditions, with a mandatory retrospective. This sounds dangerous but it's safer than having an unofficial workaround culture.
- Quarterly system reviews with product teams — not design team reviews of the system, but product teams reviewing how the system serves them. The gap between those two conversations is where most systems die.
The components are the easy part. Any competent team can build a button component. The hard part is building a system that product teams will still trust to make decisions six months after the design team has moved on to the next project.
If your design system feels stable but adoption is stalling, the instinct is usually to improve the documentation. Resist it. Ask instead: who owns a token change? How long does it take? What does a product engineer do when the component doesn't quite fit their use case? If those answers are unclear, that's where to work next.