Design Systems: Coherence vs. Consistency
TL;DR
- Consistency and coherence get framed as rivals. They are not. A consistent system is always coherent, but a coherent one does not have to be consistent.
- Consistency optimizes for speed and cost: one library, one dev mirror, junior teams shipping UI fast. The price is sameness and slow evolution.
- Coherence optimizes for fit: each platform gets an experience that feels native. The price is that it demands trained people and a real UX lifecycle, which most shops do not have.
- I have shipped both. Coherence on eHMP for the VA, where medical instruments cannot be solved by throwing Bootstrap at them. Consistency at CEMEX, where efficiency and a shared language mattered more.
- Whatever you choose, the base of the system has to be solid enough to leave no room for wacky interpretation.
I was handed this dichotomy recently, and after browsing around to get a glimpse of the online debate, I have to say I cannot take a side on it. Let me explain why.
Consistency in a design system is what you see in a system that is locked. One that does not evolve often, built and used with efficiency in mind. By efficiency I mean doing things fast and staying true to a specific brand, color palette, and tone, right down to specific components and sometimes even predefined layouts. Sounds familiar? It should. We have been exposed to these for a while now. Bootstrap and Material Design are prime examples, at least to a degree.
Coherence, on the other hand, describes a system with a strong definition of the basic rules of the language, but one that also allows flexibility on things a highly opinionated system would flag as "don'ts". Does that sound vague? It is. The argument for coherence is that a design system should not dictate what things look like on whatever platform you use it, and should stay open to what the user expects as familiar in the medium they consume your product through.
A good example in digital design is an application that looks and behaves differently across platforms but caters exquisitely to the user by honoring their expectations. Ever noticed the differences between the same app on iOS versus Android? If it is a well made app, its design system is most likely built on coherence and not consistency.
Which means a consistent design system is highly coherent, but a coherent design system does not need to be highly consistent. Do I have a preference? No. Highly consistent systems have their use, and coherent ones have plenty going for them too.
The case for consistency
Consistency is a must in certain scenarios, most likely enterprise design. It is a big part of efficiency in terms of time and cost of development.
With a consistent system you have a sledgehammer for any piece of software that comes your way. You have a library for your design tool and a development mirror, so a developer can solve the UI of a product in no time. Another advantage: you do not need highly trained designers and developers on every product team, because a big part of the UI work is already solved. Grab your juniors and let them ship that feature.
That scenario is loved by many companies, because it translates directly into saving money, and plenty of execs are very happy about that. The ultimate goal of the consistent approach is a system so streamlined that it can cater to most of the UI challenges that come up during product ideation.
The consistent inconsistencies
Not everything is fine and dandy about being consistent. One critique of these systems is that all the products end up looking the same, which produces infinite boredom. Remember when the whole web looked like Twitter because of the popularity of their Bootstrap library? Another version of the problem: your users cannot tell the products in your suite apart, because everything looks pretty much identical.
Evolving a consistent design system is sloooooow. Change is hard unless the system was set up from the ground up with an atomic approach and technical aides like tokens and variables. Rebranding is very difficult if that was never an architectural consideration.
You need genuinely skilled people defining the system, ideally with knowledge of both design and development, so features can be planned and executed precisely from the start. And every new idea and component has to pass the design jury before it enters the language, which means a few powerful members will sometimes sacrifice good ideas for the sake of time and money.
The case for coherence
Flexibility within certain standards is the basic posture of this philosophy. It means design sits at the center of every product feature you create, and that your team has to be comfortable with the UX product lifecycle. That is something only the most exquisite companies carry in their DNA.
You cater to users within the platforms they consume your products on, which lets you build a UX that feels natural to each medium: iOS, Android, web, and so on. You get the freedom to invent novel UI solutions that feel right for a specific case, without leaning on a fixed toolset. And you get the satisfaction of presenting tailored, coherent experiences that lift the brand to a different level of perception.
Incoherencies?
With great power comes great responsibility. The strength of the philosophy is also its weakness: your shop has to be comfortable with the UX product lifecycle. That is not where most companies in the world live, and although the process keeps gaining relevance, it is far from standard.
Your presentation-layer professionals have to be very well trained. So much flexibility can be confusing, and it leads to disaster when designers and developers mistake flexibility for total freedom. Every product team needs dedicated people on product design and UX development. Surprised that is not the norm? It is not. And your development lifecycle will not necessarily be faster, because attention to detail translates inevitably into time well spent.
Where to sit on this debate
My take is that you should be prepared for both circumstances.
I have led projects where coherence was a must because of the difficulty of representing certain information on screen. That was the case on the eHMP project for the VA, where medical software forces you to tailor very specific instruments that you cannot execute by throwing Bootstrap at them. I have also built a very consistent design system at CEMEX, carrying the flag of efficiency and getting designers and developers on the same page so we could ship applications faster while making users feel at home.
One thing is certain. In either variant, the base of the design system has to be solid enough that it leaves no room for wacky interpretation. It also helps to remember that design is a technical craft that is still subject to fashion and trends, so your team may get bored from overexposure before a thing even hits production. Navigating that constant appetite for novelty, and managing expectations, pays off on any route you take.
If you have the time, the money, and the professionals to go the coherent route despite the number and size of your projects, then more power to you and your organization.