Word Choices and Language in UX, Part Two: Information Architecture & Personas
On November 28, I gave a presentation to UX Winnipeg on the impact of word choices and language on the user experience, and how we can create better user experiences through the better use of language.
- Part One: Introduction & the Meaty Bits
- Part Two: Word Choices and Language in Information Architecture & Personas
- Part Three: Word Choices and Language in User Interface Labels & Messages
Language in Information Architecture
In Part One, we looked at how words are really powerful symbols with the power of evocative expression, categorization, and conceptualization.
Now, let’s explore how this plays into defining information architecture:
It’s a trap.
Here’s why: people satisfice. All the time. We’re energy-intensive creatures and our bodies and minds have evolved to exert as little energy as possible to get things done.
We’ll go with “good enough,” even if “good enough” is wrong.
When our users go through their Perception-Action Loop, they construct invariants: things in their environment that don’t change, that can be used as a basis of understanding for everything else.
Gravity exists. The sky is up. A red ❌ in a small box at the top corner of a tab closes that tab. These are invariants. Everything we know about how things work and everything we intuit about how things will work is built on top of these invariants. They’re our foundations of understanding.
If users build the wrong invariants, they build the wrong understanding of how things work.
Our products and experiences are full of really powerful symbols — words — that our users rely on to build their mental models. If we use the wrong words, our users will build the wrong invariants. They’ll have a flawed understanding of our product.
This can have serious, long-term consequences on the user experience, because it’s really, really hard to change invariants after they’ve already been formed.
Here’s how we can nail the information architecture from the start by deliberately finding and using the right words:
1. Talk to users
Talk to your users. Learn their workflows and routines. While you do this, pay particular attention to what words they’re using to describe what they’re doing, or want to do.
We’re very rarely making entirely blue-sky products that create and solve new user needs. We’re most likely helping users get something done that they were already doing using some other product or process.
“…then I submit the report…”
The words they use to describe what they’re doing are very indicative of the mental models they’ve already formed. If you talk to ten users, and all ten users use the phrase, “Then I submit the report,” it’s probably a good idea to call reports “reports” and letting them “submit” those reports.
2. Talk to stakeholders
Like users, stakeholders will have their own vocabulary. They may also have a position on the front lines where they may hear the words their users are using.
Paying attention to the words that stakeholders use is a great way to identify language common to both users and the project team.
3. Do card sorts
Card sorts are a brilliant technique for involving users in defining the information architecture based on their own mental models.
To carry out a card sorting workshop, write different terms and information (types of content, pages on your website, etc.) on index cards, and ask participants to sort the cards into groups that make sense to them. After they’ve done this, ask them to give each group a label.
4. Do a competitive language audit
What words do your competitors already use? If it’s a successful product, there’s probably a good reason they chose those words.
By using similar words, you can “piggyback” on top of existing mental models, and make switching to and adopting your product easier for your users. They won’t have to learn how to use it from scratch.
5. Document language and words
Make language frameworks as part of your workflow for information architecture and strategy.
To create a language framework, identify all of the entities that exist in your product, and all of the actions that the user can take.
This is an example of a simplified language framework for a theoretical classroom application. It has courses, which have both waitlists and quizzes. Quizzes have questions, and questions have answers.
Each of these entities has actions associated with them — you can join or leave a waitlist, or take or re-take a quiz.
Once words have been defined within a language framework, it’s important to use those words consistently. If you decide that a quiz can be taken, avoid saying that a quiz can be started.
A language framework is a great artifact that can be shared with the entire product team to both create a shared understanding of the product and create consistency in word choice and language.
6. Test the language
See how real users respond to the information architecture as early as possible. You won’t know for sure whether you’ve got the right words until you see users interact with them.
7. Don’t change the words!
If the information architecture or mental models for your product haven’t changed, don’t change the words you’re using. Your users built invariants — their foundations of understanding—around those words, and changing them can easily cause confusion.
8. Change the words!
On the other hand, if the information architecture or mental models for your product have changed — perhaps you introduced a new feature or a feature outgrew its original label — change the words! This can help users revisit their mental models, because it’s very clear that something is different.
It’s important to make sure that new words are distinctly different from the old words, or users may not notice. It’s also a good idea to tell users exactly what changed, and why.
Language in Personas
We use personas as a tool for building empathy with our users. Challenge is, empathy can be hard.
Sometimes we just don’t want to empathize with our users.
Maybe we think they’re being obtuse. Maybe we’re cranky.
When we think our users are being obtuse or we’re cranky, weak personas don’t help, because we don’t (or don’t want to) empathize with them.
We can create personas that make it easier to empathize with our users by remembering that words give us the power of evocative expression — they’re inherently emotional.
We associate positive and negative emotions with specific words. We can often use two different words to describe the same thing, but one of those words will be inherently positive, while the other will be inherently negative.
Take, for example:
“John is cheap.”
“John is thrifty.”
“Cheap” has negative emotional connotations. We don’t want to empathize with “cheap” John. “Thrifty,” on the other hand, is positive. We find it much easier to empathize with “thrifty” John.
Here’s some other examples:
- Loudmouth v.s. Outgoing
- Cowardly v.s. Cautious
- Old-fashioned v.s. Traditional
- Scattered v.s. Busy
- Single-minded v.s. Focused
- Careless v.s. Distracted
(Have more examples? Share them in the comments! I’d like to build up a list.)
Here’s how we can deliberately choose words to make better personas:
1. Pick good words (🙄)
Choose words deliberately when writing your personas. Make an effort to find positively emotional words.
2. Update existing personas
Go back and look at your existing personas, and find negatively emotional words that can be changed into positively emotional words. Do it. It’s an easy way to make things better.
Tell your team what you changed and why.
3. Humanize phrases
Keep making it easier to empathize with your personas by humanizing phrases. Cut down on the stale business-speak. Consider which of these examples sounds more human — and easier to empathize with:
“Not good with money.”
v.s.
“Hasn’t developed strong fundamental saving habits.”
Good word choices are critical when defining your information architecture, so that you can avoid the trap of your users developing the wrong invariants. Get it right from the beginning, and you’ll help your users build a strong foundation of understanding. It’s also easy to make small changes to the words you use to make more effective personas.
In Part Three, we’ll explore word choices and language in user interface labels and messages.
Keep reading:
Thanks for hitting the 👏 if you enjoyed this article!
Quinn Keast is a UX Designer + Partner at Caribou, a user experience strategy and design consultancy in Winnipeg.
