Design Systems. Coherence vs. Consistency
I was presented with this nice dichotomy recently, and after having browsed around to get a glimpse of the online debate I must say that I can't take any sides on it.
Let me elaborate.
Consistency in a design system is what you would see in a system that is locked, one that doesn't evolve often and it is built and used with efficiency on mind. And by efficiency I mean doing things fast and be consistent with a specific brand, color palette, communication tone, and so on to the point of specific components and sometimes even predefined layouts.
Sounds familiar? Yes, it's because we've been exposed to these for quite some time now. Bootstrap and Material Design would be prime examples of these to certain extent.
Coherence on the other hand has been assigned to a design system that has strong definition in terms of the basic rules of the language, but it also allows flexibility on many aspects that a highly opinionated design system would flag as "don'ts".
Does this sound vague? Well it's because it is. The debate in favor of coherence specifies that the design system should not be dictating what things should look like in whatever platform you should be using it, and be more open to what the user might expect as familiar within the medium they use to consume your product.
A good example of this in digital design would be applications that look and behave differently on diverse platforms but cater exquisitely to the user, taking into consideration the expectations.
Have you ever seen differences between the same application when handling it on iOS vs Android? Well, if it's a respected application, then most likely their design system is based in coherence and not consistency.
This 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. I think that highly consistent design systems have a use and that coherent ones also have many aspects in favor.
The case for consistency
Consistency is a must on certain scenarios. Most likely on enterprise design.
Consistency is a good part of efficiency in terms of time and cost of development.
With a consistent system you have a sledge hammer to take upon any piece of software that it might arise. You have a library for your design software and a development mirror so that a developer can solve the UI of your product in no time.
Another advantage of a consistent system is that you don't need highly trained designers and developers on your product teams cause a big part of the UI work is already solved. This means, grab your juniors and make them come up with that feature ASAP.
Such scenario is highly appreciated by many companies cause it translates directly into saving money, and of course when saving money lot's of execs are really happy about it.
The ultimate goal of the consistent approach is to have a design system so streamlined that it could cater to many of the UI challenges that may arise during product ideation.
The consistent inconsistencies
Not everything is fine and dandy while being consistent.
A critique that has been given to these systems/frameworks is that all the products end up looking the same, producing infinite boredom. An example of this was that time when all the web looked like Twitter because of the huge popularity of their Bootstrap Library. Another case would be that your users may not distinguish clearly between the products of your suite because everything looks pretty much the same.
Evolving consistent design systems is sloooooow. A change to it is difficult if it hasn't been properly set up from the ground up with an atomic approach and technological aides such as tokens, variables and so on.
It is very difficult rebranding your system if this hasn't been taken into consideration as an architectural characteristic.
You need really skilled people defining the system and they should likely have knowledge of both design and development so that features can be planned and executed precisely from the ground up.
Every new idea and component has to go through the design jury before it makes it into the language. This means there will be a really powerful members within the team that may sacrifice really good ideas for the sake of time and money constraints.
The case for Coherence
Flexibility within certain standards is what dictates the basic approach of this philosophy.
This means that design will be in the center of every product feature you create and that your team MUST be comfortable with the UX product lifecycle. This is something only the very exquisite companies have in their DNA.
Catering to the users within the platforms/mediums they consume your products. Again, this means that you can create a unique UX that feels natural to the medium you are distributing your product (Again, iOS, Android, Web, etc)
The ability to come up with novel UI solutions to design problems that feel right for a specific UX case. This means that you don't have to rely on a specific toolset to solve your UX/UI problems. You can come up with something new and more efficient cause it's specifically designed with solving a certain issue or flow.
The satisfaction of having presented unique coherent and tailored experiences to your customers that elevate the brand to a different level of perception.
Incoherencies?
Well, with great power comes great responsibility.
An advantage of the philosophy can be seen as a disadvantage as well, which is that your shop MUST be comfortable with the UX product lifecycle. This is not the place for the vast majority of companies around the world, and although the process is gaining more and more relevancy, it's far from being a standard.
Your presentational layer professionals MUST be very well trained. Having so much flexibility can be confusing and can lead to disaster with UX/UI designers and developers misunderstanding flexibility for total freedom.
Every product team should have dedicated professionals taking care of product design and UX development. Surprised this is not the standard? Well, it's not.
Your product development lifecycle will not necessarily be more agile, nor faster, as attention to detail translates inevitably to time well spent.
Where to sit on this debate?
My take on this is that you should be prepared for both circumstances.
I have led projects where the coherence was a must due to de difficulty on representing certain information on screen. This is the case of the eHMP project for the VA, where medical software requires you to tailor very specific instruments that cannot be executed just by throwing bootstrap at them.
I have also developed a very consistent design system for CEMEX carrying the flag of efficiency and having designers and developers on the same page so we can produce applications faster while making our users feel at home.
One thing is very certain, that in any of these variants, the base of the design system should be very solid so that it doesn't leave room for wacky interpretations.
You also have to understand that design is a technical craft that is also subject to fashion and trends. This means your product team may become bored due to overexposure even before it hits production stage, so being able to navigate the incessant desire for novelty and change is something to take into consideration and managing expectations is always beneficial any route you may want to take.
Should you have the time, money and professionals to go through the Coherent branch despite the number and size of your projects then more power to you and your organization.
