I have spent the last few years building, breaking, and rebuilding design systems at Amazon, Western Union, and startups. And if there is one lesson that repeats like an error loop in the console, it is this:
I'm not talking about components, or tokens, or documentation. I'm talking about the real architecture: the one that defines how decisions are made, who has a voice, and what happens when the system collides with the reality of the product.
The problem wasn't in Figma. It was in the gap between the illusion of control of design and the real complexity of the system.
The same thing happens with Design Systems.
We create beautiful libraries, with variants for every use case... but we don't design the evolution protocol. We don't define how a conflict is resolved when a team needs something that the system doesn't contemplate. We don't establish who can break the rules... and when.
* Who decides that a token changes value?
* What happens when a team needs a pattern that contradicts the system?
How is a trade-off* between consistency and innovation resolved?
These are not design questions. They are governance questions. And most systems ignore them until it's too late.
In "[Haikus and Tokens](https://medium.com/@joanarbo/haikus-y-tokens-18c753ad2b13)", I wrote that "Design Tokens are design decisions that propagate through a system". But I never said the most uncomfortable part: poorly governed decisions propagate like bugs.
I also believed that good components were enough... until my system was ignored by 3 teams.
The moment a team, frustrated by bureaucracy or rigidity, decides to create its own version of the system.
Many see it as a betrayal. I see it as a signal.
Because if your system doesn't allow for decentralized evolution, it's not a system. It's a prison.
The true test is not whether everyone uses your library. It's whether, when someone breaks it, the system learns instead of punishing.
Think of it as a coordination infrastructure.
* Define clear, but not rigid rules.
Document not only what to do, but how to decide*.
* Make the change process visible, not just the result.
Celebrate forks* that add value, not just blind obedience.
They are the ones that disappear.
Not because they are invisible, but because their architecture is so solid that no one has to think about them. The team focuses on solving real problems, not fighting the system.
That is not achieved with more documentation.
Joan Arbó
UX Engineer @ Western Union | Ex-Amazon Alexa
Has your team already made a fork of your Design System? Don't punish them. Ask yourself: what feedback is it giving me?
P.S.: If your Design System has an "owner" but not a "disagreement protocol," it's already broken. Someone just needs to say it out loud.
We obsess over the surface and ignore the structure that supports it.
I'm not talking about components, or tokens, or documentation. I'm talking about the real architecture: the one that defines how decisions are made, who has a voice, and what happens when the system collides with the reality of the product.
The myth of the "perfect system"
In my article "[The Day Our Perfect Prototype Started Lying to Us](https://medium.com/@joanarbo/the-day-our-perfect-prototype-started-lying-to-us-61971324637e)", I told how an impeccable prototype — with fluid interactions, defined states, and apparently solid logic — fell apart in production because no one had questioned the underlying API.The problem wasn't in Figma. It was in the gap between the illusion of control of design and the real complexity of the system.
The same thing happens with Design Systems.
We create beautiful libraries, with variants for every use case... but we don't design the evolution protocol. We don't define how a conflict is resolved when a team needs something that the system doesn't contemplate. We don't establish who can break the rules... and when.
True scalability isn't technical. It's political.
A Design System doesn't scale by having more components. It scales by having clear mechanisms for decision making.* Who decides that a token changes value?
* What happens when a team needs a pattern that contradicts the system?
How is a trade-off* between consistency and innovation resolved?
These are not design questions. They are governance questions. And most systems ignore them until it's too late.
In "[Haikus and Tokens](https://medium.com/@joanarbo/haikus-y-tokens-18c753ad2b13)", I wrote that "Design Tokens are design decisions that propagate through a system". But I never said the most uncomfortable part: poorly governed decisions propagate like bugs.
I also believed that good components were enough... until my system was ignored by 3 teams.
The acid test: the first fork
Every healthy system survives its first fork.The moment a team, frustrated by bureaucracy or rigidity, decides to create its own version of the system.
Many see it as a betrayal. I see it as a signal.
Because if your system doesn't allow for decentralized evolution, it's not a system. It's a prison.
The true test is not whether everyone uses your library. It's whether, when someone breaks it, the system learns instead of punishing.
So, what to do?
Stop thinking of your Design System as a product.Think of it as a coordination infrastructure.
* Define clear, but not rigid rules.
Document not only what to do, but how to decide*.
* Make the change process visible, not just the result.
Celebrate forks* that add value, not just blind obedience.
The final irony
The best Design Systems are not the most used.They are the ones that disappear.
Not because they are invisible, but because their architecture is so solid that no one has to think about them. The team focuses on solving real problems, not fighting the system.
That is not achieved with more documentation.
It is achieved with less ego and more structure.
Joan Arbó
UX Engineer @ Western Union | Ex-Amazon Alexa
Has your team already made a fork of your Design System? Don't punish them. Ask yourself: what feedback is it giving me?
P.S.: If your Design System has an "owner" but not a "disagreement protocol," it's already broken. Someone just needs to say it out loud.