The Design System That Fits in Your Head
A design system isn't a component library — it's a set of decisions small enough to remember. On the cognitive budget of the systems we build, and why most of them quietly bankrupt the people who use them.
There is a particular kind of design system that looks magnificent in the documentation site and falls apart the moment a real person tries to use it under deadline. It has four hundred components, eleven button variants, a token named color-surface-secondary-hover-inverse, and a contribution process with its own RFC template. It is, by every visible measure, mature. And nobody can hold it in their head.
That last sentence is the whole problem. A design system is not, fundamentally, a library of components. It is a set of decisions that a team has agreed to stop re-litigating. The components are just the decisions made physical. And decisions live in human heads, which have a fixed and unforgiving budget.
What a system is actually for
The point of a system is to remove choices, not to offer them. Every time a designer reaches for a button and finds one obvious answer, the system has done its job: it has converted a decision into a reflex. The team gets to spend its scarce attention on the things that are genuinely new about this screen, this flow, this product.
When a system instead offers eleven button variants, it has done the opposite. It has taken a settled question — what does a button look like here — and reopened it, eleven times over, on every screen, forever. The library grew, but the cognitive load grew faster.
The tyranny of completeness
Most systems rot in the direction of completeness. Someone needs a slightly different card, so a variant is added. The variant is reasonable in isolation — they always are. But the marginal cost of a variant is not the design time to make it. It is the permanent tax it levies on everyone who now has to know it exists, choose against it, and explain to a teammate why they did.
Completeness feels like rigor. It is usually just an unwillingness to say no.
Tokens are a memory aid, not a database
Design tokens get this wrong constantly. A token system is supposed to be a small vocabulary — a dozen colors, a handful of spacing steps, three or four type sizes — that a person can recite from memory. The whole value is that space-4 means something because there are only six spacing tokens and you know them.
The moment you have ninety spacing tokens, the abstraction has inverted. Now nobody recites them; everyone looks them up. You have rebuilt the raw pixel values you were trying to escape, but with worse ergonomics and a layer of indirection on top.
I keep token sets aggressively small and let teams compose. In Figma this means resisting the urge to publish a variable for every value a designer might ever want, and instead publishing the values they should reach for by default. The defaults are the system. Everything else is an escape hatch, and escape hatches should feel slightly uncomfortable to use.
The system as a social object
Here is the part the tooling discourse misses. A design system’s real substrate is not Figma or code — it is agreement. It works because a group of people share a model of how the product is supposed to look and behave, and they trust each other to honor it.
That trust is what you are actually maintaining. When the system gets too large to hold in one head, the shared model fractures into many partial models, and the agreement quietly dissolves. People stop trusting that “the system” has an opinion, because no single person can say what the opinion is. They start improvising, and the improvisations don’t compose.
This is why I treat governance — the boring stuff, the issue tracker, the way changes get proposed in something like Linear and discussed before they ship — as more load-bearing than any component. The components are downstream of whether the team still shares a brain.
Pruning is the senior skill
The most valuable thing a systems person does is not add. It is remove. Deprecate the third card variant. Collapse the two date pickers into one. Delete the token nobody uses. Every removal buys back cognitive budget and re-tightens the shared model.
It is unglamorous and slightly unpopular, because removal always inconveniences someone who was using the thing. But a system that only grows is a system with a half-life. The pruning is the maintenance.
Build for the head, not the doc site
So when I start a system now, I don’t ask how complete it is. I ask whether a person can hold it. Can a new designer learn the spacing scale in an afternoon? Can an engineer guess the component name before they search? Can the whole team agree, without a meeting, on what a primary button is?
If yes, the system is small enough to be real. If no, it doesn’t matter how beautiful the documentation is — you have built a reference manual, and reference manuals don’t make decisions. People do, and only with the decisions they can remember.