Mental models are one of the most important concepts in human–computer interaction (HCI). Indeed, we spend a good deal of time covering their design implications in our full-day training course on User Interface Principles.

Here, I'll report a few examples from our usability studies. Not coincidentally, using concrete examples often helps people understand abstract concepts (such as "mental models").

First, though, you have to suffer one bit of theory — namely the definition of mental models. A mental model is what the user believes about the system at hand.

Note the two important elements of this definition:

  • A mental model is based on belief, not facts: that is, it's a model of what users know (or think they know) about a system such as your website. Hopefully, users' thinking is closely related to reality because they base their predictions about the system on their mental models and thus plan their future actions based on how that model predicts the appropriate course. It's a prime goal for designers to make the user interface communicate the system's basic nature well enough that users form reasonably accurate (and thus useful) mental models.
  • Individual users each have their own mental model. A mental model is internal to each user's brain, and different users might construct different mental models of the same user interface. Further, one of usability's big dilemmas is the common gap between designers' and users' mental models. Because designers know too much, they form wonderful mental models of their own creations, leading them to believe that each feature is easy to understand. Users' mental models of the UI are likely to be somewhat more deficient, making it more likely for people to make mistakes and find the design much more difficult to use.

Finally, mental models are in flux exactly because they're embedded in a brain rather than fixed in an external medium. Additional experience with the system can obviously change the model, but users might also update their mental models based on stimuli from elsewhere, such as talking to other users or even applying lessons from other systems.

Remember Jakob's Law of the Internet User Experience: Users spend most of their time on websites other than yours. Thus a big part of customers' mental models of your site will be influenced by information gleaned from other sites. People expect websites to act alike.

Mixed-Up Mental Models

Many of the usability problems we observe in studies stem from users having mixed-up mental models that confuse different parts of the system.

For example, the word "Google" is usually the top query at other search engines, and words like "Yahoo" and "Bing" score high on Google. Why, oh why, do people search for a website if they already know its name? Why not just type, say, www.bing.com into the URL field?

The reason is that many users have never formed an accurate model of how the "type-in boxes" on their screen function. When they type stuff into a box, they sometimes get where they want to go. What to type where and exactly how each type-in box functions, however, are often beyond their ken.

The inability to distinguish between similar type-in boxes is a key reason for the guideline to avoid multiple search features. When a website or intranet has several search engines on the same page, users often don't know the difference. They'll enter their query into whatever box catches their fancy and assume that the site doesn't have the answer if nothing comes back. (In reality, they might have used a specialized search that didn't cover everything.)

The one exception to this guideline is that it's preferable to have a separate search on intranets for the employee directory, because in most users' mental models, finding a colleague's contact details doesn't constitute "search." It's looking up a person, not searching for information. In contrast, of course, any developer mentally models the employee directory as one more database and a phone number as a piece of data. As I said: users and the design team have very different mental models, and you have to understand the users' model to design something that works in the real world.

Users don't just confuse search fields; many less-techy users don't understand the differences between many other common features:

  • Operating-system windows vs. browser windows
  • A window vs. an application
  • Icons vs. applications
  • Browser commands vs. native commands in a web-based app
  • Local vs. remote ("cloud") info
  • Different passwords and log-in options (users often log in to other websites as if they were logging in to their email)

Mental Model Inertia

Netflix started as a mail-order service for renting movies on DVD. However, Netflix worked differently than typical e-commerce sites, which caused problems when we tested it with new users in our project about famous sites' usability:

  • When users added a film to their Netflix "queue," they used a mental model of an e-commerce shopping cart to predict what would happen: nothing. Adding stuff to the cart doesn't cause you to receive that item in the mail. You first have to proceed through checkout and confirm that you want it.
  • In reality, however, Netflix will immediately mail you the DVD that's on top of the queue. Later, when you mail it back, they'll send you the next movie in your queue, without you having to go to the site and do anything. That's why they have the "queue" feature instead of a standard shopping cart.

There's great inertia in users' mental models: stuff that people know well tends to stick, even when it's not helpful. This alone is surely an argument for being conservative and not coming up with new interaction styles.

On the other hand, sometimes you do need to innovate, but it's best to do so only in cases where the new approach is clearly vastly superior to the old, well-known ways. Netflix is obviously a successful company, and its innovation of sending customers a steady stream of movies from a queue was a major reason for this success.

When you do something new on the web, you face an immense design challenge: How do you explain the new concept such that users have a living chance of constructing a valid mental model of the site?

It's amazing how one misconception can thwart users throughout an entire session and cause them to systematically misinterpret everything that happens on the site. Through failure after failure, they never question their basic assumptions. This is yet another argument for complying with preexisting user expectations whenever possible. If you don't, then make certain that you're clearly explaining what you're doing — while also realizing that you face the added challenge of users' reluctance to read very much.

Acting on Mental Models

Understanding the concept of mental models can help you make sense of usability problems in your design. When you see people make mistakes on your site, the reason is often because they've formed an erroneous mental model. Although you might be unable to change the UI at that point, you can teach users a more accurate mental model at an earlier stage of the user experience. Or, you might have to acknowledge that users won't understand certain distinctions and then stop making those distinctions.

In case of a mental-model mismatch, you basically have two different options:

  • Make the system conform to users' mental models — assuming most models are similar. This is the approach we usually recommend to fix IA problems: If people look for something in the wrong place, then move it to the place where they look for it. Card sorting is a useful way to discover users' mental model of an information space so that you can design your navigation accordingly.
  • Improve users' mental models so that they more accurately reflect your system. You can do this by, for example, explaining things better and making labels clearer to make the UI more transparent (even though the underlying system remains unchanged).

Mental models are a key concept in the development of instructions, documentation, tutorials, demos, and other forms of user assistance. All such information must be short, while teaching the key concepts that people need to know to make sense of the overall site. It's sometimes worth trying a short comic strip; research has shown that mental-model formation is enhanced when concepts are simultaneously presented in both visual and verbal form.

One of the main reasons I like the thinking aloud method of user testing is that it gives us insights into a user's mental model. When users verbalize what they think, believe, and predict while they use your design, you can piece together much of their mental model. There are also more advanced knowledge-elicitation methods for gaining deeper insights into mental models, but for most design teams, a few quick think-aloud sessions will suffice. In any case, simple user testing is certainly the first step to take if you suspect that erroneous mental models are costing you business.