The most common thing I hear when teams start a design system project is some version of: "once we have the system, we'll finally have a consistent product."
I've thought this too. And I've been wrong.
Design systems are necessary. They're not sufficient. The gap between having a system and having a consistent product is wider than most teams expect — and it's filled not by more components, but by people, habits, and shared judgment.
What a design system actually gives you
A mature design system gives you a shared vocabulary. When someone says "use the primary button," everyone knows what that means. When the spacing between a label and an input is defined in a token, there's no argument about whether it should be 8 or 12 pixels.
That's genuinely valuable. It collapses a category of low-level decisions and frees attention for higher-order ones.
But "shared vocabulary" and "consistent product" are not the same thing.
Where consistency actually breaks down
In my experience, consistency breaks down at three levels the system doesn't touch.
Pattern selection. The system tells you how to use a modal. It doesn't tell you when to use a modal versus an inline expansion versus a drawer. Those decisions happen at design review, or in someone's head at 11pm before a deadline. If there's no shared instinct for when each pattern is appropriate, you get a product where similar problems are solved differently in different parts of the app — even when everyone is using the same components.
Tone and judgment. Consistent products feel like they were made by a single coherent mind. That's not a component problem — it's a taste problem. It comes from designers who've spent enough time together to have absorbed each other's instincts, and who push back on each other when something feels off. You can't token your way to this.
Implementation fidelity. Design tokens make it to code only if engineers integrate them. Component libraries stay consistent only if the team has a culture of using the library rather than one-offing things. The gap between Figma and production is almost always a process and culture gap, not a design gap.
What actually creates consistency
The things I've seen create genuine product consistency are less glamorous than a design system:
- Regular design reviews where the whole team looks at work together and develops shared language for what's working and what isn't. Not just critique — comparison and calibration.
- A strong point of view on the product that designers actively maintain. Not just "are we using the right components" but "does this feel right for what we're trying to be."
- Engineers and designers spending time on problems together, not just handoffs. Consistency in production comes from engineers understanding the intent behind decisions, not just the spec.
- Someone who feels responsible for the whole product at once. Systems have owners. The product's felt coherence often doesn't — it's everyone's problem and therefore sometimes no one's.
The system is a foundation, not a finish
I'm not arguing against design systems. I work with one. I contribute to one. They solve real problems.
But the teams I've seen with the most consistent products treat the system as a starting point for a larger conversation about craft and judgment — not the end point. The system codifies what's already agreed upon. Consistency requires continuous agreement on what hasn't been codified yet.
That's a human problem. Components don't fix it.
Credits & further reading
- Brad Frost, Atomic Design (2016, free online at atomicdesign.bradfrost.com). The foundational text on thinking about design systems as hierarchical, composable components rather than static style guides. The "atoms → molecules → organisms" mental model is where component thinking in design systems began.
- Nathan Curtis — his writing at EightShapes on design system governance, team structure, and the organizational challenges of maintaining shared systems is the clearest thinking I've found on why systems fail in practice. The gap this note describes — between having a system and having a consistent product — is a gap he's written about extensively.
- Design Systems — Alla Kholmatova (Smashing Magazine). The most practical book on building and governing design systems in real product teams. Goes beyond the component library and into the cultural and process questions the system can't answer.
- The point about "consistent products feeling like they were made by a single coherent mind" connects to Jony Ive's interviews on the Apple design process — not a book, but worth searching. Product coherence at that level is an organizational and cultural achievement, not a tooling one.