The Difference Between Consistency and Correctness in Product Design
Consistency has a cult following in product design. Design systems, component libraries, atomic design — all of it is infrastructure for making things look and behave the same way across a product. That’s genuinely valuable. I’m not arguing against it.
But there’s a version of consistency that becomes an excuse for not thinking. It shows up in code reviews and Figma comments everywhere: “This doesn’t match the system.” Full stop. No further reasoning. The system is the argument.
That’s not design. That’s compliance.
Consistency is a proxy metric
What consistency actually proxies for is coherence. Coherence means the product feels like it came from one mind — the interactions, the visual logic, the communication patterns share a common reasoning. Users don’t consciously register consistency. They register trust. They register “this thing makes sense.”
But coherence doesn’t require sameness. It requires shared intent.
A button that behaves differently in a critical flow than it does on a marketing page isn’t inconsistent — it might be exactly correct. The context changed. The stakes changed. The right call changed. Forcing the same component behavior into both is what creates friction, not what removes it.
Consistency treats every context as equivalent. Correctness asks whether the context is actually equivalent before deciding.
Where consistency becomes a ceiling
The places consistency fails hardest:
- Error states. A playful, rounded UI should still feel serious when something goes wrong. Matching the system’s tone in error messages has cost more user trust than I can count.
- Onboarding. New users are not in the same mental state as returning power users. The same navigation pattern doesn’t serve both. Treating them consistently is a false efficiency.
- Edge cases. The edge case is, by definition, outside the pattern. Forcing it into the system produces a UI that technically follows the rules and obviously doesn’t work.
The problem isn’t that teams chose consistency. It’s that they stopped asking the prior question: consistent with what, and for whom?
The actual discipline
Correctness is harder than consistency because it can’t be automated. A linter can catch deviations from your design system. No tool catches a component that follows all the rules and still fails the user.
The designers I trust are the ones who can tell you why a given element was chosen — not just what it is, but what problem it solves, what alternative was rejected, why this context is different from the surface it resembles. That reasoning is the design. The component is just the output.
If you can’t explain why something is correct, “it’s consistent” is not the answer. It’s a placeholder.
Make your system. Enforce it where it earns enforcement. And know the difference between breaking it because you’re lazy and breaking it because you’re right.