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.
When You Have Little Time and Money
You might have extremely limited time or almost no budget. I have increasingly heard of teams following a three- or six-week “agile” develop-ment cycle. How does that leave you time to do proper user research?
Well, if it is going to happen, it has to occur in little chunks. Spend one of your development cycles mapping out the entire set of task-based audience segments you deal with, selecting the highest priority segment, and writing a recruiting screener to find these people. Hire a recruiter to line up some interview appointments. Then spend another development cycle interviewing four people from one of the audience segments (four is the minimum to start seeing a pattern of repeated behaviors). Analyze the transcripts. At the end of this second cycle, you should have a mental model for that audience segment. At this point, you can do any of three things: You can proceed to another audience segment and interview those people; you can use the mental model you just created to design the solution you’re working on; or you can take a step back and use the mental model to strategize where to focus your development efforts for the next few quarters. In any case, there are ways the process can be broken down to fit into your development cycles.
What if time is even tighter, and spending four weeks analyzing transcripts simply won’t fit into your deadline? If you can, strive to conduct interviews with real people—the benefit of hearing their words is worth the cost of eating up a week or two of the time before your deadline. Instead of transcribing those interviews, my frequent collaborator Mary Piontkowski suggests capturing rough notes about behaviors in real time as you conduct the interviews, or creating these behaviors right after the interview from the notes you took. Without a transcript you will probably miss half of the behaviors, but the important ones will stand out in your mind and your notes. That will be good enough for a shortcut.
And what if there is no time to conduct interviews? Talking to real people is the most important part of creating the mental model. If your organization already conducts usability tests with some regularity, piggyback short interviews on top of each session. Ask the participant to stay with you for an hour, and spend half the time on the usability test and half of the time conducting a non-leading interview. At least this way you will get a chance to talk to real people.
Those in charge of the development cycle schedules usually see the advantages of an underlying
