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.

This question comes up now and then and I think it arises from our loose usage of these two phrases. How would you make the distinction?

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.

Andrei

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.

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

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