Consistency as represented by a rogue square in an array of circles

When design consistency is harmful

Mark Parnell
Designing Atlassian

--

Looking back at the lies I was told growing up, a few stick out…

Like when my grandmother convinced me that opening a can of Burger King’s Ghostbusters 2-branded tie-in drink, would cause an actual ghost to jump out. This led to such fear that the merest hint from my grandmother of opening the can would terrify both my sister and I. She was an interesting woman, my grandmother.

Three views of a can of Burger King’s Ghostbuster’s coca-cola
The offending can

One of the more insidious mistruths has been the need to always be consistent with your design work. In this post, I examine just how consistent we should be, and where a quest for consistency can lead us to make poorer design decisions.

Being consistent is, in informal language, a virtue. While there are few people who are consistently bad (Martin Shkreli springs to mind here) being inconsistent is the preserve of the cheat and the hypocrite, a defect of the morally suspect. So too with design. It doesn’t take long to remember design inconsistencies that are baffling, offensive, and maddening in equal measure. Inconsistencies such as:

Turn indicators

A car steering wheel, including stalk controls

A clear example of inconsistency existing across an industry. In some cars (usually European or American), the left-hand stalk controls turn indicators. Yet in other cars (typically Japanese or Korean), the right-hand stalk controls indication. This lack of a consistent standard means trips in unfamiliar hire cars is a frustrating battle of turning wipers on every time you want to turn.

Keyboard shortcuts for grouping

A screenshot of an Arrange menu from a MacOs app

I love nothing more than grouping objects in software, whether in Figma, Keynote, or Photoshop. Unfortunately, this is often harder than it needs to be.

Most MacOS apps — from Figma to Sketch to Photoshop to Mural to Affinity — use the simple CMD + G shortcut to group a set of objects.

Keynote stubbornly resists this simple pattern and uses the shortcut Option + CMD + G. This leads to much irritation as I hammer CMD + G to no avail, and Keynote uselessly tries to “find next”.

Swipe actions

Screenshots of several different swipe actions from iOS apps

Inconsistency exists in simple visual differences — take swipe actions on iOS. In some apps, they’re just text, in others text combined with an icon, and yet in others, they have different labels. Minor, but once you notice this, the lack of care is evident in keeping the interface consistent.

Inconsistency then, is bad. It isn’t hard to list the many ways a great experience is delivered by consistent use of elements and controls.

Some examples:

Google Workspace navigation

Screenshots of the navigation from several different Google Workspace apps

The navigation bar in Google workspace apps provides a consistent experience with just the right amount of flex — you always know how to navigate within and between apps but the elements of the navigation bar are optimized to the specific app you’re in.

MacOS / iPad shortcuts

An image showing different keyboard shortcuts — command c, command v and command c

The same keyboard shortcuts can be used on both Mac and iPad keyboards, making moving between the two, effortless.

Atlassian Jira issue visual language

Screenshots of different versions of a Jira issue, showing consistent design elements in each

In Jira, the consistent use of an icon and a numerical issue key provides a powerful visual shorthand that a user is looking at an issue, whether the issue appears as a list item, a card, a link, or as a full page.

Signage systems

Different but consistent versions fo a bus signage system

Signs, through a consistent system of visual identifiers, colors, and terminology (whether in airports, metro lines, or on the roadside) relay information much more quickly through their consistency.

Here, for instance, is a set of Australia’s roadsigns. As with other signage systems, it’s helpfully and thoughtfully consistent.

A large collection of Australian road signs

Now let’s suppose that high on the achievement of creating such a successful and consistent set of signage, a crazed sign designer mandated that all roadside signs conform to the visual standards they have defined. Thus buildings, houses, and advertising signs must use the same pattern.

In this world, a nice cosy house sign and produce advertising would end up similarly consistent:

House signs and advertising, both before and after being made consistent with a road signage system

Mission accomplished — we are consistent! By extending consistency beyond reasonable sense, it has now caused a far worse design outcome. We’ve lost many of the specific, idiosyncratic goals that the two signs had, either to express something homely and charming about a house or to sell the many virtues of Vegemite. Worse yet, we now have many, many similar-looking signs, some carrying critical information, others mere house names or adverts. And even if our maniacal sign designer then mandates that house signs and advertisements be a different color, this doesn’t do much to reduce the monoculture or remedy the first problem.

Consistency is not everything

In short, consistency is not and cannot be the sole criterion of good design. Building a consistent design system is important, but over-zealous quests for consistency can be at the expense of other aspects of design.

Let’s take Google’s recent redesign of the icon system for Google Workspace. It’s great in many ways that a more consistent set of icons was introduced, but the downside is that every icon is now one of an almost identical set of rainbow boxes and blobs, indistinguishable from one another at a glance and harder to discern between.

The old and updated versions of Google Workspace icons

As one Reddit user states “the icons blend into a sea of colorful boxes”.

A meme with the Google Workspace icons and how, to one Reddit user, all the icons look like dientical boxes
Via u/Behave_or_else

Now let’s not raise our pitchforks and join the mob that is drawn whenever a major app makes bold changes. It’s clear from this example there are some downsides to focusing on too much consistency. Looking at my own work at Atlassian, I can see a number of times where this has been true — here’s an incidence:

Atlassian: Compass

We were designing cards to structure information on a screen. Our initial design used a different format for a card that captured a performance score. Such scores are an important indicator that users would need to appraise and understand at a glance.

An original set of cards, with a prominent, distinct design for the performance indicator, and a consistent set of cards where all cards are consistent but the eprformance indicator is less prominent

In the course of iteration, the team veered towards a design that did away with this different layout and ensured greater consistency across the cards, but at the cost of the score being easy to comprehend at first glance. The result was a worse experience, with critical information harder to parse on the page.

Thankfully the team moved back to the earlier design, but the quest for consistency led us to miss other important design considerations and put us at risk of worse design outcomes.

Why and when consistency is important

The importance of consistency in interface design has been understood for a long time, one of Jakob Nielsen’s 10 usability heuristics is:

#4: Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.

He then adds …

People spend most of their time using digital products other than yours. Users’ experiences with those other products set their expectations. Failing to maintain consistency may increase the users’ cognitive load by forcing them to learn something new.

Nielsen goes on to highlight the need to maintain both internal and external consistency — consistency within your tool or product family and consistency with wider industry conventions.

Recall the Apple keyboard shortcuts example discussed earlier? Apple’s keyboard shortcuts are internally consistent and CMD + G will “find next” across all Apple Mac apps, but this is at the expense of being consistent with the wider industry pattern of using CMD + G to group objects.

Should we optimize for internal or external consistency? I think Jared Spool is right when he argues that this is the wrong question. He argues that we should be thinking about the current knowledge of the user, because

When you think about consistency, you’re thinking about the product. When you’re thinking about current knowledge, you’re thinking about the user. They are two sides of the same coin.

I would add to this the importance of also thinking about the user’s current goals. That is, not just thinking “what does the user currently know?” but also “what are they trying to do?”. To go back to our card example, we need to optimize not just for what the user knows about how cards look. We also need to optimize for user goals that contribute to making critical scoring information more prominent.

Spool goes on to state

Why do we gravitate to consistency? Because it’s easier to think about. You don’t actually have to know anything about your users to talk about making things consistent. You only have to know about your design, which most designers are quite familiar with.

It’s not a matter of consistency being easier to think about, the goal of creating a consistent design system displaces the goal of creating an effective, usable interface for users.

The tail wags the dog

Creating a consistent design system is both important and wickedly hard. And yet, such a design system is merely a tool to deliver better experiences to our users by increasing internal consistency.

For designers there is often a trap we fall into as we start to create components in tools like Figma. We think our goal is to nurture a “perfect” design system. A system where every piece of typography is the same, where every component has the same states with the same colors and the same terminology. As we design, exceptions multiply, but we almost see these as a threat to the logic of our designs, and so find ways to shoehorn them into the existing system instead of evolving what we have designed and building in more flexibility to support unmet user needs.

A set of interface elements and their variants laid out in a Figma file

To come back to Spool’s point, we have come to ask the wrong question about consistency, because of the almost moralistic way our design education teaches us to think of consistency as being inherently virtuous. In design critique we heard “y is inconsistent with x!” as a failing of a piece of design instead of more considered questions around the best way to match user knowledge and to meet user needs.

Consistency as thought-terminating cliche

The danger is when “our design must be consistent!” becomes what the psychiatrist Robert Jay Lifton called a “thought-terminating cliche” — when a commonly-used phrase is deployed in a manner that looks like an argument, but actually shuts down rational discussion.

Phrases such as Damned if you do, damned if you don’t or Now is not the time exemplify this, as do conspiracy theorists when they say trite things like “Trust the plan”. Instead of examining the sort of consistency we should be optimizing for (internal/external/visual/functional?) or whether consistency really helps us to meet user needs in a situation, it suggests that we unthinkingly remove any identified inconsistencies because consistency = good.

Consistency is a means and not an end for design

At the risk of using another fatuous cliche, we need to think of consistency as another tool in our toolbox to deliver effective, usable experiences. Sometimes an internally consistent experience will be the best way to match user knowledge and help users achieve their goals. And sometimes an externally consistent experience will be the answer, and sometimes something totally novel will be the best solution instead.

Having said this, we must balance optimizing for user needs and knowledge in every interaction, along with ensuring we have some level of internal and external consistency. The outcome should not be completely different interfaces, patterns, and styles for every interaction. We do need to factor in the development cost of inconsistency. Consistent, reusable design patterns result in consistent, reusable code. Consistency is one of a set of tools we may consider and optimize when making design decisions, and excessive, reductive focus on any one factor can lead to worse outcomes.

There are probably good reasons for the swipe actions across iOS apps being inconsistent. Sometimes the swipe action outright deletes an item, sometimes it merely removes it from a list, hence the different language. Emails in lists tend to be much taller than most other list items, hence the use of an icon + text is better to fill the space. The general pattern of a swipe and then some color-coded actions are consistent, but the designers balanced the design by considering more things than just consistency to deliver a better experience for that situation.

Atlassian’s own design principles recognize the reality of this. One of our design principles is:

Match purpose and feel familiar

Our products are individually fit-for-purpose as well as collectively harmonious, with each other and other products that people use. Although there’s a persistent visual and behavioral similarity, they adapt to people’s devices and contexts, rather than being consistent for the sake of consistency.

Are we balancing the expectation that learned behaviors will carry across products, with the need to adapt appearance and functionality to be more effective?.

With consistency, as with all things, the poison is in the dose. Moreover, consistency is not virtuous in and of itself. It’s a core design principle that’s essential to delivering a great experience to users. Taken too far, or in an overly reductive manner, it can displace serving user needs with building a consistent system for the sake of it.

So the next time you fret about consistency in your or another’s designs, instead ask what the user knows and is trying to achieve, and then discuss what measure of consistency best helps you to achieve those goals and if this case warrants a little inconsistency. As long as the inconsistency is internal it may well be justified. This might not look as good lined up in your Figma files but will help you to better support your users.

--

--

Mark Parnell
Designing Atlassian

Product designer @Atlassian. Sydney-based pedant and recovering laowai.