The first time I built a component library, I made the classic mistake: I made everything configurable. Buttons had twelve props. Cards had eight variants. The spacing system had forty-seven tokens. I was so proud of the flexibility that I didn’t notice the paralysis.
Every developer who touched the system spent more time choosing between options than building features. The “system” hadn’t systematised anything—it had just moved the chaos from CSS files into prop interfaces.
The paradox of choice in code
Barry Schwartz wrote about this in the context of consumer behaviour, but it applies equally to engineering. When you give a developer six spacing options, they pick one quickly. When you give them forty-seven, they either agonise or—worse—pick randomly and move on, creating visual inconsistency that compounds across every screen.
The best design systems I’ve used share a common trait: they’re opinionated to the point of seeming inflexible. You don’t choose your spacing. You use --space-3 because that’s what goes between related elements. End of discussion. The system made that decision for you, informed by hours of thought about visual rhythm and cognitive load that you shouldn’t have to repeat.
A design system is not a collection of components. It is a collection of decisions.
Decisions as infrastructure
Think of each design decision as a piece of infrastructure. A colour token isn’t just a hex value with a name. It’s a contract: “this colour means secondary text, in any theme, on any surface, in any context.” When you define --color-text-secondary, you’re not just naming a colour. You’re encoding a hierarchy relationship that every future component inherits for free.
This is why the Klim Type Foundry website is such an effective reference. They use exactly two heading levels in their blog posts. Not because they couldn’t add more—they clearly have the design skill—but because two is enough. The constraint isn’t a limitation. It’s a decision that frees every future author from wondering whether this sub-point deserves an H3 or an H4.
The cost of undecided
Every token you don’t define is a bikeshed argument waiting to happen. Every variant you don’t kill is a PR review comment about consistency. Every breakpoint you leave ambiguous is a mobile bug filed at 2am.
I count the quality of a design system not by what it enables but by what it prevents. A good system makes it nearly impossible to build something ugly. Not through restriction, but through defaults so well-chosen that deviating from them feels wrong.
Butterick’s Practical Typography operates on this principle. His rules aren’t suggestions. Body text is 15–25 pixels, period. Line length is 45–90 characters, period. Line spacing is 120–145% of the point size, period. The dogmatism is the feature. You stop thinking about whether your body text is too small and start thinking about what it says.
Building for the second developer
The true test of a design system is what happens when someone who didn’t build it uses it for the first time. Do they need to read fifty pages of documentation? Or can they look at one existing page and intuit the rules?
This is where the “visible infrastructure” principle earns its keep. When your grid is apparent—when a developer can feel the 12-column rhythm just by scrolling through the site—they stop fighting it and start working with it. The system teaches by example, not by manual.
The best design decision I’ve ever made was choosing to use fewer spacing tokens, not more. Eight values cover every case I’ve encountered in three years of building. The temptation to add a ninth “just for this one edge case” is the temptation to destroy the system. Resist it. Make the edge case fit. If it truly can’t, that’s a sign the edge case is actually a different pattern that deserves its own component.
Restraint compounds
One constrained decision saves one argument. A hundred constrained decisions create a culture where people build instead of debate. Over time, the accumulated constraints become invisible—they’re just “how things work here.” That invisibility is the highest compliment a design system can receive.
So the next time you’re tempted to add a prop, a variant, a token, a breakpoint, or an option: don’t. Make the decision. Commit to it. Write it down. Your future self—and every developer who comes after you—will thank you for the tyranny.