Design systems for consistency and efficiency in UX
Why the best systems are invisible, and how to build one that scales without drowning the team in tokens.


The best design system I ever built is one almost nobody at the company could point to. No one opened it to admire it. It just meant that a button looked like a button everywhere, that a new feature shipped in days instead of weeks, and that the twelfth screen in a flow felt like it came from the same hand as the first. That invisibility is the point, and it is also why design systems are so easy to underfund. You cannot take a screenshot of a problem that quietly stopped happening.
For a long time I pitched systems the way most designers do, as a way to save time, and that framing undersells the whole thing. Yes, the time savings are real. Figma's own research put designers working with a mature system at around thirty four percent faster on the same tasks, and three quarters of their enterprise customers run on a shared system rather than improvising screen by screen. But efficiency is the small argument. If you walk into a room of executives and lead with productivity, you have already lost, because every team in that building claims it will make people faster.
faster on the same tasks for designers working with a mature, shared system
The bigger argument is consistency as economics, and the strongest evidence for it does not come from a design blog. It comes from McKinsey, who tracked three hundred public companies over five years and built a design index out of two million pieces of data. The companies in the top quartile for design grew their revenue and their shareholder returns dramatically faster than the rest, by margins large enough that no CFO can wave them away. A design system is the machine that makes that kind of consistency repeatable instead of accidental. It is not the cost center. It is the thing that lets a brand feel like one brand at the exact moment it is scaling fastest and is most likely to fracture.
There is a part of this that I have come to believe is almost a moral argument, and it is accessibility. The WebAIM Million scans the top home pages on the web every year, and year after year the number lands around the same brutal place, roughly ninety five percent of them carry detectable accessibility failures. Most of those failures are not exotic. They are low contrast text, missing alternative text, headings in the wrong order. These are exactly the problems a design system solves once, in one place, and then distributes to every screen automatically. When the color tokens pass contrast and the component ships its label correctly, a thousand future pages inherit that without anyone thinking about it. A system is the most scalable accessibility decision a company can make, and almost nobody sells it that way.
of the top home pages on the web carry detectable accessibility failures, most of them solvable once at the system level
Here is the trap I watch teams fall into, including teams I have been on. They treat the system as a project with an end date. They build it, they launch it, they move the people off it, and then they are surprised eighteen months later when it has quietly rotted into something nobody trusts. A system is not a deliverable. It is a product, and its users are the designers and engineers who depend on it. That means it needs a roadmap, it needs someone listening to the people adopting it, and it needs maintenance budget that does not vanish the week after launch. The industry is slowly admitting this. In zeroheight's 2025 report, nearly eight in ten teams now have dedicated design system people, up from the year before. The ones who staff it like a product are the ones whose systems are still alive.
A design system is not a deliverable. It is a product, and its users are the designers and engineers who depend on it.
of teams now have dedicated design system people, up from the year before
The reason consistency pays is that inconsistency is expensive in ways that never show up on a single invoice. Every time a pattern is reinvented, an engineer rebuilds something that already existed, a designer relitigates a decision that was already made, and a user hits a screen that behaves a little differently than the last one and loses a little more confidence. None of those moments is catastrophic on its own. They compound. A system is the decision to stop paying that tax forever, and to pay a smaller, predictable cost of maintenance instead.
So when someone asks me to justify the investment, I have stopped reaching for the time savings first. I tell them the system is how the company keeps looking like itself while it grows, how it ships accessibility by default instead of as a lawsuit response, and how, over a few years and not a single quarter, it turns design from a thing you redo constantly into a thing you build once and trust. The best ones disappear into the work. That is not a bug in how we talk about them. That is the whole product.