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 base of research. Work on persuading them to set aside resources for this re-usable, long-lived information.
When You Don’t Have Enough Influence
You might not be able to persuade anyone to follow this method. This is an extremely frustrating position to be in, and I empathize. Don’t give up. You can pull together a rough draft of a mental model by yourself, simply by listing behaviors and grouping them, then laying them out in towers and mental spaces. You will have to work based on your accumulated understanding of customer aims, and you will want to write the behaviors from the customer’s point of view. In the end, you will have a mental model that probably shows 30% to 40% of the mental spaces and towers. Treat the diagram as a rough draft, and use it to persuade others on the team to investigate further.
I have also heard of practitioners “flying under the radar” so to speak. They lay out all the steps to create a mental model, including task-based audience segmentation, interviews, and analysis, but they spread them out over the course of several months. When they have an unscheduled hour or a break from their assigned projects, they conduct an interview or analyze a transcript. In the end, they have a solid mental model to present at design meetings. I have heard this wins the respect of management and clears the way for subsequent user research. Be warned that this approach takes a very dedicated, determined personality, but that might be you!
Six Shortcuts to Mental Models
What you might have already guessed is that the approach I describe in each of the scenarios doesn’t only apply to that scenario. Go ahead and choose any of the shortcuts that seem likely to work best for you.
Rough Sketch: Sketch a rough draft yourself
Rough Draft: Gather your team and create a mental model based on existing data and your collective understanding
Rough Notes: Conduct the interviews, but skip the transcripts and pull behaviors from your notes of the conversation
Fly Under the Radar: Conduct interviews and do your analysis as you can, over the course of several months
30-Day Cycles: Go ahead and conduct interviews, but focus on just one or two audience segments, narrowing your data set from four to 10 interviews
Piggyback on Usability Tests: After each half-hour usability session, tack on a half-hour interview
In the next chapter, I’ll go into whom to include in your work and when to do it.
[1] See Donna Maurer’s upcoming book Card Sorting, published by Rosenfeld Media.
[2] See the work of Liz Sanders at http://maketools.com
[3] Wikipedia: http://en.wikipedia.org/wiki/Research
[4]A brief explanation of Six Sigma appears on my book site under the Resources section:
[5] See Chapter 11, “Adjust the Audience Segments.”
[6] A striking example was shown at MX—Managing Experience through Creative Leadership, San Francisco 2007, by Tim Brown, CEO of IDEO, in the form of a short video (really a series of still images with voice-over) of a futures trader making decisions about pork distribution for an upcoming sunny spring weekend. It was a story about how that trader used various tools, including phone, email, weather reports, and the prototype trading application to diagnose and act upon an opportunity.
[7]Wikipedia definition: “An edge case is a problem or situation that occurs only at an extreme (maximum or minimum) operating parameter.” http://en.wikipedia.org/wiki/Edge_case
[8]“The Problem with Scalability,” Communications of the Association for Computing Machinery (CACM), Sept 2000/Vol.43, No. 9 by Mauri Laitinen, Mohamed E. Fayad, and Robert P. Ward.
[9] Existing user data may come in the form of preference or evaluative research. Try to deduce root causes, if they exist in the reports. (We’ll cover root causes in great detail in Chapter 8.)
[10] The company that survived the bust under the guidance of CEO Peter Ostrow is http://www.testmart.com, selling previously