As usability and design professionals, we often use the term “mental model” loosely. Part of the problem is that there isn’t a clear English definition, though there are several serviceable academic ones (for some examples, see Johnson-Laird, Girotto, and Legrenzi’s introduction and Martina Angela Sasse’s excellent Ph.D. thesis on the subject).
Even in these works, however, mental models aren’t defined more specifically than a mental representation of something. How, then, do you tell people in other disciplines, such as managers or developers, what they are? I often use examples to convey what a mental model is. If I tell them that I recently ordered a steak at a restaurant, they might assume that I was met at the door by a host or hostess, seated, and presented with a menu. They assume these details, and others, that I never actually mentioned because they have a mental model of how restaurants operate. To illustrate the consequences of having a mismatched mental model, I describe a person who goes into a buffet restaurant and waits for someone to take their order. The person’s mental model of how that restaurant operates doesn’t match the actual situation, and he would experience confusion and frustration until he modified his original model to include buffets.
Defining mental models by example is not sufficient if we want to treat them more formally, however. All mental models have a few key characteristics:
- Mental models include what a person thinks is true, not necessarily what is actually true.
- Mental models are similar in structure to the thing or concept they represent.
- Mental models allow a person to predict the results of his actions.
- Mental models are simpler than the thing or concept they represent. They include only enough information to allow accurate predictions.
But how are mental models constructed? We need to know the parts that each mental model contains if we are to document them correctly.
This article proposes a formalization for mental models. This formalization is still in its infancy—I have not yet used it on a major design project. I’m hoping it will stimulate discussion and feedback about mental models and how we use them. It is also designed to be practical, however, and it can be a useful way to describe users’ perceptions and expectations during the design process.
Why do we need to document mental models?
Mental models should serve as an analytic tool, allowing us to clearly document users’ current mental images, vocabulary, and assumptions. Once the mental model is documented, we can create a target mental model—the model of the product that we want our users to have. If there is a difference between the two, we can design the UI and user assistance material to transition users from their current models to the target model. Additionally, we should be able to provide clear and credible specifics when we tell our colleagues that there is mismatch between user and system mental models. This formalization lets us do that.
We can portray mental models using several key parts:
- An image (needed if the mental model is of a physical thing)
- A script (needed if the mental model has a process)
- A set of related mental models
- A controlled vocabulary
- A set of assumptions
An Image. If the mental model is of a physical object, the model should contain a simplified image that serves as a template for that object. Consider a graph. For most people, it has a vertical and horizontal axis, representing the upper right quadrant of a Cartesian plane. There are probably labels near each axis. There may be a legend. The “content” part of the graph may consist of lines, data points, bars, or other visual things that show a relationship among data on two dimensions. We can easily represent this type of mental model as a schematic diagram. It doesn’t include every last detail of what might appear on a graph, but only the essential things that would lead someone to identify it as a graph.
A Script. If the mental model is of a process, it should contain some sort of description of that process. The best way to present the script will vary—it might be a series of steps expressed verbally, a flowchart, or a decision tree. Perhaps a finite state diagram works best. Let’s consider the process of creating a graph from a spreadsheet. First, you might check to see if data has already been entered. Assume it has. You then create a graph and tell it in which rows and columns to find the data. If the spreadsheet application’s designers wanted it to be helpful, it might take a guess at the axis titles based on row or column labels for the data spreadsheet or database. Then, you have to choose the display style (line, bar, etc.) and choose any other settings there may be (background color, graph title, legend details, etc.). Maybe you want to pull in data from other sources too. Finally, you’ve got the thing looking the way you want. Does it show a useful relationship? Does it solve the problem you are trying to solve? If so, you might want to polish it up and use it in a report. If not, you might want to change settings, add or remove data, and so on. Scripts may be the same as task models, though they show a person’s expectations and beliefs rather than the true process.
Related Mental Models. Mental models are composed of other mental models. We can quickly get lost in a fractal mindscape, wondering where to begin and where to end. The art of documenting a mental model is choosing the right representation and showing how it relates to other models. For a particular model, list the two to four most important mental models that are its building blocks, and then list the two to four mental models for which it is a building block.
Take the car. A typical commuter has a mental model for personal transportation that includes her car, but may also include a bus system, subway line, network of friends with cars, etc. If she were a fleet manager for a police department, however, the car would also be a key building block of her fleet. Selecting the right related models shows designers how users think and relate to their larger context.
Controlled Vocabulary. Each mental model has a set of key definitions and variants. Information architects and librarians are adept at creating controlled vocabularies, and mental models should contain a small controlled vocabulary (see “What is a Controlled Vocabulary?” for a good primer on the subject). The model of the nuclear family has a set of definitions that include mother, father, and child. Each of these terms has a set of alternates, however. Define each term and state other terms that can be used for them. A mother, for example, is the female parent. Other terms used for mother include mom, mama, and ma. If it is important to the mental model, include any subtle variations in meaning for these alternates. If you document user mental models during analysis, the terms you identify and define can form the basis of the standard terminology for the product’s UI.
Assumptions. Mental models contain assumptions that allow people to predict behavior. Carrying forward the model for the nuclear family, we might assume that if the child misbehaves, one of the parents disciplines the child. There may be further assumptions about the method as well. There could easily be thousands of assumptions for a given model. The key is to state only those assumptions that affect the product at hand.
Using the formalization
The two mental models shown here are based on a combination of recent projects (I have modified the models involved somewhat). The first shows a user’s interpretation of an academic article while the second shows the system designer’s model for an article. The system’s model for an article includes two separate databases, one for the article’s metadata and one for the article’s full text. This solution was a compromise because including everything in the same database caused searches to take too long.
Many parts of these mental models are the same. There are some terminology changes, but the key difference is highlighted in the models’ assumptions. Users do not make a distinction between the back-end databases and presume that articles are stored completely in a single online catalog. This difference affects the Scripts shown. Because the databases do not have fields in common, the system needs a separate search page for each database. Users, however, will have trouble making this distinction and will expect to see only a single search page. The ideal solution to this problem is to restructure the databases so they can both be searched from the same search page. If that is not possible, the designers must help users develop a new model of the search interface through a combination of instructions, tips, and clear error messages and results pages.
Since this formalization is, in effect, a model of mental models, it does not necessarily include every aspect of an actual mental model. This method for documenting them includes only those details we need to conduct our analysis and complete our design. I see this technique as being similar to that of developing personas. Both are short, perhaps one or two printed pages. For any given project, there should usually be one or two major personas and perhaps a few more supporting personas. Similarly, there should be only a few mental models for a UI and perhaps a few more supporting ones.
We should create these mental model descriptions during user analysis to document users’ current understanding. Then, during a design phase, we should create the target model to show the mental model we want users adopt. Comparing the current and target models, we will be able to guide the users’ transition from one to the other, if necessary.
I’m looking forward to using and refining this formalization for mental models further, and I welcome any criticism and critique. My hope is that a tool like this can help us clarify our thinking about mental models and incorporate that thinking into our information architecture and UI design projects. We can then begin to use mental models with more certainty and conviction, including them in our design process in the same way we use personas, navigation architectures, and use cases.