A version of this originally appeared in Issue 045 of my UX Writing Events newsletter.
When reviewing or critiquing design work, it’s so, so, tempting to see something different…a different word, a different phrasing, a different pattern…and want to “fix” that difference. But making things consistent just for consistency’s sake sometimes leads us to the wrong choice.
When you allow an impulse to make things “the same” replace your critical thinking skills, you’ve fallen into something I call the consistency trap.
Every designer is at risk of falling into the consistency trap, but I find that UX writers and content designers are especially at risk. Making things “the same” as a UX writer or content designer – identical labels on buttons, starting like headlines with verbs, always using the same exact same word for the same idea – often feels like the right thing to do. The design becomes “simpler”, stuff looks and feels more aligned, the reading-ease score improves, and so on.
But what if making those button labels the same leads to one of them not-quite-accurately describing what the button does? (Here come the support tickets!)
What if we use the same pattern for every headline so consistently that readers to start to skim over them and miss critical pieces of information?
What if by using the exact same words every time, we miss a chance to connect with a reader’s mental model by using additional words they might be more familiar with? (Not to mention running Google searches for…)
Your job as a designer – especially a word-focused designer like a UX writer – is to stay mindful and critical and evaluate each individual design choice, including word choices, being made. Don’t match things just to match them. Think. Think!
Consistency is a by-product of a well-oiled design process.
True consistency happens at the conceptual and operational levels, not the execution level.
You can’t force consistency at the end of your design work by using the same words and the same UI components … those components have to actually work consistently and consistently refer to the same things.
For instance: If a set of buttons can all be accurately labeled to read Disconnect, that should be because every single button in that set does exactly the same thing – disconnect something! And your reader should know exactly what Disconnect means. But if three of your buttons disconnect, while the fourth merely pauses something, or unsubscribes … well, it should probably say that, instead!
Why do design teams fall into the consistency trap?
I’m sure there are many causes, but these three have happened the most often in my own experience.
You have a bird’s-eye view of the experience. Users don’t.
Your view of the experience probably doesn’t match the user’s view of the experience. For instance, although you’re looking at three versions of the same screen in Figma that appear based on different prompts or flows, a given user will only ever see one of those versions of the screen. That means that differences in language and phrasing between those screens aren’t actually “inconsistent”, just distinct … purposefully so, hopefully!
A formal design critique process that requires you to walk through the experience screen-by-screen can mitigate against this to an extent. But at the pace many design teams operate, we’re often reviewing things asynchronously or in lighting-quick review sessions where everything is on-screen at once. So we have to be careful.
Before you drop a comment about something being inconsistent, remember to check against how it will really come across to users, and what they’re seeing in what order. The inconsistency you perceive might not really exist.
Consistency might not mean what you think it means.
Consistency gets thrown around a lot as a design principle. It tops many lists of “best practices” for UX writing by new UX writers trying to summarize what they’ve learned so far. That’s very understandable — often, the first important impact that a UX writer can bring to an organization’s product is the clear and consistent application of feature labels.
But the thing is, consistency doesn’t get established at the UX writing level. Consistency is more of a product and design-systems level consideration. Your job as a UX writer is just to not mess it up. Consistency means that we say what we mean and mean what we say, that components that resemble each other operate in similar ways, that buttons and links do what we expect and take us where we want to go.
But it doesn’t mean, has never really meant, make everything the same. Consistent is not a synonym for identical.
So again, the consistency trap happens when we turn our brains off … but if we’re staying thoughtful and critical, we’ll remember that making everything identical can actually prevent us from being consistent!
(We would also do well to remember that a “best practice” is a last resort, not a first step. What you write and how you label things in an interface should be derived from a design process, not some sort of consistency-focused copyediting pass independent of any larger design conversation. “Because some guy on Medium said to” is not a persuasive design argument.)
Stakeholders have to comment on something.
Humans are pattern-matching machines, and supposed “inconsistencies” are one of the the easiest things for stakeholders to spot when giving feedback. This is natural, and something you should be ready for. Your word choices should be design choices, not arbitrary, and something to be defended (or thoughtfully abandoned) like any other design choice.
How do you avoid the consistency trap?
It’s not easy – I still fall into it from time to time. Still, there are a few methods I’ve picked up over the years that can help:
Exercise self-control. – Now that we all know that consistency is not inherently virtuous, we have to find deeper and more nuanced questions than “Why is this different?” Change starts with you!
Review flows, not just screens or frames. – I see a lot of design documents that seem to be engaging in some sort of minimum viable specification competition … each single state or mode represented with but a single frame, with no connection drawn between them. This seems like a silly practice to me when it’s so easy in tools like Figma and others to duplicate frames and screens and organize a view of each given flow in a design. Reviewing the words and UI components in a given design as part of a flow will give you a view that more closely resembles the experience your users will have, and minimize false-positive inconsistencies.
Include preferred and allowed synonyms in your writer’s guidance. – Stakeholders generally mean well when pointing out supposedly inconsistent word choices. Having an established glossary or other vocabulary document with approved synonyms can help you back up your choice in any moments where one of the already-approved synonyms seems to fit a bit better.
Stick to your guns. – If you’re in the writer’s chair, you might find yourself with feedback coming from all sides pushing you to make things “simpler” or “more consistent”. You’re going to need to pull those shoulders back and use a little backbone in these situations from time to time. It’s really easy, and tempting, to say, “Sure, we can make those the same.” But remember that you aren’t there for your stakeholders … you fight for the user!