Can consistency harm your product?
A lot has been said about the value of consistency in product design. We obsess over design systems, unify the visual language across all company assets, and research and implement the industry’s best practices. We believe it leads to flawless UX and saves us money. It is often the case. Often, not always. I would like to poke the dragon and suggest that there are situations when blindly striving for consistency can harm our products, block innovation and slow us down.
First, just a bit of theory — What is consistency?
One of the definitions Cambridge English Dictionary gives to the term “consistency” is the quality of always behaving or performing in a similar way. In terms of user experience, it means that similar elements and patterns are uniform, they look and function similarly.
There are four types of consistency:
- Visual — when similar product elements and patterns look the same
- Functional — when similar product elements and patterns behave the same
- Internal — when similar elements and patterns inside the product look and behave the same
- External — when elements and patterns look and behave the same as in most of the apps, i.e. follow industry standards and best practices.
For the goals of this article, I will focus on internal consistency, thus uniformity of elements within one ecosystem of products and websites. It would be more relevant for larger organisations overseeing bigger infrastructure, in which new and legacy products or websites are built and maintained.
Ideal world vs. reality
In the ideal world, our products are designed using elements of a high-quality, complete, accessible and thoroughly tested design system. The problem is that it’s rarely the case. A few organisations can afford a team dedicated only to creation and maintenance of a design system infrastructure. It indeed requires the teamwork of designer(s), frontend developer(s), product manager(s) and ideally some design ops who would ensure all teams are aligned. It’s already hard to find designers with the right skills — you’d be surprised, but system thinking is a rare trait. In reality, “design systems” are often put together over long periods of time, containing “creative” solutions that probably have not been tested. More often then not it’s hard to track why exactly something is made a certain way, it’s just “how we always did it”.
The problem arises when we try to reuse those poorly designed and outdated patterns. When we are talking about big products, they may have multitudes of variations of the same component owed by different teams and different agendas. For example, imagine a table grid component. One team created a solution that changes the way tables look/behave. They tested it and it indeed works great. The only problem is that it is inconsistent with all the other tables throughout the product. Even with a well-oiled system of shared components, changing all the tables might result in weeks spent in meetings and politics trying to influence other teams’ plans, let alone the time spent on the actual design of all variations, development and testing. As a result, unable to push the improved but inconsistent solutions through, the team would settle on the worse but consistent one. Religiously trying to be consistent might block improvements, the experimenting with better patterns and new approaches.
The hard question is where to draw the line — does inconsistency really harms the overall UX as much, as consistency with the patterns that do not work perfectly anymore? One extreme is an organisation where every team is designing their stuff as they please without considering general standards, another extreme is when any deviation from the standards is painfully hard. Neither of these approaches is good.
Does it even matter?
Before pushing or blocking an inconsistent solution, consider the following:
Will users actually notice the difference?
- Will users encounter the same component during the same user session? For example, imagine Airbnb host and travel experience — the flow of booking a property doesn't need to be perfectly consistent with a property registration by a host. Those flows are unlikely to be performed on the same day and by the same user, thus inconsistency of UI won’t be noticeable.
- Is the content of the page different enough, so that inconsistency is justified? For example, back to the Airbnb example, a list of rental listings and a list of payout invoices might both essentially use the same components — a table grid with a set of filters, but users would not find their stage if they actually look different.
This is a very common scenario, most often people do not notice anything odd with inconsistencies that a designer eye might obsess about. Sometimes we should just take our work less seriously :-).
Would noticeable inconsistency result in a significant loss of trust or a drop in conversion?
In some cases an element look so foreign to the rest of the product that users are reluctant to use it. Consider a payment page of an e-commerce store. Online payment forms are often provided by a third-party service— Paypals and Stripes of the world. Done poorly, such forms might look significantly different from the rest of the store. Imagine that the pay button is green and square, while the rest of the shop uses pink and round. Customers might feel unsafe and drop their purchase — money lost. On the other hand, in the same example, when the pay button is black and round while all the other buttons are pink and round, users will not see it as a foreign element, but as a design highlight. The border between acceptable and unacceptable inconsistency is very thin.
Is there a high risk to make an irreversible mistake because of earlier-learned patterns?
For example, if CTA is always placed to the right from the secondary action, swapping them might result in a lot of frustration.
Does consistency actually work better?
In some situations, intentionally inconsistent patterns lead to better UX. If the product contains a lot of similar modules, users might confuse them. Once I worked on a complex product that included multiple modules that were designed as table grids with filters, which was the best way to organise the large quantities of data. All tables and filters were perfectly consistent and each module performed very well alone. But when we started testing the entire journey, the feedback we got was that all modules looked the same and people mixed them up when did not pay close attention to titles. The solution was to add different visual elements to help users to distinguish them one from another without having to read the titles.
Lean and agile practices
Lean and agile practices might be the key to the issue. Introducing a new UI pattern, it might be safer to do it for a single area of the product and see how it performs, and only after scaling it to the entire application, possibly in many iterations. Starting small and learning fast allows us to go through a number of improvement cycles before adding an element into a global design system that would affect other products.
Think big, act small, fail fast; learn rapidly
- Lean slogan
Stop feeding the monolith
Sometimes, products grow way too big and heavy. Too many dependencies slow teams down, and too many features confuse users. In these cases, we might deliberately break the product down into a set of products, aka products suit. The requirement to stay consistent across all products should be limited to absolutely necessary critical elements and flows when it can really confuse the user. In many cases, it’s only about the basic set of colours and most primitive and frequently used components (e.g buttons and main navigation). As an example, check Google products — Youtube, Gmail and Google docs look roughly similar, but if you would follow their evolution over time, you would notice how they used radically different patterns and styles, which sometimes became shared, and sometimes remained different.
Conclusion
Consistency is only one of many qualities of a UX solution, along with how well the solution solves the problem, how easy/intuitive it is to use, and how delightful the experience is. All qualities have to be weighted and compared.
References:
