I.Process · June 2026
Most design systems aren't systems. They're a tidy mess.
We dressed up a component library, gave it a Notion page, and called it infrastructure. It's not. It's furniture. And the furniture is starting to argue with the house.
By Gisella Famà · 5 min read · Process
Walk into almost any product org and ask to see the design system. You will be handed a Figma file with 412 components, a token doc that hasn't been updated since the last rebrand, and a Slack channel where someone is, right now, asking whether to use Button/Primary or Button/PrimaryNew.
This is not a system. A system has rules, feedback loops, and a way of resolving conflict. What most teams actually have is a wardrobe — a neatly labelled collection of stuff that someone reorganises every six months and quietly resents.
"A library is a noun. A system is a verb. Most teams have the noun and call it the verb."
The tidy mess, defined
The tidy mess is what happens when the cosmetic layer is treated as the contract. Colours match. Spacing is on an 8-point grid. The documentation site has a hero with a gradient. Underneath, three product squads have quietly forked the primary button because none of the official variants survived contact with a real interaction.
Designers ship faster, briefly. Then engineers start writing wrappers. Then the wrappers get wrappers. Two years in, the team is maintaining a library, a meta-library, and a folklore of which components you are actually allowed to use this quarter.
Why this keeps happening
Systems are sold as a deliverable. They are bought as a deliverable. Nobody budgets the operating cost.
Ownership lives with one team but consequences live with all of them. That is not a system, that is a tax.
The success metric is adoption (a vanity number) instead of conflict resolved per quarter (the only number that matters).
Tokens are treated as decoration, not as a contract between design and engineering. So when the contract breaks, nobody is on the hook.
A slightly inconvenient opinion
Most teams under 80 people don't need a design system. They need three good primitives, a typography scale they actually obey, and a designer with the authority to say no. The rest is theatre — beautifully kerned, lovingly tokenised theatre — performed to convince leadership that design is mature.
The teams that genuinely benefit from a system are the ones who have already felt the pain of not having one across multiple products. Until then, building one is procrastination dressed up as rigour. It feels like the responsible adult thing to do. It is, in fact, the thing you do instead of shipping.
What a real system looks like
It has a governance model that fits on one page. It has a way for product teams to propose, fork, and merge back without filing a ticket into the void. It has someone whose actual job — not their side quest — is to keep the contract honest. And it ships less than you think, because most of the work is saying no to the eleventh variant of a card.
If your design system has a beautiful website but your product still looks like four different apps glued together, you don't have a system. You have a portfolio piece. There's a difference, and the difference is what your users feel every day.
"Stop building the museum. Start running the kitchen."
None of this is an argument against design systems. It is an argument against pretending the hard part is the components. The hard part is the politics, the maintenance, and the willingness to delete things. Almost nobody budgets for that, and then everyone is surprised when the tidy mess returns.
Disagree? That's the point. Tell me why.
← Back to all thoughts