Communicating Mental Models to Your Team

‘Star Trek’ actor Anton Yelchin died last year at the age of 27 when a Jeep pinned him against a gate and brick pillar outside his home. Poor Anton apparently didn’t realise that the Jeep was in neutral when he got out, so it rolled backwards down the driveway, crushing him.

This accident was one of more than 250 related to confusion over the design of the Jeep’s gearshift. Many people thought the Fiat Chrysler gearshift, which looked like most gearshifts, should move up and down to shift into reverse, drive and park. That was their mental model. In other words, their belief about how it should work.

The gearshift, in fact, worked differently than most. It used push-buttons and always returned to the centre position. The fact that the gearshift’s actual functionality – otherwise known as its  “conceptual model” – was different than users’ mental models caused issues. Major ones in this instance.

In the field of user experience, we need to understand how users think so we can design with that in mind. When we understand people’s thinking, we can either design to match their current mental models, that is their beliefs about how things should work. Or, we can clearly educate people about anything that might differ from their expectations. We know this is critical to creating usable products.

This article will walk you through how to apply this idea to your own designs, covering:

• how to understand your users’ mental models in relation to your product
• how to represent them so the design team can keep those findings in mind
• how to translate what you know into designs that will work.

Let’s get started.

Understanding users’ mental models

The first step in understanding our users’ mental models is (unsurprisingly) research. Many research techniques such as interviews, observation and focus groups help us understand how users think about the world and products like ours. Let’s look at interviews as an example.

You’ll want to interview several users who have similar characteristics; in other words, those who you think are likely to use your product in a similar way. In an example from my past, my email marketing firm had a lot of users who were small business owners who didn’t have much time for marketing.

Some of our goals for the interviews were:

• to understand why they were doing newsletters
• how they created them
• pain points they encountered with our system
• how they wanted to feel when sending messages.

All of this would teach us about they understood the world of email marketing.

Write down whatever you want to learn and then come up with open-ended questions for your interviews. Start each interview with easy questions to make your participants feel comfortable, then move on to those that require deeper thinking. There are plenty of resources for tips on interviewing users. As a start, take a look at Cameron Rogers’ article right here on UX Mastery, or Steve Portigal’s book, Interviewing Users.

If you’re observing people work or conducting a focus group, it’s still helpful to determine ahead of time what you want to learn, which will help you focus your session.

Once you’ve completed your research, you should have a good idea of common themes, and how they experience your product and other similar products.

When I interviewed small business owners, I learned, for example, that they generally created their newsletters bit by bit because they were interrupted a lot. I also learned they were trying to stay on their customers’ minds, had lots of pain points with our system (things that didn’t work the way they expected or needed them to), and they wanted to feel smart and confident when sending their messages.

Representing mental models

By now, you’re starting to form a good understanding of this user group. Your next job is to put this information into a format that will help your designers consider these users’ mindsets. Again, you have several options, including personas, storyboards and mental model mapping. Let’s talk through how to use personas to represent mental models.

In my example, one finding was that the business owners had a mental model based on using Microsoft Word. They thought they could walk away from their work and return to work on it where they left off. In their work as small business owners, they often did need to step away frequently.

Unfortunately, this conflicted with the way our product – or conceptual design – actually worked. If you left for “too long” and the system shut down, you navigated to another page, you lost your work.  This caused much pain for users, who were devastated over losing their work. This even happened the usability testing environment test when it wasn’t even their work.

Our persona, Bob the Busy Business Owner, conveyed that there was a mismatch between the persona’s expectation and the software’s reality. The team then needed to decide whether to address this mismatch by meeting Bob’s expectation or by explaining the different model and how the interface worked.

When you create your personas, consider conveying their mental models – their beliefs about how a system will work – in the form of their current work habits, product expectations, issues, and quotes.

One quote that helped describe our Bob persona’s system expectation, for example, was “I need something where I can just plop in my copy and it works.” That helps the team understand that he’s busy, in a hurry, and in need of something that doesn’t require a lot of technical knowledge and fuss. In design discussions, make sure designers keep the personas in mind and address their needs. 

Instead of personas, you might decide to create storyboards or maps because you want to represent your users’ mental models more visually, or focus more on illustrating their ideal interactions with your product. That works too.

Creating conceptual models using mental models

And now the final step: applying what you know about your users to the design. In this case, it made sense to make the software match Bob’s expectation because he was in a hurry and not technologically advanced. It was important to prevent such critical errors. So that was our strategy.

The designers and developers worked together to create a system that automatically saved users’ work frequently, helping Bob to achieve his goal of feeling confident about his newsletters. To test how well this and other new design changes matched our users’ mental models, we usability-tested each iteration of the design and made modifications where needed.

When you understand how your users think, you can create intuitive designs for them. It just makes sense. If Fiat Chrysler had stuck with designing for a well-established mental model instead of veering in a different direction, the world would be a safer place today.

Up for some further reading? Here are more useful resources on mental models.

Books:

• The Design of Everyday Things by Don Norman
• Designing with the Mind in Mind, Second Edition by Jeff Johnson
• Mental Models: Aligning Design Strategy with Human Behavior, by Indi Young

Online Articles:

• Mental Models by Jakob Nielsen, Nielsen Norman Group
• The Secret to Designing an Intuitive UX by Susan Weinschenk, UX Magazine
• User Experience Design with Mental Models by Ross Johnson, 3.7 Designs Blog