If you haven’t started on your reading list yet, here’s a suggestion. Since the pile of books you want to go through is tall, and your time might be better spent with friends enjoying discussions, say, about the latest movies, try allowing yourself to read just two chapters a week–from separate books! From the Mental Models book, I recommend Chapter 8. This is the chapter that helps you see how different this type of analysis is. Instead of focusing on facts, you focus on motivators. What makes a person do something this way? Mental models are all about letting you see your customers from a whole new perspective, and this type of analysis is at the heart of it.
I’ve been guiding the fabulous folks at the University of Buffalo (and the team at their design partner mStoner) through the interviewing process this week. One of the university stakeholders for the project wanted to be interviewed as a participant–as someone who keeps track of what an organization is doing and crafts his decisions based on what he learns. As expected, the interview kept bouncing back to what this stakeholder does at the university, rather than branching out to similar habits he might have in other circumstances. When I tried to explore how he tracked information about other organizations than the university, he was surprised and said he wasn’t prepared to talk about other topics. It was disappointing because the other topic we glimpsed was unique to him, and I could sense that we would have been able to go deeper into what was motivating him.
That’s when it hit me. Perhaps instead of telling him we were going to interview him, we should have indicated it was going to be a more informal session. We should have said it would be conversational, where we talk about a variety of topics and follow branches in the stream of thought. Then the participant might have felt more relaxed about jumping to topics other than what he thought were “sanctioned” for the interview.
I mentioned to the team members that I thought the term “conversation” would be better to use than “interview.” They agreed and immediately changed the recruiting screener to use this word instead of “interview.” True, the definition of “conversation” is “an informal discussion or exchange of ideas,” which is not quite what we are doing, but it’s close. (We are listening rather than adding our ideas to the conversation.) The emphasis is on the informality of it. That’s what I like about it.
The Python script used to generate mental model diagrams has been updated to allow for added flexibility in output. Originally, box labels greater than about 48 characters would render outside the margins of the box, requiring close monitoring of the label length and often caused the label to be rewritten awkwardly or with abbreviations.
The new script was updated to allow for the following:
- Variable box height setting (on or off)
- Base box height setting
- Max box height setting
- Page aspect ratio may be altered, allowing the mental model diagram to be rendered in either landscape or portrait
- The boxes with the greatest height are moved to the top of the tower when rendered
- Tower height/width is rendered relative to the cumulative height of the boxes plus margins
Requirements for Running the Script
- Install Python version 2.6.2 for Windows (latest supported by PyWin)
- Install Pywin32 version pywin32-212.win32-py2.6.exe (Match the version number to the version number of Python you install–you will need to look at the list of exe files to find the right one, which may involve clicking on an upper-level folder; don’t just “download now” the whole package. Go for the matching exe file, with a strange file name like the one I show here.)
- Excel is required to run the script. The script does run with Excel 2003, but has not been tried with other versions
- While Omnigraffle or Visio are not required to run the script or create the diagram, they are required to view the diagram
- Note: As of Jan 2011, I have tried running Python27 on my Win7 32-bit OS, with the matching win32 Python extension, and it works. I have not tried Vista, egad.
Setting Variables Within the Script
Variables within the script may be set by the user to adjust the appearance of the mental model diagram. To set variables, open the script in any text editor such as NotePad or UltraEdit. There are numerous text editors available for free if you do not have one. Avoid rich text editors such as MS Word, or WordPad.
Caution: There are several variables that are calculated relative to other variables. Tower width is an example of this, where it uses the BOXWIDTH setting plus the spacing settings to render the Tower width. If you change these settings you are likely to break the script. If you do this, please download a fresh copy of this mental model script.
The first variable you may change is VariableHeight. Setting it to “False” restores the original script behavior, hiding all updates in this release. BOXHEIGHT defaults to 0.375 inches (3/8″). (You can reset this variable if you want.) At this default height, box labels will be restricted to about 48 characters and will overflow the box margins if too long. Setting VariableHeight to “True” allows the boxes to adjust automatically to the length of the content. (default = True)
The second variable you may change is PageLength. This variable allows the height of the diagram to be set in inches. Setting this variable to 11 for example will cause the diagram to render in portrait. Setting it to 8.5 will cause the diagram to render in landscape. (default = 11″ – portrait) One can assume that setting it to other numbers will allow rendering for slightly different page heights, although we have not tested it yet. Between this variable and MaxTowerHeight, one could possibly format the model to fit on plotter paper, admittedly still at the small font size.
Box Variables If VariableHeight=True:
- MAXBOXHEIGHT – Sets the maximum height in inches for the box height (default = 1.5 inches)
- MINBOXHEIGHT – Sets the minimum height in inches for the box height (default = 0.375 inches, 3/8″)
- BOXWIDTH – Sets the width of the Task boxes (default = 0.625 inches, 5/8″)
- Box2BoxSpacing – An empty space between boxes (default = 0.0625 inches, 1/16″)
Tower Height Variables If VariableHeight=True:
- MaxTowerHeight – Sets the maximum height for the tower (default = 4.05 inches)
- VariableTowerHeader – Turn on/off tower header content adjusting. Turned on (True) computes a space occupied by a tower header and adjust the boxes accordingly. Disabled (False) leaves a constant space controlled by a variable TowerHeaderExtra (default = True)
- MaxBoxNumberPerColumn – Sets the maximum number of boxes in a tower (default = 7)
- Box2TowerSpacing – A gap between a tower border and a box side (default = 0.125 inches, 1/8″)
- TowerHeaderExtra – Height of the tower header if VariableTowerHeader = False (default = 0.375 inches, 3/8″)
- If you are not using the Excel template, please be aware the the script is looking for column headings with the following labels in the exact order: Mental Space, Task Tower, Task
- Some characters will not render by this version of the script. Curly quotes will break the script, as well as some diacritical marks such as the acute acccent in fiancé.
- This script has been tested on the PC, but it has not been ported to the Mac.
Note: this list will be updated as new issues are found.
In the first five months of 2009, I’ve guided four teams through making their mental models. We have combed transcripts, labeled quotes, and grouped the labels from the bottom up to create the structure of the mental models. We have made 11 different models together. What has come up again and again is the difficulty of choosing what to include in the model and what to exclude. I see two recurring prominent mistakes. Avoiding these mistakes will greatly simplify the complexity of piecing together the data.
First, someone will break one thing an interview participant says into granular steps. We all have a natural tendency to treat details as king in data analysis. Yes, when building mental models we need to read between the lines of the conversation and pull out implied behaviors. But often researchers pull out too much, including things the participant says which are off-the-cuff statement-of-facts intended to support the central idea the participant is talking about. Here’s an example. I found the following five labels combed out of one transcript by a team-member:
- Participate in Local User Groups in My City – “And a lot of times, we just use these things for ideas … down here in Atlanta, there’s an Atlanta.net users group”
- Hear How Industry Professional Implemented a New Technology – “And typically what happens is someone will come in, usually like a industry professional, and they give a talk on a technology they use, and how they implement it.”
- See What Else Is Out There – “it kind of lets us see what else is out there”
- See Demos & Code Walk-Thrus of New Technologies – “They do demonstrations, and actually low level … actually doing code walk-throughs”
- See Code Debugging Examples – “and debugging”
The team-member is trying too hard to pull implied behaviors from the off-the-cuff statements. The interview participant was trying to say that he learns a lot from seeing the code examples people present at the local users group. The first two and last two labels above are statements of fact. “There’s a users group here in Atlanta where industry professionals give us talks. I see demos, code walk-throughs and debugging examples.” Statements of fact are not behaviors. The participant is not doing anything here except passively attending. You want to look past this, deeper into what the participant is conveying. You want to record the root behavior in the mental model. The five labels above can be replaced with one label:
- Get Ideas from Professional’s Code at Users Group – “we just use these things for ideas … Atlanta.net users group … someone will come in, usually like a industry professional, and they give a talk on a technology they use, and how they implement it … lets us see what else is out there … They do demonstrations … code walk-throughs … debugging”
Note that the actual label could vary and still convey the essential meaning: “Attend Users Group to get Ideas from Professional’s Code” works equally as well.
Second, I frequently see a single concept repeated as separate labels and quotes. The participant has mentioned something a few times in the course of the conversation, and the researcher has not taken the time to pull the quotes together into one label. Instead, when grouping the labels, the team is faced with finding a task already in place for this participant about this concept, and they must rip apart the entry, move the quote into the original concept, and deleted the redundant entry. Here’s an example:
- Find Out Progress of Everyone In Scrum Meetings – “We had scrum meetings every day … kind of finding out the progress of everyone”
- Collaborate at Scrum Meetings – “one of our biggest points for collaboration is we have these – we have daily scrum meetings”
These two redundant entries can be combined into one:
- Find Out Progress of Everyone In Scrum Meetings – “We had scrum meetings every day … kind of finding out the progress of everyone … one of our biggest points for collaboration is we have these – we have daily scrum meetings”
I should admit that it is difficult to avoid this second trap when you are combing one transcript over the course a couple of days. It’s hard to remember that you already captured an idea. If you have the slightest inkling that you have recorded the concept before, do a search right then to see if it already exists in this set of combed labels you are working on. It is worth the time to do it in the moment, rather than grapple with it later when you are grouping.
It’s also possible that you see a nuance–a slight difference–between ideas and you want to label them separately. If you can clearly and easily label the two ideas distinctly, then it is likely the nuance is significant enough to record separately. More often it is the case that you struggle to label them, and after a few minutes of consideration, you decide that the nuance is not important enough to capture in the model after all.
If your team can avoid these two classic mistakes while combing the transcripts and making labels, then grouping those labels will go so much faster. Less brainpower will be needed to understand how the labels relate to each other within the context of one participant, so that more brainpower can be put towards comparing the labels to other participants instead.
At nearly every presentation and workshop I give, someone comes up to me and asks, “Have you tried (insert tool name here) with your method? It’s really cool.” I shake my head no and politely ask them what they think the tool would do. Every explanation boils down to this: it would automate the analysis of all those interviews, make affinity groups, and do away with all that manual work. I ask them to email me the tool name, then I file it away untouched. I always thought this was just a personal quirk of mine–that I want to do the analysis myself. I don’t want to use a tool to comb through transcripts for me because I’m the one who is reading between the lines and guessing at implied meanings.
I finally realize this is not a personal quirk. Manually analyzing the transcripts is a requirement.
Why? Why should we do things manually when there are tools to automate them? In a nutshell: none of the tools is good enough. Yesterday I watched a Marvin Minsky lecture on how artificial intelligence is not making any breakthroughs. A chimpanzee can still recognize things better than a machine can. You and I can recognize intentions, motivations, implied philosophies, and emotions better than a piece of software can.
But there is a more compelling argument than this. This argument is predicated on an analogy to food. Nutritionists have been telling us that we should eat closer to the source–eat foods that are not processed, that are closer to their natural state. Books mention that the reason food manufacturers enrich their products with nutrients is because the nutrients have been removed during processing. Enrichment only adds a small percentage back. So my argument goes that by analyzing the interviews yourself, you are going closer to the source. (This argument also works for deciding who to interview: the business stakeholders at the organization, the people who currently serve a customer, or the customer herself.) It is far more nutritious for your brain to get enmeshed in the complex strands of meaning in a conversation than to look at the pre-sorted list of software-processed groups. It’s like going out to the garden and seeing how the plants grow, learning how they use the soil, watching pollination, understanding how disease spreads, harvesting the fruits, and then using them in your kitchen, as opposed to sitting on the couch eating potato chips. Those chips bear little resemblance to an actual potato.
The point of mental models is to understand your customers deeply–so deeply you could live their life, walk in their shoes, and make decisions exactly the way they would. If you use processed data to create your understanding of customers, you only create empathy with the tool or the tool’s designer, not your customers.
I just finished my Australian Road Show with the Web Directions folks. It was really illuminating doing the workshop three times in a row. I conduct five classroom exercises in each day-long workshop, and one thing really stood out for me this week. When workshop attendees tried their hand at grouping data (represented by a deck of cards with verb + noun labels on them) by affinity, things sometimes fell apart in two different ways.
The first part of the problem was because the data I gave them to group has to do with training for marathons, which, to my chagrin, is not widespread in Australia. By the last workshop, I managed to alleviate misinterpretations of the data by explaining what it all meant up front. However, the folks in the Canberra workshop really struggled with marathoning concepts. (Sorry for that!)
The second, more striking, observation I made is that workshop attendees often tried to group too high by making a few labels like “prepare,” “monitor,” and “track,” then putting all the cards into these three or four big broad categories. Each category would have 20 cards or so. Then the groups would try to investigate each of those piles of cards for more detailed subsets and encounter difficulty.
(One of the groups sorting marathon cards at the Melbourne workshop.)
That’s a top down approach. Even though I asked them to work from the bottom up, to refrain from putting their own model of the data together at the top level, to avoid making boxes and sorting stuff into them, they did this. I don’t think the groups realized they were working from the top down. They were thinking it was more of a way to break down the large amount of data into more manageable piles. I guess it is a natural tendency for many of us. In our own process, if we have a lot of data, we want to break it down into a few sets and attack each set separately. It reduces cognitive overhead, if you will, and makes us feel less overwhelmed.
Truly the best way of grouping data into subsets from the bottom up is to randomly select one piece of data to begin with and compare it to all the other data to see what is like it. Ask yourself, “What does this person intend by saying this?” What’s behind a label like “Stop to Remove Rock from My Shoe” or “Enjoy the Fall Colors?” For the first one, the intent is to make my running as comfortable as possible, since it is quintessentially an uncomfortable process. The second label represents the intention to get a spiritual boost from the run, perhaps associated with distracting myself from the pain. By looking at the intent behind a label, workshop attendees found it much easier to find similarities between cards spread out on the table before them.
I figured these observations were important enough to share with the general group. We’re all data analysts of one stripe or another. It helps to remind ourselves that the data needs to be assessed one droplet at a time, rather than as a set.
Apparently Mental Models is the book to read right now. Two UX Book Clubs are covering it for their upcoming meetings.
Nathan Shedroff’s book is out, and his message will not fall on deaf ears. One of the key points he makes is that for the past decade or two, design has been “about appearance, or margins, or offerings and market segments, and not about real people–their needs, abilities, desires, emotions, and so on.” Notice something that Rosenfeld Media’s books have in common?
The fact that we are all emphasizing the importance of caring about people–respecting their own thought processes–won’t go unnoticed. It may take a bit of persuasion at the upper echelons of many organizations, but we are good messengers, all of us. Eventually organizations will stop “creating consumers” and start supporting what people need and love to get done. Mental models are one tool to help organizations do that.
If we base what we produce and what we serve people on their inherent humanity, it will lead to a better world. The direction Nathan would have us go is toward “design that is about systems solutions, intent, appropriate and knowledgeable integration of people, planet, and profit … design that can lead to healthy, sustainable solutions.” An excellent point!
Erich Joachimsthaler, author of the book, Hidden in Plain Sight: How to Find and Execute Your Company’s Next Big Growth Strategy,” says this about mental models:
“The book talks much about the design process, but what I find the most important lessons is how to develop a strategy for a firm, from the point of view of the behaviors of the people the company serves. This has the potential to add entirely new thoughts about strategy formulation.“
It’s thrilling to see mental models recognized as a strategic tool. Read more of Erich’s book review and his sister approach of episodic reconstruction. I also talk about tactics and strategies in my Future Practice seminar.