Skip to Navigation | Skip to Content

Mental Models

Aligning design strategy with human behavior

Mental Models

The "Mental Model" Wins

Remember my query back in September, "Should I call it a Mental Model or an Alignment Diagram?" Well, I am remiss in announcing the results... early this year we made the call to stick with the phrase "Mental Model." There has been an explosion of definitions for the term in the past ten years, so my use of it shouldn't rock the cognitive science/psycholog boat too much.

So, this means that we're changing the name of the book from "alignment diagrams" to "mental models." The former title was the result of a few people worrying that "mental model" might be too overloaded with meaning. It was a challenge to come up with the phrase "alignment diagrams," and it has been a challenge to remind myself to use that term instead of what comes more naturally. So, to be honest, I'm relieved that we're switching back to "mental model."

We will change the title of the book page soon.

Comments

I see you have decided to call this a mental model, instead of an alignment diagram. This seems to cause some consternation among the UX community, in that a diagram mapping tasks is not really a mental model, the process in the user's head is really the mental model, but the deliverable is more of a task analysis document.

I'm trying to work how using these techniques can fit into our user centered design process. Calling the end deliverable a mental model doesn't seem to quite fit.

I wondering how you see it - is it more the process that is mental model mapping per se, and then the deliverable is actually an alignment diagram? I know this might be splitting hairs, but since I am new at my position and trying to instill good habits for UCD in our company I want to get it right.

We're also creating one-sheeters to explain to the organization what each deliverable is (such as personas, wireframes, usability testing, etc) and I'm stuck on how exactly to communicate this one.

Thanks! Looking forward to the book.

Tom

Among cognitive scientists, there are many definitions for the term "mental model." Only one of those definitions is "mental models are the users understanding of how a system works," as Nathan Kendrick states in the thread at IXDA. (I was an a couple of working sessons with Nathan at Wells Fargo a while ago.) The mental model diagram here represents the throughts, actions, philosophies, and emotions of someone going to the movies. I do use the word "task" to indicate the small square boxes in the towers, but only because I need one word instead of four to name it. I'm not terribly picky about definitions of --am much more of a generalist. So "task" is close enough for me, since it represents the "action" part of the concept.

There is another discussion on this site where we debated "mental model" versus "alignment diagram," and I also conducted several surveys over the course of last year. People were pretty much 2 to 1 in favor of calling it a "mental model" despite what the academics might say. Then some academics let me know that the term "menal model" had sprouted several definitions as it has been evolved by cognitive scientists over the past decade. So we decided to stick with "mental model" as the name. "Alignment diagram" would have worked, and so would have something like "experience model." People who have been making these diagrams prefer to stick with "mental model."

So your one-sheet definition for a mental model diagram can say that the top half of it represents a persons actions, thoughts, philosophies, and emotions. The bottom half of it represents the ways your organization serves (or doesn't serve) those concepts. The diagram as a whole acts as a touchstone that your team returns to, say every quarter, to prioritize design projects and double check that decisions are in accord with the strategy your organization follows, which is represented as the proposed (and purposely not proposed) solutions on the bottom half of the diagram. Also nice: a mental model doesn't shift very quickly, so these diagrams hang around for 10 years without much change. This longevity can benefit your organization as team members come and go.

Also for your one-sheets: I develop hypothetical audience segments in order to decide whom to interview for the mental model(s). Then, based on all the interview data, I refine/change these audience segments. Next, I sometimes develop them into personas. This is how "mental model" and "personas" fit together.

Thanks Indi, that helps quite a bit. The only part I'm fuzzy on is how you are speaking of the diagram in terms of the organization as a whole instead of in a project by project context, as an overarching strategy. You say "to prioritize design projects and double check that decisions are in accord with the strategy your organization follows".

I'm sure some businesses can define their user segments in that manner. But if user segmentation varies among different products/projects? For example, we have marketing sites that sell our product, then we have web applications that are used by our paying customers. There is a distinct set of users for each product. Yes, there is some overlap, but some pretty significant differences as well.

Would you do the exercise for both in that case?

Thanks

Tom

You're right, mental models are not built for a project, they are built for the people an organization serves. And you're right again that there are frequently distinct sets of users for the various solutions an organization produces. The very first part of the book outlines the importance of setting up task-based audience segments --or a hypothesis of what you think they are-- which are distinct from one another in terms of their mental models. (See my report on audience segmentation at Adaptive Path for more, or wait for the book to come out. It's possible the PDF version will be ready by the end of August.)

Distinct task-based audience segments will often have different mental models. Each mental model represents the beginning and end of a solution (or solution set) for that particular kind of person. I describe how these various solutions, when they happen to be web properties, can come together in the section of an essay at Adaptive Path called The Intranet Business Park.

So, yes, you would do an exercise--a mental model--for both audience segments. And if their mental models are distinct enough--some overlap, but not a lot--then you would create two distinct solution sets. To give you an example, for enterprise software companies, usually there is a separate web property for potential customers than for current customers. There is overlap in the mental spaces where both segments are looking at improving what they have, but customers need access to bug patches and tech support, whereas potential customers need access to people who can help them decide whether the product is right for them.

Post a comment

We’ve enabled comment moderation on Rosenfeld Media. Upon posting your comment, it will not immediately appear on this page. Hang tight, we’ll be sure to screen it before too long. (Starred fields are required)

Buy This Book:

Ordering Info

Within This Book's Site: