Design systems have become the dominant paradigm in product design. They've also become a kind of dogma — one that optimises for consistency at the expense of the thing consistency is supposed to serve.
There is a particular kind of meeting that happens in almost every design organization above a certain size. Someone has built a component that doesn’t exist in the system. A system team member is brought in to review it. The review is not about whether the component is good — whether it solves the user’s problem, whether it’s well-considered, whether it delights. The review is about whether it fits.1
This is the moment design systems orthodoxy reveals itself. The system has become the arbiter of correctness, and the user has quietly left the room.
The point of a design system was never consistency. It was to free designers from re-solving solved problems, so they could spend more time on unsolved ones.
Design systems emerged from a real problem. At scale, inconsistency compounds. Buttons with slightly different radii, spacing that drifts across platforms, color values that live in someone’s head — these things erode trust in a product silently, one rough edge at a time. The system was the solution.
But solutions have a way of outliving the problems that created them. The system became infrastructure, then process, then culture. Tokens replaced colors. Figma libraries replaced handoff. And somewhere in that progression, the system stopped being a tool and became a constraint.2
The tell is in the language. Systems teams talk about adoption rates, coverage metrics, drift detection. These are the metrics of a compliance function, not a design function. The system has started to manage design rather than enable it.
The cost is subtle but real. When the system is the ceiling — when novel work is de facto out of scope — you lose the experiments that would have pushed the product forward. The components that ship are correct but not interesting. The interactions are consistent but not considered. The system protects quality at the median while suppressing quality at the high end.
There’s also a second-order effect on the designers themselves. When enough of your work is system-compliant by definition, you stop building the muscle that generates the system’s next generation. You become a consumer of prior taste rather than a producer of new taste.3
A system that can’t accommodate the work that should exist in five years isn’t a system. It’s a snapshot.
The healthier frame is to treat the design system as a hypothesis, not a truth. Every component in it is a current best answer to a recurring question. The job of the system team is not to enforce that answer but to keep asking whether the question has changed — and to make it easy for the rest of the organization to surface cases where it has.
This requires a kind of institutional humility that is genuinely difficult to maintain. It means accepting that the most valuable work sometimes happens at the edges of the system, not inside it. It means treating outliers as signal rather than noise.
None of this means design systems are wrong. They remain one of the most effective tools available for scaling design quality. But like any tool, they’re only as good as the assumptions built into them — and those assumptions need revisiting more often than most system teams allow.
This isn’t a critique of system teams specifically — it’s a structural problem. The incentives of a system team are naturally oriented toward coverage and consistency, not toward the quality of any individual solution. ↩
The pattern recurs across infrastructure generally. CI/CD, design systems, component libraries — all begin as force multipliers and can end as gatekeepers. ↩
Related: the best system contributions often come from product designers who are also prolific producers of novel work. The system stays alive because they keep stress-testing its edges. ↩