Constellation of some user-centered design steps. (No wonder it seems so hard to figure out where to start!)
Mental models are also useful for things other than design. Sales and customer service can use the data to understand clientele better. MBAs and information designers can re-format the data into workflow and process diagrams. Project managers can use it to prioritize among a set of development options. I encourage you to reach out to these people and introduce them to any mental models that you create.
Within the realm of designing solutions, mental models provide a nexus for all the other tools in your toolbox. You can draw benefits from using mental models to support your personas and scenarios. Mental models along with web analytics and use cases influence your interaction design concepts. Prototypes coming out of these concepts undergo usability testing to touch base with the user.
There are a few additional techniques that could flow directly into or out of a mental model. I’ll sketch these additional techniques here, and then dive into the main techniques later.
Input: Diaries
Diaries are a popular way to gather data in the user’s voice. You could ask participants who are, for example, members of Weight Watchers to write down their daily successes and frustrations with the diet and exercise program they are trying to follow. You can comb through this data for behaviors and create a mental model from this analysis. Diaries do have a tendency to flit from subject to subject, however, without deep examination of a topic. This tendency can leave you with a spotty mental model. But if you have this data, go ahead and mine it for your mental model.
Input: Field Visits
Field visits conducted by a professional researcher produce a much deeper understanding, and all topics within a scope are likely to be covered. In this respect, field visit data is better for task analysis than diary content. To create a mental model of the participant’s perspective, however, you will need to convert third-person notes into first-person behaviors. This translation is not insurmountable, and you will have a solid mental model as a result.
Output: Personas
According to Alan Cooper and Robert Reimann in About Face 2.0: The Essentials of Interaction Design, personas are user profiles that help the design team and other teams such as sales and marketing get more useful products into the hands of customers. If you review how they instruct you to write a persona, you will know to list experience goals, end goals, and life goals. The mental model focuses on the end goals (the things a person wishes to accomplish) and the life goals (the reasons why a person wishes to ccomplish something—the larger picture). You can use this data to adjust your original task-based audience segments[5] and go on to build personas out of each segment with photos, names, and experience goals.
Output: Scenarios
A time-honored practice is writing scenarios that describe how a persona accomplishes a goal using a set of tools. Once you have a mental model, you can certainly write scenarios based on the meaningful tasks for your business.
I don’t usually write scenarios, but it doesn’t harm the design process if it is done correctly. Let me explain two things: Why I don’t write them and what is incorrect execution. I don’t write scenarios because I ordinarily work in quick-paced environments. I explore scenarios verbally with my team. To communicate these scenarios to other team members, we could use comics, storyboards, or videos,[6] but typically we don’t have time. We go straight to prototypes, working directly and verbally with engineers.
What is an incorrect scenario? They are long, written descriptions that contain a lot of unnecessary detail, such as the specific buttons the user hits, every edge case,[7] or every error condition. Don’t make it read too much like code, yet. Don’t dwell on the facilities being used. Incorrect scenarios might also include non-relevant conditions that do not affect what the person is trying to accomplish, and might be better off as part of a persona description, such as gender or fashion preferences. In a situation where you’re designing a clothing store, of course fashion preferences would affect how a customer behaves. But it’s unlikely to affect how someone decides on a retirement plan.
Shortcuts and Other Ways to Use Mental Models
I have mentioned in the first chapter of this book that mental models can be applied to many different situations. Here I want to point out that mental model research can scale to differently sized problems. Scalable adequacy is defined as “the effectiveness of a[n]…engineering…process when used on differently sized problems…Methods that omit unneeded notations and techniques without destroying overall functionality.”[8] Mental models collect just enough data about users to help you determine where and how to concentrate your efforts. There are several ways to scale the mental model method.
When the Project is Almost/Already Finished
You might be at a late stage of design and development when you pick up this book. Don’t despair; it’s not too late to take advantage of a mental model, or at least a rough draft of one. Say you already have prototypes and usability test results. Say the users just don’t get it. Sketching out a mental model will help you see exactly where your design veered off in a direction different than users. If the departure between your solution and user goals is significant, now is the time to convince someone to spend a little time on research so that the patches to the first version are not a waste of time. Developing something involves a lot of iteration, and if your first try is wide of the mark, subsequent tries will benefit more from a solid understanding.
What if your beta application is faring well and you want to know in which direction to move next? It’s perfect timing to align functionality to a mental model and prioritize the gaps. When your team sees this diagram it will become a lot clearer how user research can help, even at this point.
In both of these instances you and your team can create a rough draft of a mental model in a matter of a day or two. First figure out which of your users you want to cover. Pore over existing user research data and try to extract knowledge using a behavior-and-philosophy-based perspective.[9] Then get in a room (virtual or physical) and brainstorm behaviors. From the existing research and your collective experience over the years, your team will be able to produce around 40% to 50% of the behaviors that actual research would create. Remind everyone to spit out descriptions from the user’s point of view. Say, “There were a few people I heard from who did it this way,” instead of, “I would have done it this way.” Leave the personal pronoun “I” checked at the door. Think of real-life behaviors you have encountered, not your own real or hypothetical reactions.
After a few hours of brainstorming, take a break, then try grouping things together. You can create a reasonable draft of a mental model in just a few days. This method is how I did it during the heady dot-com boom at the end of the last century. Be aware, though, that every single mental model I produced with a team this way was missing at least one or more significant mental space. More ominously, only one of the dot-com companies I made a mental model for is still alive today,[10] and for them I employed the full-blown method with 34 interviews. Thought-provoking.
A draft mental model diagram can be the result of a few days worth of well-disciplined, task-oriented thinking on the part of the team. You can then check assumptions against this draft and even conduct gap analysis.