Categories

Social

Sponsored by

What’s Your Idea of a Mental Model?

“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.”

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.

Conclusion

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.

Scott McDaniel is a user-centered designer with Cognetics Corporation. He has more than seven years of experience in designing and documenting software, networks, and telecommunications systems. As a designer, he helps establish vision and direction for products, researches prospective users, determines requirements, and provides detailed designs and specifications for both software and web. Scott first discovered usability upon joining the Society for Technical Communication as a novice technical writer. After several years of applying user-centered design methods to documentation, he made the switch to user interface design.

Share this:

Scott McDaniel

is a user-centered designer with Cognetics Corporation. He has more than seven years of experience in designing and documenting software, networks, and telecommunications systems. As a designer, he helps establish vision and direction for products, researches prospective users, determines requirements, and provides detailed designs and specifications for both software and web. Scott first discovered usability upon joining the Society for Technical Communication as a novice technical writer. After several years of applying user-centered design methods to documentation, he made the switch to user interface design.
In his off time, Scott plays the doumbek (a Middle Eastern drum), plays and designs games, and doesn't have enough time to watch all the movies he'd like. He definitely recommends looking at the user interfaces in Minority Reportquite fun! View all posts by Scott McDaniel

14 thoughts on “What’s Your Idea of a Mental Model?”

I am assuming that this debate on mental models and conceptual models does not have an expiry date.

I consider mental models to be broader in scope than conceptual models. Hence, I would like to propose that conceptual models are mental models that are transposed on the system or interface. In other words, a mental model that is now bounded by what the system makes visible or implies in terms of tasks/goals that can be completed, and how to go about doing them.

I hope this explanation compliments the comment made just before this one.

Not sure that getting a mental model down on paper in this fashion is very helpful from the point of view of trying to get users to “transition” over to a target mental model.

I’ve never encountered a user that would switch their mental model when told what to do, or “adopt” a different mental model than what they already have when they use a product. They just do what they want, think what they want, and that’s usually all there is.

Their mental model of the product is far different than mine would ever be, and there’s not much I’m going to be able to do to change that, and one could argue I should NOT attempt to change it. (What right do we have to try and get people to think differently? Just a thought.)

However, I do agee that understanding their mental model is useful in that I can try to bridge the gap to keep what I know to be true in the product, but make it *appear* like something they can relate with in their mental model.

Bridging the gap to give users something to hang their hat on is what mental models are for imho. Transitioning them over to a new one sounds like a task where I want to pound my head agaisnt a wall.

Consider one case in point: the whole desktop metaphor for the OS. The original UI designers from XeroxPARC and Apple created icons to represent folders to give users a bridge into what a hard disk and file system does. Do the users of computers REALLY understand what is happening at the OS level with the file system, how the code saves files, where it points, how it store the data, etc? No. But they can relate to folders because it fits their mental model of how they work in the office.

This is a case where you as the designer bridge the gap. Maybe its semantics, but I don’t think you ever want to try and bring people over to your target mental model. But you do want to find way to brdige the gap between what you know is going on in the product at the engine level to something the user can relate to in their own mental model of what is going on.

Karl asked about the difference between mental and conceptual models. I tend to use “conceptual model” to mean the high-level definition of a user interface. Used this way, a UI’s conceptual model includes:

1) Architectural diagram of the UI, showing major screens and their relationships.

2) Screen layouts for key screens.

3) Target mental models of the UI or the major objects (from the user’s perspective) in the UI.

4) Graphic design for the UI.

Mental models, then, are one aspect of a larger conceptual design that also shows how those models are to be implemented in the UI.

Andrei questioned the idea of trying to document a designer’s mental model and then figure out how to transition the user’s mental model to it. I guess it depends on what we mean by “designer’s model.” A system designer’s model of the objects in the backend (execution threads, databases, etc.) is different from a UI designer’s model of the objects in a UI that a user should perceive. That model, which I’m calling the target mental model, will reflect the actual users’ models in a best case scenario. That’s not always possible, though, and understanding where the models differ can help mitigate usability problems.

In one of the projects on which I based the example mental models, we had a technical constraint that meant we had to have two different search screens, one for a document’s meta data and one for its full text. Since we couldn’t create a single search page, we were able to put instructions and a link on the meta-data search page to point people to the full text search page. A before and after usability test showed that the instruction and link was partially successful, but not completely. People still started down the wrong path, but then usually saw the note and got back on track. The real solution is to combine the search pages, but given the scope and schedule of the project it wasn’t practical. In that case, considering the mental models did help some.

I’ve felt for some time that “mental model” and “conceptual model” are largely terms used by the industry in an exclusive, jargonerific way.

What is the difference between a “mental model” and an “expectation”? I see very little, and have replaced my references to mental models with “expectations” when I’m talking with managers, developers, or clients.

As to where expectations come from, in rough order:

– past experience (skill level, use of similar systems, use of different systems, use of this system)
– environment (social & physical)
– the cues presented by the system

My first exposure to these terms was through Donald Norman’s “The Design of Everyday Things.” I understand (and still do) the distinction between mental and conceptual models to be point of origin: a mental model is the perception a user brings to an application, and a conceptual model is the background, overarching idea of how to realize a thing best to match this user’s mental model. So, in short: users have mental models, software designers have conceptual models.

Semiotics speaks to me when trying to understand this…kind of a sign/signifier/signified thing. True, it is jargon–but it’s important jargon within our community, I think. I’d expose this jargon less frequently outside of UX professional circles, probably.

About how to get at the mental model — One of the defining principles of user-centered design is that you base design decisions based on observed behavior, not stated opinion. I think Jenny is right that you can’t just ask a person what their mental model is or ask 2-3 “right” questions to fully reveal it. I’ve seen usability tests reveal mental models well, particularly when everyone makes the same mistake at the same place. Contextual inquiry can also get at mental models well. I’d also say it’s impossible to fully document a complete mental model — we’re just interested in those parts of it that lead people to make assumptions and behave in certain ways.

About expectations — “Mental model” and “conceptual model” are certainly jargon terms, and we need them for our own discussions. I’d also agree that we don’t need to expose everyone to them, and I like “expectations” as a close way to convey what we mean. To switch back to jargon for a moment, though, I think that the mental model is the thing that produces the expectation, not the expectation itself. Users might expect a UI to work a certain way, but the mental model explains why.

Perhaps a better way to think about this “target mental model” is not so much something that we want to bring the user into compliance with, but rather the standard set of assumptions, terms, visual representations, and processes that we will use in the software. Ideally, we will base this on the users’ actual mental models, but sometimes we won’t be able to do that. In such cases, we will know where the users’ mental model differs from what we’ve set down as the UI’s standard model. An understanding of that difference will help us better target the training, documentation, tutorials, instructions, and error messages.

I may be getting a little off-topic here, but I am having some trouble convincing myself that we do users justice by creating for them, or having them tell us about their mental models of a project.

In the original article, Scott writes:

“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.”

What I am having trouble getting my head around is what a concise, user-defined mental model should look like. From the statement above, it would appear that the assumptions about the product are still driving the mental model that we think the user possesses. Consider the fact that they should not, and in fact may not at all, think of their articles as being stored in databses at all.

The ideal solution may be more along the lines of allowing users to search all data transparently, and gracefully helping them to refine their searches for criteria that are either not present, or not relevant. The user’s mental model is probably more along the lines of a library catalog, where every book, journal, periodical and whatever else, is searchable on a few common attributes, regardless of whether it is oversized, stored on microfiche or whatever.

So, I guess I am left with some questions. How do we know when we have accurately portrayed a mental model? Is one model really all there is, or are there so many potential models with equally applicable ideas that it is difficult to select a forerunner or two?

Just my $.02, and I hope it is not too far off the mental model track.

One of my big troubles (and I recall Peterme asking this question ages ago) is: what does a mental model look like? How is it physically drawn/written/articulated on paper so that people can grasp it? For content-heavy sites, I like the solution that Adaptive Path eventually came up with, a sort of heirarchical bar chart thing that is really pretty clear and easy to understand.

I’ve seen mental models drawn as overlapping circles, flowcharts, or other diagrams, and I’ve seen them written as text.

It’s important to distinguish between the conceptual model – a description of what the application, site or service does – and a mental model – a description of how the application, site, or service is structured.

As the most abstract level of the interface, the purpose of the conceptual model is to leverage the user’s experience from the physical world to enable them to form accurate and useful expectations about what type of functionality or content is available. It helps them answer the question, “is this thing a store, a brochure, a newspaper, a reporting system, or what?”

Despite their abstract nature however, conceptual models invariably represent real world objects and experiences. For example, blogs are a like a diary, iTunes is like a jukebox, Microsoft Word is like a typewriter, and an ATM is like a bank teller. Although none of these models tell the user how something is likely to be organized or structured, they do tell them what types of transactions, features, objects, and capabilities are likely to be present.

By contrast, a mental model describes how a user expects a particular system or service to be organized. It helps them say, “Given that this thing is a store, I expect there to be a place dedicated to product X, a space for product Y, and a place to complete my transaction.” Of course, mental models are intensely individual things, varying from one user to the next. Therefore, a significant challenge is to discover the various mental models and then find consistent and predictable ways of reconciling and expressing them as a single, coherent information architecture.