Design systems: speed or fit?

A leader tells us they need a design system, and about five minutes into the first call the question lands: should it be consistent, or should it be coherent? Somebody on their team read a long thread about it, the room goes quiet, and everybody waits for us to pick a side.

Here is the belief behind the question, and it is a fair one: these are two camps, you choose one, and the wrong choice will cost you a year. It is easy to see why it feels that way. Both camps argue loudly, and both have real examples to point at.

We don't pick a side, and here is why. A consistent system is always coherent, because it follows one set of rules everywhere, while a coherent system doesn't have to be consistent at all. They are not rivals on the same line. One is a stricter version of the other, and the useful question is how strict your product can afford to be.

Consistency is a sledgehammer

A consistent system is a locked one. One library for the design tool, one code mirror for the developers, the same brand, the same colors, sometimes even the same predefined layouts. Bootstrap and Material are the famous examples, at least to a degree.

The appeal is plain: you have a sledgehammer for any piece of software that comes your way. A developer can solve the interface of a new product in no time, and you don't need highly trained designers and engineers on every team, because a big part of the work is already done. Grab your juniors and let them ship that feature. That saves time, and thus money, and plenty of executives are very happy about it.

The price shows up later. Everything starts to look the same, so your users can't tell the products in your suite apart, and you remember how the whole web once looked like Twitter because everyone used the same library. Evolving a locked system is sloooow too. A rebrand is brutal if it was never an architectural consideration, and every new component has to pass the design jury before it enters the language, which means a few powerful opinions will sometimes sacrifice a good idea for the sake of time.

Coherence is fit

A coherent system defines the basic rules of the language strongly, and then leaves room where a highly opinionated system would say don't. It doesn't dictate how things look on every platform. It stays open to what the person using it expects in the place they are using it.

Ever noticed the differences between the same app on iOS and on Android? When it is a well made app, the differences are on purpose, and the product feels natural on both. That is coherence. You get the freedom to invent a new solution when a case calls for one, and experiences that feel tailored to the medium.

It asks a lot back, though. Your people on the presentation layer have to be very well trained, because so much flexibility turns into disaster when a team mistakes it for total freedom. Every product team needs dedicated design and front-end people, and the whole company has to be comfortable with a real product design lifecycle. Surprised that is not the norm? It is not. Nor will it necessarily be faster, because attention to detail is time well spent, but it is still time.

How to choose

If you are the one buying or commissioning the system, these are the questions we would sit down with before anything gets drawn:

1. How many products, and how many teams? Many teams and thin senior coverage point to consistency. A few products with strong people point to coherence.
2. Who builds the interface day to day? If the answer includes a lot of juniors, the system has to carry the judgment for them. That is a consistency system.
3. How specialized is the information on screen? Some content can't be forced into a standard component. Dense, high-stakes data usually asks for tailored instruments.
4. How often will it need to change? If a rebrand or a new platform is likely, the system needs tokens and an atomic structure from day one, whichever side you choose.

We have led both. On eHMP, the clinical software for the VA, coherence was a must, because medical information needs very specific instruments, and you can't execute those by throwing Bootstrap at them. At CEMEX we built a very consistent system under the flag of efficiency, getting designers and developers on the same page so teams could ship applications faster while making users feel at home. Same craft, opposite answers, and in both cases the context made the call, not taste.

One thing holds on either route. The base of the system has to be solid enough that it leaves no room for wacky interpretation, and it helps to remember that design is a technical craft still subject to fashion, so your own team may get bored of it before it even hits production. Plan for that appetite for novelty, and manage the expectations around it, and it pays off whichever way you go.