CHAPTER 7
Understanding Potential Users and Customers
There's a Dilbert comic strip in which the character says, "None of us has designed a nuclear power plant. In phase one we will gather customer requirements." In the next frame, one of Dilbert's colleagues sits with a wide-eyed energy consumer, saying, "So...you want free electricity, without mutating, unless the mutation gives you X-ray vision." Clearly, Scott Adams, Dilbert's creator, has encountered the most common way companies conduct research: by asking their customers what they want.
The problem with this approach is that customers and users are not experts in product design. There is a deeply held belief among some usability and design professionals that users are the only experts. I would argue that users are the only experts in what their problems are, but that they are seldom equipped with the expertise to solve those problems. It's a bit like the doctor-patient relationship: Patients have the best information about their symptoms and can assess whether particular treatment plans fit their lifestyles, but physicians are experts in diagnosing and treating. The right solution involves the knowledge and cooperation of both parties.
When people ask for feature X, it's often their way of identifying that they have a problem with how things work now; the suggested solution is sometimes workable, but a skilled designer can usually come up with a solution that's not only better, but that also suits the needs of a wide range of users. The techniques in this chapter will help you get beyond what customers and users say they want to what they really need. Chapter 8 is a dissection of an actual interview, which shows you how to put these techniques into practice.
Interviewing Customers in a Business Environment
Customers are the people who buy the product or service. The customer and user of most consumer products are one and the same. In a business environment, chances are the user and buyer are different people with different—even conflicting— needs. In some cases, there are a few customers who share the purchasing decision, such as the heads of IT, clinical operations, and business operations in a hospital. If you're designing an internal tool, your "customers" are probably one
Designing for the Digital Age: Creating Human-Centered Products and Services
In a business environment, chances are the user and buyer are different people with different—even conflicting— needs.
or two of your stakeholders, most likely the heads of whatever business functions the tool supports. Most of these customers never touch the product, or only do so to install and configure it, so interviews with them focus on goals and concerns rather than behavior. This makes stakeholder interviews somewhat simpler than user interviews.
When possible, interview the customer(s) at any site before meeting with the potential users. This will give you more context for how the various roles work together, so you can spend more of your precious time with users focused on their individual roles and less on how the company functions. Also, setting the stage with the customer will typically ease your entry into the user interviews. Once you establish a rapport with the customer, she is reassured that it will be worthwhile for other employees to spend time with you.
In many cases, the sales person for a particular customer account will want to accompany you to the interview. This can be helpful provided there's a good rapport between sales person and customer. However, some sales people can impede the interview by taking over, interjecting leading or otherwise unhelpful questions, or preventing you from asking questions to which they feel you should know the answers. Even if you've prepared the sales team with a note or phone conversation, a five-minute discussion of interview etiquette right before the meeting is a good idea. Ask the sales person to hang back during the interview, but say you'll be sure to defer to him for any customer questions. Also, plan on giving him a couple of minutes at the end for any questions of his own.
Customers are useful sources of two types of information: how the organization works and what their goals and concerns are related to purchasing and maintaining a product or service. If you're improving or adding well-understood functionality to an existing product, your interview focus can be fairly narrow. If you plan to launch a product unlike anything they've ever seen, your inquiry will of course be broader.
Begin the interview by thanking the customer for agreeing to meet with you. Introduce the members of your team and briefly state why you're there. You might be specific if this is a customer with whom your company has a close relationship. It's usually best, though, to be a little vague about what you'll be designing, just as in the introductory note described in the previous chapter.
Long-time customers occasionally have an expectation that everyone from your (or your client's) company should already understand their business. If you think this might be the case, consider explaining that
114
Chapter 7 Understanding Potential Users and Customers
because you're starting from scratch or doing significant rework, you're asking some deliberately naive questions to make sure you don't make any bad assumptions.
Useful questions for customers
The following useful questions are applicable to most customer interviews, though they certainly don't cover everything you'll need to know from every customer. Don't take this for a script, however—keep the interview loose and conversational.
Could you please tell us a little bit about your background and your role here at (company)?
You may not always know going into an interview exactly what role this person plays. Is she the only decision-maker or one of several? Does his job title mean the same thing at this company as at other companies? Does he have an IT background or a business background? This information helps put the subsequent answers in context. This is also a good starting point for an interview because it's a simple, comfortable question this person has probably answered before.
How does (the function or process to be addressed by the product) work here at (company)?
This may seem like a vague question. It is. Some loquacious customers may respond by drawing you a process diagram or organizational chart, which is an excellent starting point. Others will give you a quick verbal summary, such as, "Someone initiates a purchase request in e-mail or in the purchasing system. It goes to one of our purchasing agents who gets quotes, bounces the best one to the right manager for approval, then places the order." Even this kind of brief answer will give you entry points to any number of additional questions. Still other customers, if they're especially frustrated, might jump right to: "How does it work?
Not very well!" This is your cue to ask about the problems, though that's usually a topic covered a bit later. The next question digs a bit deeper if the customer doesn't provide all the detail you need.
What are the different groups or roles involved in (whatever function or process the product will address) today? How do the various roles work together?
The customer will mention one or more job titles and hopefully elaborate on what they all do. Ideally, you will get some sense of sequence from this, as well. Don't hesitate to ask for it if you don't get it. If the process is complicated, consider asking the customer to draw a diagram of the workflow. Ask follow-up questions to get clarification or additional detail. Be sure to summarize your understanding and ask the interviewee if it's correct.
How does this compare to your previous companies?
If an interviewee has considerable industry experience, it's worth spending a couple of minutes to compare her current company to others. Although this information won't be terribly detailed, it's a good sanity check. You can skip this topic if you're short on time.
What are the biggest problems or inefficiencies in this process/function today?
Notice that this question still isn't asking about the product, but is looking at the business process or function. If the customer wants to zero in on the product, see if you can get him to broaden his focus a bit. This will allow you to see where there might be opportunities to address needs beyond what the customer or product team might be considering. The customer may not be able to diagnose why these problems occur, but between the customer and user interviews, the design team often can. The customer's perspective on this question likely differs from what users will tell you.
115
Designing for the Digital Age: Creating Human-Centered Products and Services
Note that a number of the issues raised may not be anything you can address with design, but may point out where business-process consulting, better support at installation, or better training and customer support could help.
What are the biggest problems with the product/ system today?
This question is critical when the customer already has your system or a similar one, but not terribly useful if you're creating a new product category. Note that this question should come after the broader one—once you've focused the interviewee on a single product or system, it's more difficult to broaden the discussion again. If the customer is in IT, chances are these concerns will focus on things like installation and maintenance in addition to some common user complaints.
What are the best things about the product/ system? Why did you choose it over other options?
While you don't want to sound like you're fishing for marketing quotes, it's important to understand what the most valuable aspects of the system are so you don't change those. Also, since you're asking for complaints—and you might get a lot of them—it's a good idea to have customers remind themselves of what they like about your product, if that's what they're using today.
Could you tell us more about the other systems that work with this one?
Few enterprise tools exist in isolation. Most are connected to other products or homegrown systems, often including antiquated legacy systems with severe limitations. This creates a fragile patchwork that's held together only by the constant attention of the IT staff. A seemingly minor change in one of those systems can cause tremendous amounts of rework, especially when it affects data structures. This is important to understand, since it may make
customers reluctant to adopt changes that don't provide significant benefit.
What issues have you been addressing with homegrown solutions?
When various systems don't play nicely together, IT groups often develop their own systems to mediate. The other reason for homegrown systems is usually that some otherwise-valuable tool doesn't do everything the users need. If the vendor isn't responsive or the cost structure seems prohibitive, something gets cobbled together. Either situation represents an opportunity for your product. If these internal tools don't work well, customers may be perfectly willing to throw them out for something better. A customer who has invested considerable resources on internal tools that work just fine may not care to adopt your solution, but chances are that another customer will.
What do you expect a system for (process/ function) should do for (company)?
This question should begin to uncover some goals. Common responses include making people or business processes more efficient, cutting business operations or IT costs, or providing some capability that didn't exist before. You might hear about a desire to enforce certain business practices or regulatory compliance through rules or workflow in the software; this is an indicator that you should look for why users don't comply with the rules now.
What other factors are/were most important to you in selecting a product for (process/function)?
You'll often hear about things like total cost of ownership, ease of installation and updates, security, reliability, and other issues users may not mention unless they work in IT. Other responses probably overlap with the answer to the previous question.
116
Chapter 7 Understanding Potential Users and Customers
Other questions and wrap-up
No doubt other questions will come to mind. Responses to each of these questions will provide opportunities for further exploration and will sometimes require clarification. Once your time is nearly up or you have all the information you need, offer to answer any questions the customer has. Establish a means to get in touch with one another later if necessary. Be sure to thank the customer again for her time.
What not to do when interviewing customers
When interviewing customers, it's important not to turn into the complaint department or the product expert. It's fine to make a note of a few concerns and let the customer know you'll pass them along to the customer service or sales team (if the sales person is not in the room with you). If you suspect those concerns are extensive, bring someone from support or sales along to have a separate discussion about anything that needs to be solved right away.
Never step on the toes of the sales person who got you the interview. It could damage the company's relationship with the customer and will definitely erode the sales team's trust in you. Don't make any promises to the customer other than, "We'll pass that along to the appropriate people," since the design team is almost never in a position to fix a customer's problem. Avoid specifics about what the new or updated product will do and when it will ship, since you may set expectations the company won't be able to live up to. If the sales person has set any rules about things you can't say or discuss, you can try to educate her if those rules will cause you problems, but in the end you need to follow those guidelines. The sales person knows things about that relationship that you don't.
If you work in a large company with many product groups, some favored customers may suffer from a sort of interview fatigue if they've been visited too often. This can make your interview feel like an imposition and can make customers cranky about answering questions they've already been asked. In your planning, try to find customers who haven't been interviewed in the last couple of years. If you can't find any, ask the sales person or previous interview teams for answers to some of the basic organizational questions each interviewer is likely to repeat.
Exercise
What specific questions would you ask customers if you were designing the Room Finder or LocalGuide? (See Chapter 6 for a description of each.)
When	
interviewing	
customers,	
it's important	
not to turn into	if CD at 10
the complaint	at OS
department or	
	
the product	
expert.	
117
Designing for the Digital Age: Creating Human-Centered Products and Services
Interviewing and Observing Prospective Users
Every good interaction designer I know is a keen observer of people, insatiably curious about how people think and what tools they use: Why does the ticket barcode scanner at an airport boarding gate sometimes beep and sometimes not? How does that ultrasound machine work? I know I'm supposed to be applying for a mortgage, but what's that software that has you so frustrated? User interviews are more than the world's best excuse for indulging your curiosity, though—they'll help you see the world through the eyes of other people. This is immensely valuable even when you have a good understanding of the design problem.
The interview setting
The best data comes from individual interviews conducted in the context where the product is (or will be) used. Interviewing people in context yields greater specificity and decreases self-reporting error. When people have artifacts around to prompt their memories, they're less likely to gloss over the details they don't usually think about. Looking around the home or work environment can give you clues to other good questions or issues, as well. For instance, if someone has instructions for using their voicemail taped to the telephone, as in Figure 7.1, it's probably an indicator that the current system does a poor job of supporting those tasks.
Try to avoid having the interviewee's supervisor or other third parties involved in the interview. It's essential that you understand the things people do to circumvent cumbersome systems or policies, but few people will confess to breaking the rules with the boss in the room. You might occasionally need to do a group interview but, as with focus groups, it can be difficult to get accurate detail on individual behavior. However, small group interviews can be appropriate for products normally used by groups, such as interactive museum exhibits.
Figure 7.1. This telephone has a small cheat sheet of common voicemail commands taped to it. It probably represents an opportunity for improving the design of the system.
Check in about appropriate dress before going to an interview. Some industries and regions are more formal than others—slacks and a sweater are fine at a California software company but unacceptable at a London insurance company. Avoid dressing too much better than your interviewees, though; wearing a suit on a factory floor will instantly mark you as an alien who's not to be trusted.
Essential techniques
An effective interview doesn't just provide useful facts; it also helps the interviewer understand how the interviewee sees the world. This is a good reason to use techniques borrowed from ethnography.
118
Chapter 7 Understanding Potential Users and Customers
We designers often describe what we do as "ethnographic research." No doubt the average ethnographer would disagree with that assertion, but the parallels between ethnography and the most effective design research are striking. In his classic work1 on the subject, James Sprad-ley defines ethnography as the work of describing a culture from the native point of view. We're examining the native point of view, certainly, but are we really studying cultures?
When people have artifacts to prompt their
memories, they're less likely to gloss over details they don't usually think about.
In The Rise of Anthropological Theory,2 Marvin Harris defines culture as "the behavior patterns associated with particular groups of people." Perhaps teenagers who text, golf course superintendents, or orthopedic surgeons don't really comprise their own "cultures" in the usual
sense, but in each case, designers are outsiders who don't share the experience, vocabulary, or perspective of the interviewees (called
informants in ethnography). Like ethnographers, we must strive to put aside our own assumptions and see the world through someone else's eyes. For example, most of us see a brown spot on the lawn as a minor annoyance, so we don't exactly stay awake at night wondering if the sprinkler system is properly adjusted. To the superintendent at an exclusive golf course, though, a brown spot on the fairway is a catastrophe that could lead to the unemployment line. If we assume a little dead grass means the same thing to the superintendent that it does to us, we won't be able to design an irrigation control system that meets his needs.
Conducting a great interview isn't only about asking the right kinds of questions; it's also about the attitude with which you approach the conversation. The following sections offer some principles to keep in mind.
MAKE IT A CONVERSATION, NOT AN INTERROGATION
A loose, conversational structure lends itself to open, revealing discussion. When you start interviewing, you won't yet know what you don't know, so any fixed set of questions you prepare beforehand is likely to be inadequate. Barreling through a detailed question list may mean you miss the opportunity to pursue unexpected (but potentially fruitful) lines of inquiry. It also tends to make interviewees feel like they're being interrogated. However, having a list of half a dozen topics taped inside the cover of your notebook can help if you draw a blank during the discussion.
1. Spradley, J. The ethnographic interview. Wadsworth, 1979.
2. Harris, M. The rise of anthropological theory: A history of theories of culture. Routledge, 1969.
119
Designing for the Digital Age: Creating Human-Centered Products and Services
No matter how relaxed the discussion, though, don't forget this is an interview. Stick to the active listening techniques covered in Chapter 4. Keep the focus on the informant's experience rather than your own. The one exception to this rule is when you have a particularly shy interviewee (which is surprisingly rare); telling a brief story of your own early in the conversation can coax a reluctant participant to open up.
BE SYMPATHETIC AND NON-JUDGMENTAL
We all have unique challenges and points of view. Assume that your interviewee is a good and capable person. If he has a negative attitude about work, perhaps there's a reason; perhaps it's even due to a problem you could help solve. If she doesn't take her medication or follow her treatment plan, there's probably a reason for that, too.
Most people can tell if they're being judged, and it tends to make them reticent. If you can be a good, receptive listener, though, you may be surprised by the extent to which people share very personal information. When my team was designing the software for an early consumer Web cam, we naively expected to see grandparents chatting with little Tommy or watching bad video of a birthday party. Instead, we heard more about birthday suits than birthday parties—our random sample of adults mostly used their cameras for very adult activities. The first interview didn't go especially well; the interviewee could tell we were surprised by his story about making his own pay-per-view movies. Once we were prepared for this kind of thing to come up, we weren't surprised in subsequent interviews, so the other interviewees all felt comfortable enough to share the necessary details (and a few unnecessary ones). Being a sympathetic listener can get people to talk about almost anything!
BE THE LEARNER, NOT THE EXPERT
Try to establish a rapport with the interviewee before bringing up potentially touchy questions, such as frustrations, relationships with others, and so on. Think of yourself as a student learning how the informant does her job or lives a certain aspect of her life. Particularly in business settings, having someone look over one's shoulder can feel threatening, so adopting this mind-set will help you send those reassuring signals that the interviewee is the respected expert. Spradley describes this as encouraging elaboration by "expressing ignorance and interest" more often than you would in a typical conversation.
Establish a rapport before bringing up potentially touchy questions.
120
Chapter 7 Understanding Potential Users and Customers
ASK NAIVE QUESTIONS
As a consultant working in complex domains, such as healthcare and financial modeling, I've often been asked how the design team can possibly be effective in a field they don't know. I always respond that ignorance is actually a blessing; interviewers who believe they know the industry or topic very well tend to make assumptions about processes, mind-sets, and terminology. Because the design team doesn't know what terms mean or how particular processes are supposed to work, they ask the "dumb" questions that often reveal critical design insights. In a business domain, of course, you never want to leave the customers with the impression that the product designers aren't very bright, so as with stakeholders, be sure to mention at the beginning of the interview that you're being deliberately naive.
ASK PEOPLE TO SHOW YOU
People self-reporting about their own behavior tend to generalize, which can cause them to obscure or omit important details. If you can see people in action, you'll be able to observe numerous things they're unlikely to mention. The ideal is to see a task through from start to finish. When time is too short because processes are complex, think about your interview as a cooking show in which you want to see the important things happen, but don't necessarily have to watch the chef dice every onion. Ask the participant to walk you through each step in the process without completing it. For example, a statistician running a complex analysis may take a day or more to clean the data before setting up the analysis parameters and running the job. You need to watch enough data cleaning to get a sense of the flow and to identify problems, but more than a few minutes of observing that particular task isn't worthwhile. The exception to this last point is most likely to crop up in critical situations that are hard to replicate through show-and-tell, such as surgery or air traffic control; in these cases,
you need time and patience because you never know when an emergency will arise and provide you with critical insight.
ASK FOR SPECIFIC STORIES, ESPECIALLY ABOUT ANYTHING YOU CAN'T OBSERVE
Asking participants to tell you specific stories— what ethnographers call being "case-specific"—is another good strategy for avoiding the self-reporting problem. Rather than asking how someone shops for home entertainment, ask, "What was the last home entertainment product you bought? Could you tell us about your decision-making process and your shopping experience?" In many ways, stories are the foundation of any interview; they encapsulate tasks and sequence, problems, thought processes, and even emotional responses to situations. Even if all you know about interviewing technique is "tell me stories" and "show me how you did that," you'll get at least some useful information for doing design.
TAKE OPPORTUNITIES WHEN THEY'RE OFFERED
When an interviewee provides an opportunity by referring to a particular person, process, or thing that may be relevant to the design problem, follow up on it by asking for more detail. If that would interrupt the flow, make a note (mentally or perhaps in the margin of your notebook) and then bring it up once the current train of thought is complete: "You mentioned a few minutes ago that you prepare a weekly report. Could you show us an example of that?"
WATCH FOR INCONSISTENCIES
Participants may also have inaccurate perceptions of their own behavior. This kind of inconsistency can help uncover self-reporting error. I recall one interviewee who saw herself as a very decisive shopper. She insisted she never, ever returned things to stores, because she was always confident in her purchases, but later described
121
Designing for the Digital Age: Creating Human-Centered Products and Services
the Amazon return process with considerable familiarity. Sometimes, apparent inconsistencies are about differing worldviews between interviewer and interviewee. When I asked her about the inconsistency, she said, "Oh, you're right. I really never return clothes, but I guess I just don't think of buying books as shopping." Her view of "shopping" was that it was a recreational activity, typically involving clothing, shoes, or housewares. Finding and purchasing books had no entertainment value for her, so she didn't equate it with other shopping activities.
GO BEYOND THE PRODUCT, BUT NOT BEYOND THE DESIGN PROBLEM
If you're designing the ultimate e-mail system, do you really just want to see how people create, view, and organize their messages today? Chances are, some of the communication that happens outside of e-mail now would be more effective if it were integrated into that application. This is where the design team can identify compelling opportunities that affect the product's definition as well as its design.
Think about what major problem the product or service is supposed to address, then focus on that problem rather than on the current instantiation of your product. If you're designing a mobile phone, you're addressing the communication and information needs people have when they're not sitting at a desk. If you're designing an electronic medical record, you're looking for opportunities to make clinicians' use of information more effective and efficient.
Your interview time on any project is necessarily limited, so it's equally important to be clear about what problems you're not solving. For the electronic medical record example, you need to understand what electronic devices (such as vital-signs monitors or glucose meters) could automatically feed
3. Mehrabian, A. Silent messages. Wadsworth, 1971.
data to the system, but you don't need to understand those devices well enough to redesign them.
PAY ATTENTION TO NONVERBAL CUES
If you've ever had the tone of an e-mail misinterpreted, you know that even seemingly straightforward communication often relies on nonverbal cues for accurate interpretation. UCLA psychology professor Albert Mehrabian3 posited that communication about feelings and attitudes is only seven percent verbal; tone of voice and body language account for the remainder of the meaning.
While I question the utility and accuracy of such detailed percentages, the basic concept rings true: If someone's response to "How are you doing today?" is "Fine," pronounced with a sigh and accompanied by a slumping posture, which part of the communication will you believe? It would be mistaken to apply these ratios to more factual information—the answer to "What's the square root of 25?" is unlikely to carry much emotional content; at most, body language might tell you whether the person you're asking finds the question difficult. Nevertheless, product design usually touches on multiple topics that can carry emotional weight, ranging from enjoyment to frustration. This is one reason that transcripts, audio recordings, and telephone interviews are not the most effective tools for understanding how people think and feel, though they're fine for simple facts.
If someone seems to exhibit discomfort, or if the verbal and nonverbal content don't agree, gently remark on it and ask why. In an interview related to managing digital photos, for example, an interviewee said he disliked the time he spent organizing photos. However, when he showed us how he laid out the photos of his child on a Web site, he seemed much more animated than he did earlier in the interview. When one interviewer said, "I know you mentioned that you didn't enjoy organizing
122
Chapter 7 Understanding Potential Users and Customers
photos, but you seem enthusiastic about this part," he responded, "Oh, well, I don't like having to rename all the files and rotate them and so on, but laying them out and sharing them with family is actually kind of fun. It gives me a chance to enjoy the photos and the memories of time with my son." This is important information for guiding the design later on. Observe the interviewee's communication style for a little while before doing this, though, since you might be misreading the cues; some people simply fidget or make faces when they're thinking. Also consider whether this will be seen as invasive; it's usually fine in the United States or other countries where people are very expressive, but may be rude elsewhere.
THINK AHEAD A LITTLE (BUT NOT TOO MUCH)
If you're the inquisitive sort, as most good designers are, it's easy to get immersed in learning about the informant's world. However, it's important to focus on the information you'll most need for design later. It will be essential that you understand process, priorities, what types of information are used when, and so forth. Be careful about jumping too far ahead, though; if you find yourself thinking about solutions during the interview, you're no longer giving your full attention to listening and observing, and you may be pulling the interview off course.
RELY ON YOUR TEAMMATE(S)
Interviewing is hard work. Simultaneously listening, taking notes, providing the right kind of feedback to the interviewee, thinking up the next question, and making sure you're covering the right topics without jumping too far ahead is pretty much impossible to do without help—especially for six or eight hours a day while you're also jet-lagged. Alternate which team member is driving the discussion and which one is mostly taking notes.
Even when you're in the pilot's seat, make use of your teammate as a copilot when you can't
think of where to take the interview next. A small amount of intra-team communication during an interview is never problematic if handled well. Work out a code beforehand; for example, turning to your teammate and asking, "What topic would you like to cover next?" means "Help! I'm not sure what direction to go." Also, be sure to ask your teammates if they have follow-up questions on any topic before you move on to the next.
What not to do in user interviews
Your interviews don't need to be perfect; you can make a mistake or have an off day and still get plenty of useful data. However, there are a few things that tend to make interviews less productive.
DON'T ASK LEADING QUESTIONS
One of the worst things you can do in an interview is ask leading questions that imply the answer you're looking for. Even experienced interviewers can find themselves "validating" their preconceived notions about new features or design changes. If you're convinced you're right and you just can't wait to get confirmation from users, it's hard to resist asking, "Would you like to be able to access your calendar on the Web?" A typical interviewee who is trying to be polite and cooperative might say, "Sure, that could be useful."
What's the problem with this? Even if this is a truthful answer, you have no idea where it really falls in the participant's list of priorities—maybe she said yes, but maybe there are 27 other things that are more important. Instead, wait to see what points of pain people bring up on their own; these are almost certainly at the top of the priority list.
Using open-ended questions will help you avoid leading; it's very difficult to ask whether feature X would be helpful without anticipating a yes or no answer. If you really must ask your leading question, at least save it until the very end of the interview, so you'll have a chance to see if it comes up
123
Designing for the Digital Age: Creating Human-Centered Products and Services
at all before that. If it doesn't, you'll be more able to put the answer in context.
AVOID ASKING THE INTERVIEWEE FOR SOLUTIONS
Solving the problem is your job, not the informant's. If you start asking for solutions or running with solution ideas the interviewee proposes, you're most likely missing some important information about the problem. If you feel compelled to ask interviewees what they want, there's a constructive way to do it: "If you had a magic tool, what would it help you accomplish?" Note that this question doesn't ask what the tool is or how it works; rather, it's focused on goals. When an interviewee suggests a solution, don't take it at face value. Instead, ask, "What problem would that solve for you?"
DON'T SOLVE PROBLEMS DURING THE INTERVIEW
Designers are solution-minded people, so it can be difficult to see problems in an interview and not try to solve them right then. It's painful to watch an interviewee struggling with the product in some way. Unless it's completely impossible for him to accomplish a task you need to see, though, pay attention to what he's struggling with and why, rather than helping him out. There are at least three good reasons for not helping: You'll miss important data, you'll eat up precious interview time, and you'll turn the interview dynamic on its head, since the interviewee is supposed to be the expert while you're the learner. If you feel you really must offer a helpful hint, try to save it for the end of the interview.
The other kind of problem solving that can be tempting is, "So, what if we put another button over here to help you add a new item to the list?" Again, this consumes time and energy you could be using to learn. Even if it's a spontaneous idea born from a genuine wish to be helpful, this is really just another type of leading question. Participatory design may have its place, but this isn't it.
Structuring the user interview
A conversational interview is somewhat loose and free-flowing, but there is an inherent structure: introduction, overview, details, more challenging topics, and wrap-up. There are surprisingly few structural differences between user interviews for consumer and business products. This is a typical structure; details on each topic follow.
— Introductions: who we are, why we're here, what the next hour will be like
— Chitchat: a get-to-know-you question or two (most important with consumer products)
— Overview question: a broad topic meant to elicit information about major activities and flow
— Demonstration of activities: user walks through key tasks usually based on response to the overview question
— Looking for gaps: a recap of activities covered so far and a request to fill in anything not mentioned so far
— Details as needed: other topics you need to cover that haven't come up yet, typically involving information and objects, actions, relationships, frustrations, background, and goals
— Grand tour: a guided walk-through of the usage environment and relevant artifacts, if it hasn't already happened naturally
— Remaining follow-up questions
— Any leading questions: only if you really must ask them (the "magic solution" question is better)
— Establish means for future contact if
necessary
Getting started: introductions
You may or may not have spoken with the interviewee before this. If this is a business setting, you most likely worked with someone else at this
124
Chapter 7 Understanding Potential Users and Customers
company who scheduled time with several people on her team. With consumer interviews, the market research firm may have passed on only the basic information you provided about what to expect from the interview. Your information may not have been transmitted clearly or completely. This means the first thing you have to do is establish who you are and why you're here. As with the recruiting screener or the e-mail you may have sent to the site contact, avoid being overly specific about what you'll use the information for; otherwise, the interview focus might get too narrow right away.
If you are offering an honorarium or other incentive, it's nice to get this out of the way up front, so interviewees can simply relax and not worry about when they're getting paid. Take care of any forms you need them to sign now if you haven't been able to do so beforehand.
Briefly describe how the interview will go and the sorts of things you'll ask. Mention that you'll be taking notes. Ask permission in a casual way for any recording but—if you can do so—reassure the interviewee that you won't be sharing the notes or recording with anyone else outside your team. You'll probably want to take photos, but people are usually more receptive if you bring this up later in the interview. Finally, give the interviewee the chance to ask any questions before you get started.
OVERVIEW QUESTIONS AND FOLLOW-UP
Start the interview with a broad, descriptive question. Although a detailed question list is often counterproductive—turning the interview into an interrogation rather than a conversation—the phrasing of the opening question is worth crafting ahead of time, because the answer sets the context for the rest of the interview. The idea is to get an overview of the relevant activities so you have a rich list of topics to pursue in greater detail. If you don't get this kind of overview early in the discussion, you may find yourself struggling to find the next question and introducing more
leading questions just to keep the conversation going. The right overview question will make it seem like the interview structures itself.
BUSINESS SETTINGS
In most business contexts, asking someone to walk you through a typical workday is a great way to start. The response to this will give you a sense of overall process as well as a list of specific activities. For example:
Interviewer: I'd like to hear about what your typical workday is like. Could you walk me through what you did yesterday, from the time you started work until you were done for the day?
Purchasing agent: Yesterday was pretty typical. The first thing I did was check my e-mail and voicemail to see if there was anything urgent. I do that every day. There were a couple of urgent things I dealt with first. After that, I did some follow-up with the vendors who needed something before they could get things shipped, then got through as many new purchase requests as I could. That's a challenge sometimes, between phone calls from vendors and people wanting to know where their stuff is. At the end of the day, I put the most urgent stuff at the top of the pile for the next day.
Even this brief response provides the basis for a whole series of follow-up questions, such as:
— What things were urgent enough to deal with first?
— How many purchasing-related messages were there to deal with?
— What were those messages about?
— How many were new requests and how many were follow-up?
Designing for the Digital Age: Creating Human-Centered Products and Services
— What kind of vendor follow-up is usually needed and why?
— Where do you find the information you need for that follow-up?
— Could you walk me through an example of how you create a new purchase order from a requisition?
— What are the phone calls or other interruptions usually about?
— Which of those interruptions are a waste of your time?
— What else happens in a typical day that didn't happen yesterday?
CONSUMER OR OTHER BROAD DOMAINS
The right overview question is usually a bit more challenging to find in consumer domains (or any other time that a typical workday isn't a useful starting point). A good overview question in these cases is usually a matter of focusing on the larger design problem, rather than an existing product.
Table 7.1. Good and bad overview question examples.
For example, "How do you use your television today?" may not be a great starting point if you hope to turn the TV into a home media hub. Instead, you're probably better off starting with, "What kinds of things do you do for entertainment at home?"
A good overview question elicits a lot of information about typical activities and how they fit together; the topics raised by the interviewee's response can often fill a large part of your interview time. Sometimes it's useful to be a bit vague, allowing interviewees to make what they will of the question, but if the question is too vague, the interviewees won't know where to start. A short series of two or three questions will usually cover the ground you need if one question isn't enough to give you a good overview. If an interview covers disparate activities, such as shopping for a product and getting support for it, you'll want to ask about shopping behavior, discuss that for a while, and then ask your second overview question about getting support after the purchase. Table 7.1 provides some examples; these are by no means the only possible overview questions for these situations.
Product Poor overview Good overview questions
questions
Business What kind of e-mail      We're interested in the various kinds of communication
e-mail system     do you use? you have with other people during a typical workday.
Could you start by walking us through what you did yesterday?
Consumer What kind of camera     What role does photography play in your life?
digital camera    do you have? What do you take photos of and how often?
Camera How do you use our      First overview question: Please tell us about the last time
company Web site? you shopped for a camera.
Web site Second overview question: Could you tell us about any
occasions since you bought your camera when you've wanted additional information or support?
126
Chapter 7 Understanding Potential Users and Customers
Although asking specifically about yesterday usually works in business settings with fairly narrow activities, be wary of getting too specific in broader domains. For example, asking someone about the last time she took photos might not be the most useful starting point, since it might be an example of her least typical photography situation. Instead, get a sense for what kinds of situations exist before you focus on one type of situation in more detail (followed by the others).
Unfortunately, the best overview questions are often socially awkward starting points, so you'll want to ask them after a few getting-to-know-you questions like those you might use at a company party, such as, "Tell me a little bit about yourself," or "How did you come to work here?" Once the conversation has started, take the next opportunity to pose your overview question.
Also note that the same overview question may not work for each role. If you're designing the end-user interface as well as the system administrator's tool for an e-mail application, you probably won't want to start the conversations with each type of interviewee in the same place.
Exercises
1. What overview question(s) would you ask potential users of the LocalGuide or Room Finder (see Chapter 6)? Don't forget to account for any different roles.
2. Imagine that you're trying to design a better grocery store. You've asked an interview participant to tell you about the last time she went grocery shopping, and she's given you the answer below. What follow-up questions would you ask based on the information provided in her answer?
"It was Saturday morning. There wasn't much in the house, so I went shopping to get food for the rest of the weekend. I went to a store I don't usually go to. I started in the produce section because I knew one thing I wanted to cook, and I was planning to see what was fresh to get inspiration for some other meals. They didn't have some of what I wanted, and some of the produce didn't look very good. I thought of a couple of other ideas, but had to wander around the store to see if they had the other ingredients. It took forever. I had to look in three different parts of the store to get milk, cheese, and cream cheese. I had to ask a stock person where to get the cream cheese. Once I figured out what other ingredients they had, I went back to the produce section to get the rest of what I needed. Of course, after I stood in line and eventually got everything home, I realized I'd forgotten one of the things I needed."
A good overview question elicits a lot of information about typical activities and how they fit together.
Designing for the Digital Age: Creating Human-Centered Products and Services
Essential interview topics
To do design later on, you'll need to understand the objects users work with, the things they do with those objects, and what skills they bring to bear on their tasks. You'll also need to understand their goals—their reasons for doing those tasks in the first place—and the frustrations that keep them from achieving those goals today.
An ethnographer such as Spradley would say most of the interview questions on these topics are either descriptive—focused on identifying and understanding the important things, concepts, and activities that exist in the domain—or structural, focused on how those things, concepts, and activities are related. Contrast questions help clarify descriptions and relationships by asking how things are different.
INFORMATION AND OBJECTS
To design an effective kitchen, you'd need to know what kinds of things get stored and used there; storage for cookie sheets is very different from storage for ice cream. If you knew roughly how many of each thing there were, you could be sure to get the right ratio of cabinets to drawers to refrigerator space. You could do an even better job if you knew how frequently things were used, so you could make the everyday dishes easier to reach than the best china that only comes out for big holiday dinners. This same understanding is required for good product design.
Note that the following discussion is an example of "thinking ahead to the design," in that it covers what you will need to understand later. Don't try to create a definitive catalog of objects and relationships during the interview, since in a complex domain this could easily consume an hour or more. Instead, seek out the information that will help you synthesize such a catalog later on. Don't be too dismayed if you miss a few things in any given interview, since the gestalt of all the interviews will help you fill in gaps.
Mental model objects
In 1943, Kenneth Craik posited in The Nature of Explanation that humans use internal representations (which may be based on imagination as well as experience and perception) to understand and predict events in the world. People act and react based on these mental models. When the conceptual structure and behavior of a system match a user's mental model, the system is generally easier to learn and use. While it is possible for mental models to evolve over time, system behavior that conflicts with user mental models tends to cause problems.
To create an effective system, designers must understand a user's mental model of the data: What are the meaningful object types and how are they related in her mind? Folders, documents, and other discrete collections of information are all types of objects; "chapter 8.doc" is an object of the "document" type and "chapters in progress" is an object of the "folder" type. In most enterprise settings, there are multiple object types. In an e-mail and calendaring application, for example, there are messages, groups of messages, appointments, and probably contacts. If it's something with multiple instances a user creates, it probably fits the definition of an object in your user's mind. There may be other things, such as user preference files, that are objects in the programming sense but that users don't think of as objects, which means they're not part of the mental model. Table 7.2 shows some examples of mental model objects.
The mental model objects aren't necessarily the same as the ones shown in an existing product's interface, though; these sometimes reflect what software engineers call the implementation model. For example, a clothing store database might note three separate product numbers for a navy blue sweater, a black sweater, and a red sweater of the same style. This structure is useful from the standpoint of inventory management, but it shouldn't be surfaced to shoppers, who will be
128
Chapter 7 Understanding Potential Users and Customers
Table 7.2. Example mental model objects.
— Messages
— Conversations consisting of related messages
— People
— Collections of messages that are related in some way other than as part of a conversation
— Photos
— Collections of related photos (represented by an envelope or box in the physical world, or by a folder in the digital one)
— Collections of related photos that have been arranged in some way (a photo album in the real world, a Web page or other layout in the digital realm)
Design problem       Likely mental model objects
E-mail system
Organizing photos
Camera company     — Products
Purchasing — Requisitions
agent's tools _ purchase orders
— Invoices
— Vendors
Family calendaring — Family members system _ Events
frustrated if your site has three separate listings for what they think of as a single sweater available in three colors. In other words, in a shopper's mental model, each clothing style exists as an object; things like color and size are variable attributes. People who have used a system for a long time may eventually become accustomed to the fact that it represents the back-end implementation in the interface, but this doesn't mean it's a natural structure that was easy for them to learn.
Try to understand whether it's the implementation itself that has meaning for the interviewee, or whether the implementation just happens to
approximate a mental model object that's slightly different. For example, people accustomed to film photography may refer to a "roll" of film as a meaningful collection. However, people who have used only digital cameras have never encountered the concept of a "roll" and don't seem to miss it. It's not that they substitute the "memory card" for the word "roll"—they're also unlikely to say "Oh, that was on the same card as this," because they can process images at any time; they're not limited to either waiting for the roll to fill up or wasting film by processing half a roll. So what's useful about the roll concept? It often represents a group of pictures taken at the same time, such
129
Designing for the Digital Age: Creating Human-Centered Products and Services
as at an event or on a particular vacation. That time-related grouping, not the roll, is the mental model object. Seeing people use different systems will help you uncover such distinctions.
Of course, if you ask someone directly to describe his mental model of the data, you'll get a blank stare. Listen and observe for a while to see if you can identify some of the objects, then use them as examples to elicit others. Try asking something like this: "I've seen you work with three types of documents so far: purchase orders, service orders, and requisitions. What other types of documents do you use, and why?" Given that small amount of structure as a starting point, most interviewees can help you fill in the rest, though they're still likely to leave some out unless they're telling specific stories, demonstrating processes, or looking at actual artifacts.
Don't be shy about asking for definitions or distinctions, such as the difference between a requisition and a purchase order, even if you think you know the answer. This is one place where the interviewer who is ignorant of the domain has an advantage, because people who think they know what the terms mean may miss the fact that the word "report" means three different things in three different companies. Asking about distinctions can help clarify which ones are truly meaningful to the interviewee. For example, a purchasing system we were redesigning made a distinction between purchase orders (for goods) and service orders (for everything from consulting to light bulb installation). When we asked about the distinction, a number of the purchasing agents told us they were "really the same thing" even though the system didn't seem to think so. If they started creating a purchase order and later realized they needed a service order because something like installation was included, they had to start over because it required a couple of different fields.
Details (attributes of the objects)
Many people confuse mental model objects with database fields. An insurance underwriter, for instance, cares about how many properties are covered by a policy, what their total insured value is, and what deductibles, premiums, and limits are applied. However, all of those bits of information, which exist as fields in a database, are attached to policies. They're meaningless without that attachment, which means they're not objects, but are important attributes of objects. Table 7.3 provides some examples of meaningful attributes for various mental model objects.
Don't be shy about asking for definitions or distinctions even if you think you know the answer.
130
Chapter 7 Understanding Potential Users and Customers
Table 7.3. Examples of meaningful attributes for mental model objects.
Objects Example attributes users care about
E-mail message — Who sent it
— Who else received it
— When it was sent
— What it's about
— What's attached to it
— What action was taken on it (forward, reply, etc.)
— How urgent it is
People (business contacts)       — How to reach them
— Where they work
— What their titles are
— Important personal details (birthdays, etc.)
As you identify meaningful types of objects, you should also be asking for details about the properties of those objects, such as:
— What information goes into a purchase order?
— How many items are in a typical PO?
— What's the biggest number of items you've ever put on a single PO?
— Is the format always the same? Why does it vary?
Try to get what detail you can about the typical contents and attributes of reports, forms, or other objects, but recognize that you won't be able to cover all of this in an hour unless the domain is very simple. Whenever possible, ask if you can take photos of typical examples like the one shown in Figure 7.2. Better yet, get copies of a few. When dealing with sensitive data, such as medical or financial records, you may not be able to do so; ask if you can at least have a blank form. In some cases, it's acceptable to copy such a record if any identifying information
is covered up. Failing these options, try to take a moment to sketch the approximate contents and format (minus the confidential information) in your notebook.
6/22/2004 Murliwts 51JB55 loiniula and Minerals one capsule oral Onoe Daily
6/t&20U3 Glybunde Sung tablet oral BID
~6yJ2/2004 ALDOMET iMemyldopale HCT l^bmg tablet oral BID
-&22/20M REFRESH TEAHK (Sodium
cariMnymeinylceiiulose) 2 drops Both Eyes TID Give As: 0.5% -IS2/2KI5 ZANTAC (Ranitidine HU| liiUmg lablet oral Every day at bedtime
Give As: 2 75mg ^____
6J22/20M TYLfcNUL ^,B™°pnn^'
Give As: 2 325mg
Figure 7.2. This is a good example of a form to get a copy or photo of in an interview. Take note of the form content and design as well as the extent to which it appears to work. What scribbles have people made? Does the format appear to break down in any way, or is it working well?
131
Designing for the Digital Age: Creating Human-Centered Products and Services
Also, try to identify which of these attributes or details users actually care about. Chances are that no one will mention file size as an interesting attribute of an e-mail message; what people truly care about is whether an attachment will make it through the recipient's email system. Similarly, you need to know roughly how many items a purchase order might contain so you can design appropriately, but this doesn't mean purchasing agents want to see a running total of how many lines there are in the document. Note what information your interviewee has emphasized, such as that shown in Figure 7.3.
10 I 11 I 12 \ 13 \ 111 IS I 16 117 pap
= NT NOS (S/P) (436.0) DX: DIABETES W SE NOS (437.9)  DX: DEPRESSIVE DISOS
AllergiesJNotes
■
30
TOMATOES
Figure 7.3. Note how a nurse has manually highlighted the allergy information on this medical record to make it stand out. This is the patient attribute she most needs to see at a glance.
Though it's best to get as much information as you can, missing some details won't be a problem as long as you have access to the same users or a subject matter expert later in the project.
Relationships
You also need to see how each type of file or information is related to the others.
"Any-to-any" relationships are common in most applications. These may be:
Many-to-many
Many-to-one
One-to-many (many-to-one from a different perspective)
One-to-one
Many people may send many messages
Many people may live in one city
One city may contain many people
One person has one legal spouse
However, these descriptions are only the starting point. Object types often have various hierarchical and dependent relationships, as well. Table 7.4 shows examples of each type.
In a hierarchical relationship, one type of object contains another. If two object types have a dependent hierarchical relationship, one type of object cannot exist independent of the other. This dependency can go either up or down the hierarchy. For example, a suit consists of a matching jacket and pants. Someone getting dressed in the morning might look for her black suit, or may just want the pants that are part of the suit. The jacket and pants exist independent of the suit, but the superior object type, the suit, does not exist without both inferior objects, the jacket and pants. A bank transaction is an example of an inferior object that cannot exist without a superior object, which is an account. Albums and photos, on the other hand, have an independent hierarchical relationship: Photos can exist without albums and albums without photos, though empty albums are uncommon.
Another type of dependent relationship is temporal: One type of object is created using another object as its basis, and largely removes the need for the original object. In corporate purchasing, for example, someone creates a requisition that asks a purchasing agent to acquire some product or service. The agent then creates a purchase order that serves as an agreement between the
132
Chapter 7 Understanding Potential Users and Customers
Table 7.4. Examples of object relationships.
Objects Examples of relationships
E-mail messages      — One sender (person or company) to one or many recipients
— May or may not be part of a longer conversation
— May or may not exist in some other collection of messages with a shared topic (such as a project folder) or other properties (such as a folder of new or deleted messages)
— Dependent on the existence of a sender and (usually) one or more recipients (Whether a message is dependent may seem ambiguous if contacts don't exist as remembered objects in the system, but in the average human's brain, there's no such thing as a message not created by a person or company.)
Conversations of — A superior object that's dependent on the existence of two or more related messages inferior message objects (an initial message and at least one reply)
Contacts (people — Independent objects that may get messages from one or many people, or companies) send messages to one or many people, and participate in multiple
conversations
Inbox — An independent object superior to messages
company and the vendor. The requisition must exist before the PO is initiated, but the requisition has largely served its purpose once the PO is created; the only reason for its continued existence is to provide an audit trail.
Just as you can't ask users what data objects exist in their heads, you'd get a blank stare if you asked about hierarchical and temporal relationships in an interview. Instead, look for clues that a certain type of object may exist, then learn about it using structural and contrast questions, such as, "What does a photo album contain?" or "How is a requisition different from a PO?" Follow these with the sort of clarifying questions Spradley describes as semantic relationship verification questions, such as, "I understand that a portfolio can contain accounts. Does it ever contain other portfolios?" or "Would you ever have an empty portfolio?"
Don't try to draw a mental map of relationships in your head during the interview; this discussion of object types and their relationships is merely intended to illustrate the kind of information you need to get from the interview. However, do take a few minutes afterward to think through the object types and relationships with your teammates to see if you understand them. If not, you'll know what you need to get clarified in the next interview. By the time you're done with your research, you should be able to describe these relationships with no trouble at all.
Quantity
You also need to understand how many of each object type there are overall and how many are accessed in a typical session or day. Exact quantities aren't necessary; you just need to
Designing for the Digital Age: Creating Human-Centered Products and Services
know whether people have dozens, hundreds, thousands, or many thousands of files, since this will affect how you design the file-management behavior. This information may reveal itself in the interview without you having to ask. If the informant indicates a quantity, see if your observations match her numbers and ask about any disparity. It's usually just self-reporting error, but sometimes those differences can be due to some behavior you haven't heard about so far. An interview with a professional photographer is a good example:
Interviewer: You mentioned that you typically take 400 pictures in a day of shooting, but each day's folder seems to contain a lot less than that. Are the folders I'm seeing not typical, or is there some other reason for that difference?
Photographer: Hmmm. No, these are about the usual size. I do take upward of 400 shots at a time, but that's just what I start off with. Well no, actually, I probably take closer to 500, since I delete some from the camera as I go, then wind up with maybe 400 to load onto the laptop. But then I trash at least a quarter of them when I first import from the camera, if I can see from the thumbnail that the exposure was off or the frame didn't capture quite what I wanted. I usually get rid of a lot more as I look closely at each one, so I'd guess in the end I have 200, maybe less.
Does every product involve "objects?"
In consumer applications with very simple data structures, people don't see themselves as working with files, but they're still looking for certain things or pieces of information. Imagine for a moment that you're designing a touch-screen information kiosk at a shopping mall. The mall management might think of the various things people need as merchants and services, but you
need to understand whether this makes sense to the people who will use the directory. You might find, instead, that people think of stores, food, and restrooms. Knowing how people think about that information is still important, even if the data is very simple.
ACTIONS
Of course, nouns aren't much use without verbs. To belabor the kitchen analogy I used earlier: Peeling vegetables, cooking them, and cleaning up afterward are all activities that require different tools and workspaces. Similarly, the things people do with information and objects will require different tools and possibly different workspaces in your product.
As with objects, you first need to understand what types of activities there are and what's involved in each. The overview question is a great starting point. Once you've covered what's involved in a typical day, recap the activities you've seen and heard about, then ask what others happen less frequently. Continue doing this until the interviewee doesn't have any more tasks to discuss.
Reasons for each activity
Understanding the tasks is important, but it's equally critical to understand why the tasks even exist. What goal is the task supposed to help achieve? Is the task something people believe is necessary, or do they do it because a bad system forces them to? In redesigning an online pharmacy, for example, we learned that most people just wanted to get their prescriptions filled online because it was cheaper and potentially more convenient. They were all happy to provide their names, addresses, and insurance information at registration because they saw how this information would help accomplish the goal. However, they were frustrated by any question that didn't seem to serve that goal, such as what health topics they wanted more information about.
134
Chapter 7 Understanding Potential Users and Customers
If some activity doesn't seem to make sense, that's a good indication that you should be asking, "Why is this important?" You'll either find that the participant says, "It's not important, but my company/boss/ software makes me do it," or you'll learn something very useful. I once encountered a nurse manager who spent considerable time copying patient problems from the paper medical records into her own spreadsheets. When asked why she did this, she explained that any increase in certain conditions or types of incidents would help her see potential problems with the quality of patient care. This pointed to a tremendous opportunity for using an electronic medical record not just to replace paper entry, but also to make clinical managers more effective by helping them identify and analyze problematic trends.
How tasks are performed and described
The way tasks are performed is also useful to observe. What information does the informant have when she begins a task? What steps follow from that? Where does she expect to find certain things? See if you can determine whether what you're seeing is the mental model at work or the result of poor implementation.
Listening to interviewees describe their tasks (using what words and in what sequence) can be informative. For example, most of us who convert documents to PDF eventually learn that we need to go to the print dialog and pick PDF from the list of printers on a Windows PC. However, most users will say, "And then I save the file as a PDF." This function may reside in the print dialog because of the format's desktop publishing origins, but novice users are inevitably flummoxed because they view the action as exporting or saving in a different format rather than as printing.
In another example, some colleagues who were designing a PDA specifically for teenagers heard their interviewees describe their next classes or other time commitments in terms of a countdown. Whereas most adults say, "I have a meeting at 3:00," teens would say, "I have 40 minutes until I have to be in class." Their focus was not on what they needed to do, but was instead on how much time they had free before they had to do something.
If you're not sure why someone is doing things in a certain sequence or manner, ask. Sometimes it's because people just think that way, but it could also be because the tool forces them to do so, or because system performance is better one way than another. This is one of the reasons it's so helpful to see people who use your current product (if there is one) as well as people who don't: It highlights where your system might be doing things in an awkward way.
Understanding the tasks is important, but it's equally critical to understand why the tasks even exist.
135
Designing for the Digital Age: Creating Human-Centered Products and Services
You'll probably have to rely on self-reporting to understand task frequency and priority, so look for clues to validate this information.
Task frequency and priority
It's easy to assume that frequency and time spent imply importance. A task may be necessary, but the amount of time spent on the task might just indicate that the existing tools are inadequate. The purchasing process is a good example. Many people view purchasing agents as human automatons who exist to type things into purchase order forms. Although agents do spend most of their time doing this, the important parts of the job are actually sourcing and negotiating: finding the vendor who will provide the best quality and customer service in the right timeframe, then getting the best price (or vice versa). Your job as a designer is to maximize the time users can spend on important things and see how much you can automate the rest. Of course, time spent on a task can also indicate enjoyment; a teenager who spends an inordinate amount of time playing video games isn't doing it because he has to.
Unless you can afford to do an extended field study with each participant, you'll have to rely primarily on self-reporting to understand task frequency and priority, especially for tasks that don't take place on a daily basis. Ask how often people perform each task, but look for clues to validate this information. If an interviewee tells you he transfers photos from his camera every couple of weeks, see how accurate this is by looking at the date stamps on the files.
To understand priority, ask questions like these:
— What things do you usually do first, and why?
— What do you put off as long as you can, and why?
— What things waste your time?
— If you had more time to spend on just one or two things, what would they be?
— What keeps you from spending more time on those things now?
Of course, the answers to these questions might illustrate other issues; if someone puts off a task, it might be unpleasant but still important. Asking why someone procrastinates will help you assess whether the behavior reflects priorities or is a symptom of inadequate tools or processes.
The role of the current product
If you're redesigning an existing tool or developing a competitive product, observe what parts of each task take place in that product and what parts take place outside of it. Are there opportunities for streamlining by
136
Chapter 7 Understanding Potential Users and Customers
integrating certain tasks currently performed elsewhere? For example, some of my colleagues working on a computer-assisted surgery system saw assistants holding up pieces of paper outside the clean zone, but where the surgeons could see them if they leaned over and squinted (see Figure 7.4). It turned out that most of these were handwritten pre-op notes the surgeons had taken but couldn't access via the surgery system. The team couldn't determine at that point whether such notes should be available in the system, but it was the sort of workaround that merited close attention.
Also be honest with yourself about how large a role your product really plays in the interviewee's day; will someone who refills a prescription once
Figure 7.4. This surgeon performing a knee replacement had someone bring him a printout with data not available in his assisted surgery system. The design team knew this must be important information, so they asked what it was and why it was on a sheet of paper.
a month be frustrated by going to her "inbox" on your Web site to see if her order is delayed, rather than seeing that information in her own e-mail inbox? Many of these things should come up naturally as users demonstrate their activities for you.
Good questions about current products might include:
— How often do you use the product?
— What do you most often use the current product for?
— Could you show me how you do that?
— What other tools do you use before turning to this product?
— What tools do you use alongside it?
— What tools do you use after this product?
— How would you compare this product to others you've used for the same tasks?
When there's no single product currently filling the niche you're aiming for, these questions may seem less useful. However, you can often ask similar questions about other products that do parts of the task, or even about existing paper or informal systems (such as hallway conversations).
Relationships with other people
Surprisingly few activities involve only one person, so it's usually necessary to understand what roles other people play in any process. With enterprise tools in particular, there are often opportunities to improve the information flow upstream, downstream, or both. Even in a consumer environment such as a family, you might need to understand such things as how parents want to control what children can see online, or how various family members annoy one another by changing the television settings. Of course, you're not trying to identify the solutions during the course of the interview; you're simply trying to see where the opportunities for improvement might exist.
137
Designing for the Digital Age: Creating Human-Centered Products and Services
Relationships with other people can be a sensitive subject, so it can work better to bring this up somewhat later in an interview, except where the interviewee touches on relationships with respect to a particular task. Effective questions about relationships will vary, but in a sequential workflow (such as a purchasing process or call center), they might include:
— Who provides the information you use in this process?
— How do you get that information?
— What's inefficient or ineffective about that process?
— Who reviews or consumes the results of your work?
— What do you provide to them?
— How well do you think that meets their needs?
— What kind of extra effort is required on your part?
— Who else is likely to touch this file?
— Why might multiple people work on it?
— What do they do with it?
— When you get the file, what do you need to know about what they've done?
— What problems arise from having multiple people work on it?
Questions about real-time collaboration differ somewhat. If you were to design a remote meeting tool, for example, you might ask:
— What kinds of information do you need to share during the course of a meeting?
— How often do you use information you already had prepared, and how often are you looking for other information?
— How does each participant need to interact with that information?
— What do you find yourself doing in remote collaboration that you don't do in person?
— What do you miss about in-person meetings when collaborating remotely?
Collaborative activity is messier and less predictable than a more linear process, so observation of the behavior is even more critical.
Workarounds
You may observe people apparently circumventing a procedure. Ask whether they're doing so and why, perhaps with a reassurance of confidentiality. For example, when designing a hospital glucose meter for
Collaborative activity is messier and less predictable than a more linear process, so observation of the behavior is even more critical.
138
Chapter 7 Understanding Potential Users and Customers
bedside testing, my team saw nurses asking other nurses for their operator IDs. From a regulatory standpoint, a glucose reading is a laboratory test, and any operator performing a lab test must be periodically recertified on the instrument she's using. This recertification is so low on the average nurse's priority list that it's common for certifications to expire. Unfortunately, the patient's test had to be performed regardless of the nurse's certification status, so having the instrument block nurses with expired certifications actually introduced a worse regulatory problem: inaccurate records of who administered the test.
If you haven't seen anyone circumvent a procedure, it doesn't mean they don't; they may just be on their best behavior for you. Once you've established a good rapport with your interviewee, try asking about any procedures that don't work for them. "I know that in a lot of places, there are procedures or rules that seem like a good idea, but that end up getting in the way. Are there any of those you find yourself working around?"
Listening to user frustrations is the product designer's equivalent of asking a patient where it hurts.
FRUSTRATIONS
Listening to user frustrations is the product designer's equivalent of asking a patient where it hurts. As your informant relaxes during the course of the interview, he will probably raise a number of frustrations on his own. He may not explicitly say, "This frustrates me," but it will be obvious from his tone that it does. When describing the process to confirm that a shipment had arrived and was correct, an interviewee once said to me—in a thoroughly disgusted tone—"It takes me 23 clicks just to say that the box is here!" His number may or may not have been accurate, but the fact that he took the time to count clicks spoke volumes about how cumbersome the process was.
Once you've covered the range of activities and heard some of the related frustrations, it's still useful to ask more explicit questions about what makes people cranky. If the interviewee has been forthcoming about pet peeves, one good approach is to recap some of them, then ask what else seems more difficult than it ought to be. If your participant has been too polite to complain, try asking what handful of things about the product could most use improvement.
Though it can be a less informative line of inquiry, also consider asking what works well about the product or process today. People usually struggle with the answers if the question is too broad, since it's easier to point at problems. Try asking what the best thing about the product is or what useful thing it lets the interviewee accomplish that she couldn't do before. If you're introducing an electronic system that substitutes for paper or for conversation, ask, "What about how you do
139
Designing for the Digital Age: Creating Human-Centered Products and Services
things today would you not want to lose in an electronic system?" Ideally, asking about what's good will point to some areas that don't need as much of your attention. If you have an existing product, it may also help remind participants that even though they've just given you a long list of gripes, there are good things about your product, too.
SKILL
By the time you wrap up your interview, you should have a good idea of how skilled and experienced a particular interviewee is relative to others, provided you've already done more than a couple of interviews. This will give some context to each person's behaviors and frustrations, while also helping you assess what amount and type of support you need to provide.
Assess both skill and experience with respect to three things: technology in general, the existing tool in particular (if there is one), and the domain. This will help you determine how much support to provide in the design, and of what kind. People who are comfortable with technology in general may be more likely to poke around in a new tool to figure it out. Knowing whether people are comfortable with your existing product will help you assess what kind of learning curve really exists today.
Perhaps the most important aspect of skill and experience is how much people know about the domain of the problem. Sometimes a role implies a certain level of skill. A nurse, for example, knows how to be a nurse; she will likely be offended if a product attempts to tell her how to do her job. A call center agent, on the other hand, typically has little training or experience, and may need help with determining how to handle a call. With some design problems, though, you'll see a variety of skill levels; a tool for organizing photos might have to address the needs of both professional photographers and people who simply take family snapshots.
To assess experience with the tool or domain, you don't have much choice but to trust the interviewee's assessment. You can often get a sense for experience by casually asking about it prior to your overview question. "How did you come to be in this job?" and "How long have you been using this product?" are good openers in a work environment. Don't delve too deeply into experience at first, or it will start to feel like a job interview and upset the "user-as-expert" dynamic you're trying to establish in the conversation. Later on, as the discussion starts to wind down, you might say, "You certainly seem to know your way around an emergency room. How long have you been doing this?" or "You seem to know a lot about the technology. What did you do before this?"
Assessing skill can be difficult. It's not a good idea to ask the participant to assess his own skill because he may not be comparing himself to the same measures you are. It may seem presumptuous or even absurd for a designer to assess the skill of a professional in a field other than her own, but, thankfully, you're not deciding whether to hire someone; you're simply trying to assess how skill level affects behavior. It's possible to develop a sense for skill level just from how people use language. Compare how these two photographers talk:
Photographer A: If the lighting doesn't seem very good, sometimes I turn the dial to the low-light setting.
Photographer B: If I'm not sure about the lighting in an action shot, I'll set my shutter speed first, then bracket the exposure. I pick the aperture I think is right based on the metering, then take a shot at one f-stop on either side of it.
It seems pretty obvious just from the photographic vocabulary that Photographer B is more sophisticated. Of course, it's possible that Photographer B still doesn't take very good photos, so it's probably more accurate to say we're really assessing
140
Chapter 7 Understanding Potential Users and Customers
knowledge or comfort with the domain rather than actual skill. The only way to get a better appraisal of skill is to have a subject matter expert accompany you and make the same assessment.
GOALS
Truly great products and services help people accomplish not only their tasks, but also their goals. Searching for restaurants, reading reviews, getting directions, and making reservations are all tasks; enjoying a terrific dinner is a goal. Later in the process, goals will help you identify and prioritize features and design product behavior.
Goals may come up at any time in the course of the interview, but they're hidden among other bits of information. Some goals are expressed in the context of frustrations. For example, a manager might say, "I spend so much time responding to little crises that I have no time to plan ahead. That's a big problem." Being able to plan ahead certainly sounds like a goal.
People describing their behavior can provide clues about goals, too, as illustrated in this comment by an elderly woman who lives alone and seldom sees friends or family: "I have my programs that I like to watch. In the afternoon, I'll sit and have a cup of coffee with Ellen. Mostly I just leave the TV on for noise." If you realize that Ellen is the host of a favorite talk show, you might also notice that the interviewee describes watching the show as if it were a social engagement with a friend. Between that and the fact that she describes leaving the television on "for noise," her behavior seems to point to alleviating loneliness. Rather than assuming this, though, the interviewer follows up with a comment to see if her interpretation is accurate:
Interviewer: It sounds like you use the television as a way to have people around during the day.
Interviewee: Why, yes, I suppose you could put it that way. Since my husband passed last year, it gets so quiet. It's a little lonely sometimes.
Observed behavior can also point to possible goals. After watching an interviewee create a task and then cross it off his to-do list with a flourish, you might observe, "You really seem to enjoy crossing things off your to-do list." The participant will probably confirm your interpretation with something like, "Yeah, it always feels good if the list is shorter when I leave than it was when I came in. This job is kind of like doing laundry: There's always a pile of stuff to do, so you have find ways to feel like you accomplished something."
Goals may come up at any time in the course of the interview, but they're hidden among other bits of information.
141
Designing for the Digital Age: Creating Human-Centered Products and Services
As with most aspects of interviewing, you probably won't get a useful answer if you ask someone directly about goals. However, there are a couple of questions that tend to elicit information about goals. The one that's usually most effective is some variant of "What makes a good experience?" Phrase this in terms more specific to your design problem:
— What makes a good shopping experience?
— What makes a good workday?
— What makes a good travel experience?
It's also helpful to use this as a follow-up question when someone describes an experience and seems pleased about it. "It sounds like you enjoyed your experience. What made it good?" In the rare instance that the good experience question doesn't seem to work, you can try its opposite: "What makes a bad experience?" The answers to this are probably the opposite of goals, so the goal might be for those bad things not to happen.
Understanding why someone undertakes a particular activity in the first place can also reveal goals. Consider these reasons cited for taking photos:
— I take pictures because she's growing up so fast. Now that she's two, I can barely recall what she was like at one.
— When I see a gorgeous bird, or an unspoiled landscape, or some other amazing thing, I want to make an image that will convey how incredible that is.
— When I'm designing a garden, I take pictures of what's there now to use as a reference while I'm designing. After the landscape is done, of course, I take pictures of it for my portfolio to show people I can do great work.
These statements indicate that these people all have different goals: remembering an evolution over time, capturing an impression of something, and facilitating work and sales. All imply slightly different things about what the product design must accomplish.
Observation and the guided tour
Throughout your discussion, you will hopefully observe people using their tools and interacting with their environments as they demonstrate typical activities. If these activities have not led to explanations of various things in the work setting, at some point you will need to ask for a sort of guided tour of the environment and artifacts. This is also a good technique to fall back on if you're only partway through an interview and have no idea what to ask next.
The observational aspect of an interview involves developing an eye for anomalies and details. What in the environment looks like it might be related to the problems you're trying to solve? What seems out of place or unexpected? What things are placed close at hand, and which are tucked away in inaccessible spots? How have people added to or altered their tools? Which other conditions—distance from the screen, distractions, lighting, and so on—will dictate aspects of your design?
ERGONOMICS
In solving any design problem, it's important to look for ways to decrease fatigue and stress on the body. For desktop-based systems this means reducing eyestrain as well as unnecessary mouse clicking and typing.
Varied lighting conditions are a common challenge in designing anything with a digital display. The radiologist reading digital films in Figure 7.5, for example, is doing so in a dark room to enhance
142
Chapter 7 Understanding Potential Users and Customers
Figure 7.5. A radiologist reads digital films in a dark room.
the contrast and detail he can see on the screen. This means your interface will need to be optimized for that dark room, with no high-contrast screen elements that compete with the images. A surveyor using a GPS device outdoors, on the other hand, may struggle with screen contrast not being great enough to be readable in full sunlight. This has important implications for your hardware (if it's custom) and visual design.
Device design offers a whole host of other possible ergonomic problems. These are largely the province of the industrial designers on the team, but interaction designers should be aware of these issues if an industrial designer isn't along for the research. When redesigning a pole-mounted medical device with a screen that was meant to be read at eye level, for example, we found that nurses were mostly mounting the device at waist height, then crouching to read the screen. At about 30 pounds with all of its attachments, the device was difficult for nurses to lift above waist height while also tightening a large screw clamp on the IV pole (see Figure 7.6).
Figure 7.6. This heavy device has an awkward screw clamp, so this nurse is trying to support its weight with her leg while she gets the device fastened to the pole.
CONTENTS OF THE ENVIRONMENT
In a work environment, consider what things are available and where. Why are certain things close at hand and others not? Also look for anything that seems unusual. If an office worker has a printer at her desk, why is it there? These things are sometimes clues to inadequate systems. I once interviewed a purchasing agent using a supposedly paperless system who had crammed two large file cabinets into his cubicle. When I asked him why they were there, he said, "Just because I can get a PO into the system doesn't mean I can get it out again." Someone either hadn't anticipated the need for him to review older purchase orders once they were created, or that functionality was difficult to find or use.
143
Designing for the Digital Age: Creating Human-Centered Products and Services
Also look at things like to-do lists, whiteboards full of work in progress, or other textual artifacts that might provide clues to activities or objects that haven't been mentioned. You might be able to tell at a glance that some things are entirely unrelated to what you're working on, while others might take more scrutiny.
Don't feel like you have to sneak peeks at things; this likely won't give you good information and might just make you seem nosy. Instead, say something like, "Just to make sure we're not missing anything important, it would be very helpful if you could you give us the grand tour of your workspace and tell us what everything is and how you use it. Could we start with these different piles of paper on your desk? What's in them, and why are they in different piles?" Follow up with specific questions about each artifact, such as why things are done or represented in certain ways, or how typical these examples are (see Figure 7.7).
UNUSUALLY HARSH CONDITIONS
In the electronic world, desktop computers have it easy: They sit in one place where they're
protected from the elements. Everything else, from laptops to mobile phones to military devices, has to put up with more: extreme temperatures, dirt and dust, shocks, moisture, even submersion. Understanding where and how people will use a device is essential. Even if you're not tasked with the industrial design of a product, take note of these difficult conditions and pass them on to the appropriate people. On one project, for example, we saw a medical device that suffered from serious deterioration of its screen in some hospitals, while the same device looked fine in other facilities. It turned out that California regulations required the device to be cleaned with bleach between uses, which the original materials specification had not accounted for.
SIGNS OF DESIGN FAILURE OR UNMET NEEDS
Where there are cheat sheets, notes, or passwords taped to a monitor or tacked to a cubicle wall (such as in Figure 7.8), this could be a sign of infrequent use, but is more often an indication of a design failure or unmet information need.
in*
■.ihhiiil:......h\
Figure 7.7. The interview team asked this nurse multiple questions about the sticky notes on her clipboard. What are they for? What do the notations mean? Is there anything significant about the arrangement? Why sticky notes?
Figure 7.8. When we were doing research to design an IV medication pump, we often saw unit conversion and dosage information for the most common medications taped up on the wall of the nursing station. This was a clear indicator of an unmet need.
144
Chapter 7 Understanding Potential Users and Customers
If the product involves hardware, how have people altered it? It's common to see voicemail passwords or forwarding instructions taped to telephones, or signs on checkout-counter card readers that say, "Press THIS button     We once had a phone system at Cooper that displayed a blinking red light to show that the system was on. It drove most of us crazy because when we saw the red light, it seemed like we either had new voicemail or had someone waiting on hold. Within a fairly short time, pretty much all of the designers had covered the red light in some way, either with black permanent marker or with electrical tape. (Non-designers were less inclined to take matters into their own hands.) Figure 7.9 shows another example.
Figure 7.9. This note, which is attached to a shared computer running a customer relationship management system, shows that this company has created an official workaround for a system shortcoming.
Physical damage can be another sign of either an engineering or design failure. In many cases, a design change can eliminate the need to spend a small fortune on stronger plastics or shock-absorbent materials. On one project to redesign a complex device, we saw numerous instances of cracks in a plastic access panel that users often had to open. It would be easy to assume the plastic just wasn't sturdy enough, but we were able to identify a design cause for the problem: The latch
for the access panel was on the side of the device, but users kept tugging at the bottom of the panel, where the affordance of a curved indentation in the plastic all but yelled, "Pull me!"
Another way to spot possible hardware design failures is to look for protective covers or other adaptations that shouldn't be needed for ordinary use, such as the case I bought to keep my exceptionally slippery cell phone from leaping out of my hands like a wet bar of soap, or the protective sheet I use to keep my laptop keyboard from making a permanent imprint on the screen when it's closed.
GETTING PHOTOS
Unless you are in an especially security-conscious environment, most people don't object to photos of their workspaces, whiteboards, or even their to-do lists. Ask in a casual way before taking any photos, and reassure people that those photos are only for reference within your product team. If you plan to make broader use of the images, you will usually need permission in the form of a signed model release for anyone who is identifiable in the photo. Also, be aware that photos you take will probably be covered by any nondisclosure agreements your company has signed.
Exercise
These activities are not quite the same as what you'll do in an interview, but they're good practice for noticing details and considering what they might mean.
— Spend time in another person's work or study space. How is their space arranged differently from yours? What kinds of things are on the desk? What seemingly unusual things might you ask questions about?
Continued
Designing for the Digital Age: Creating Human-Centered Products and Services
— Spend a half hour or so in a busy public place such as an airport or shopping mall. What things are people carrying with them? How are they dressed? What are they doing as they sit or walk? Hypothesize about their backgrounds and why they're here; consider what kinds of questions you would ask to test your hypotheses without leading your interviewee.
— In the ordinary course of your day, observe someone doing some kind of work you're unfamiliar with: a travel agent making a reservation, a store clerk using a computer to see whether something is in stock, or a barista at the coffee shop using a touch-screen order system. What strikes you as an interesting design issue?
Wrapping up the interview
You can finish most interviews in 45 minutes to an hour. Unless the domain or design problem is exceptionally simple, you're probably missing something if you do a 20-minute interview. As things begin to wind down, check the margins of your notebook (or wherever you've made notes about things to follow up on) to make sure you've got everything covered. Turn to your teammates and ask if they have any additional follow-up questions. If you have any leading questions you really feel you must ask, now is the time to do so.
When you're done with your questions, tell the interviewee how much you appreciate his time and help. If offering an honorarium that you can't pay up front, let him know when to expect a check in the mail. Finally, establish some means for contacting him again if you have follow-up questions (and whether he's willing to answer); also make sure he knows how to contact you.
Dealing with challenging interview circumstances
Not every project involves ideal interview circumstances. Whether due to the nature of the design problem or to some constraint of time and budget, you will sometimes find that the techniques described here need to be adapted in some way. Some of the common challenges and adaptations follow; no doubt there are other circumstances not covered here.
LANGUAGE AND CULTURAL DIFFERENCES
If your product or service has an international audience, it's a good idea to conduct research internationally if the budget will allow it. This may mean you're speaking something other than your native language, or that the interviewee is doing so.
If you're both reasonably fluent in a common language, you can probably do without a translator, but you should allow some extra time for finding vocabulary words or explaining difficult concepts. Scheduling an hour and a half should be sufficient. If the language barrier is such that you need a translator, plan on two hours, since everything you'd ordinarily say in an hour has to be said twice. If the translator is a colleague or member of the sales team rather than a professional interpreter, be sure they understand that you need the most precise translation they can manage, since how interviewees say things can be as important as what they say. Even a professional translator will be most effective at helping you if you meet beforehand to discuss your interviewing goals and techniques.
Interviewees may already feel like they're going to be judged, so speaking in a language other than their own can increase their anxiety. Some will apologize for not speaking as well as they'd like. It can help to find some self-deprecating way to thank them for the courtesy of speaking in your language: "Thank you so much for agreeing to
146
Chapter 7 Understanding Potential Users and Customers
speak with us in English. I wish I spoke German half so well. I'm afraid I'm limited to asking for directions!"
Cultural differences are usually not a tremendous barrier. If your company or client has a local sales office where you're interviewing, the staff there can usually help with a cultural "dos and don'ts" list. Failing that, a local market research firm that's helping with recruiting should be able to offer some tips, such as whether it's considered rude to take notes without asking.
CHILDREN AND TEENAGERS
Speaking of cultural differences, the gap between teens and older adult interviewers can pose similar problems. My colleague Ernest Kinsolving shared this bit of excellent advice about interviewing them:
"Take them seriously. This may sound trivial and obvious, but it's essential to treat their observations, concerns, and lives as truly significant and worthy of serious attention. It can be easy for an adult interviewer to trivialize the issues that are of significance to a teen subject, since most of us have moved on to other concerns and don't necessarily remember what it was like to be 14 or 16 and know absolutely that life and death hinged on your standing on the crew team or whether you were wearing the right pants."
Teens may be more reticent about sharing with adults, whether it's because they think you don't care about the details, or because they're concerned about getting in trouble. You may need to reassure them more than once that what they say won't be passed on to their parents, teachers, or peers. In general, though, they'll appreciate being treated as adults. The same techniques that work with adult interviewees, such as looking at artifacts and asking for detailed stories, can help get a teen who responds with, "You know...stuff," to open up. Starting off with a group interview can help break down barriers, as well.
The unique cognitive, developmental, and ethical aspects of conducting research with children are worth an entire book. Thankfully, there are plenty of good resources available for responsible researchers, so I won't address this complex topic here.
In either case, it's a good idea for at least one of the interviewers to be comfortable conversing with teens or children in the target age group. If you're not comfortable, it will show, and it will take longer to establish a rapport.
REMOTE INTERVIEWS
Design research often has tight time or budget constraints, so international or even domestic travel may be out of the question. Remote interviews are generally the best compromise in this situation, if you need cultural diversity in your sample or if you're designing a business tool without many users in your area.
If possible, use remote interviews as a supplemental technique rather than as the bulk of your research. Remote research, even with the best videoconferencing tools, is missing the nuance and detail you can get from in-person discussion and observation. For this reason, start with as much local research as you can manage, then use remote research primarily as a way to see if there are any significant differences. If what you're hearing sounds very similar, that's good news. If not, it might give you enough evidence to argue for some in-person research.
Videoconferencing can be somewhat helpful for remote interviews, but it's less useful than you might think. Transmissions are often low resolution with low refresh rates, so the nuances of body language and facial expression may be lost. It's also a rare interviewee who has videoconferencing capability in the actual context of use. If you're working on a Web site or an application, a telephone conversation plus a desktop-sharing tool (such as WebEx) may be the best option.
147
Designing for the Digital Age: Creating Human-Centered Products and Services
To get some rich information in a sterile conference-room setting, ask the interviewees ahead of time to bring some artifacts with them.
Often, you'll find you're limited to a simple phone call. Try to prepare interviewees ahead of time by specifying the kinds of tools or documents you may be interested in. If possible, get your interviewees to send photos or copies of examples so you can talk through them in the interview. When someone mentions an interesting artifact that you haven't seen, ask if you can get a copy later.
Remote interviews will also require the best active-listening skills you can muster. It's even more important that you summarize back what you're hearing to confirm that you're interpreting correctly. Also allow for longer pauses than you would in face-to-face conversation, since you don't have body language cues to tell you when someone is finished speaking. Be sure to use a full-duplex conference phone, as well; some ordinary office phones don't transmit signals both ways at the same time, so you may not be aware when you're speaking over the person on the other end.
LITTLE OR NO ACCESS TO THE CONTEXT OF USE
You may be too pressed for time to visit people's homes or offices, or an interview might be too disruptive in an open-plan workspace. Whatever the reason, it's not unusual to have limited or no access to the actual context of use. A few design problems, such as consumer Web sites, lend themselves to out-of-context interviews more than others, though you'll always lose some information by not conducting them in context.
Consider how you can still get some rich information in a sterile conference-room setting. Ask the interviewees ahead of time to bring some artifacts with them, and offer examples of the kinds of things you're looking for. If designing a car maker's Web site, for example, ask people to bring in any magazines or articles that have influenced their thinking, any notes they have, and a list of any Web sites they've been looking at.
Set up a computer with the existing version of the software or Web site; approximate the most common user hardware and software setup. Of course, users may struggle due to different settings or lack of familiar files, so your data won't be entirely accurate; this is particularly problematic with enterprise or productivity software that may be highly configurable.
In the event that a full-length interview is disruptive in a work setting, see if just a five- or ten-minute tour in the work area would be acceptable. At some point during the interview, use this as your opportunity
148
Chapter 7 Understanding Potential Users and Customers
for a condensed version of the "grand tour." Try not to do it at the very end of your time, since what you see might raise useful questions you'll want to discuss back in the conference room. Snap a few digital photos or use a video camera so you can point to workspace artifacts during the remainder of the interview.
PERIPATETIC OR HARD-TO-INTERRUPT ACTIVITIES
Not all activities are conducive to having the interviewer ask to see a demonstration of this or that behavior. If the users are peripatetic—such as nurses who make notes while walking around a medical ward, or golf-course superintendents who look at their greens and want to adjust their watering parameters on the spot—try to follow along and observe this behavior, asking questions about what you're seeing when it's feasible or polite to do so. Plan on a long interview in such settings, if possible, so you can start with an introduction to what you're about to see, then wrap up with a more thorough debrief of what you observed. With very busy users, you may need to work in this discussion over a cup of coffee or during lunch.
There are also some behaviors that would be unwise to interrupt, such as driving a car or doing knee surgery. The interviewee may have some limited ability to comment as she goes about her activity, but can't stop or take detours to answer your questions. An ideal approach in these situations is to videotape the action, then watch it with the interviewee as you ask questions in a more typical interview style.
ACCESS TO SENSITIVE DATA
Interviewees dealing with medical, financial, or other sensitive data may be reluctant to show you actual documents or records. You can often address this concern by signing a nondisclosure agreement, which is best to take care of in advance. If this doesn't do the trick, you may need to
ask the informant to work with a blank record or to create some fake data; neither is optimal. In most cases, it's acceptable for you to look at the real data as long as you don't capture it in any way.
An interviewee might mention a document that sounds particularly useful, but then be uncertain whether he can share it with you. Ask for the name of the document and see if the interviewee would mind you requesting it through his or her manager; most people are relieved to pass such decisions along.
In particularly secretive environments where, for example, a business process is seen as proprietary, it's occasionally useful to make an exception to the "no manager in the room" rule. Otherwise, interviewees may be so uncertain whether they can answer your questions that you get nothing from the interview; if they can look to a manager for permission, you will at least get something, even if you don't get the workarounds. Hopefully, not all the companies you visit during your research will be so reticent.
GROUP INTERVIEWS
Individual interviews are almost always better, though group interviews can be ideal either as a warm-up for individual discussions or when you know almost nothing about a domain. They can also be useful as a follow-up later on, since they offer an opportunity for people to compare and contrast their approaches and processes; after people have participated in individual interviews, they're a bit more self-aware about how they do things.
In rare cases, you may work on a product that's likely to be used by two or more people together, in which case a group interview makes sense. Informational kiosks in a museum or home entertainment systems are good examples of this. It's important to see how users behave together—do they all engage directly, or does one person drive the interaction while others watch?
149
Designing for the Digital Age: Creating Human-Centered Products and Services
You might also encounter group interviews when you don't particularly want them. A colleague who had to recruit interviewees at the local mall lamented that teenage girls always seemed to "travel in packs" and were reluctant to participate in interviews without their friends. If the manager at a customer site schedules things in the easiest way, you might find yourself unexpectedly facing a roomful of users for an hour or two, instead of the two or three users you hoped to see individually. In essence, your interview has just turned into a focus group, which can't accomplish what an individual interview can.
If you must do group interviews, plan for 90 minutes rather than an hour. In most cases, you'll want people in the group to have some key characteristic (such as role or age) in common, so you can compare apples to apples. People are also more likely to speak openly with their peers in the room than if some authority figure is present. Seat the participants so they can see one another.
The biggest challenge with groups is getting everyone's thoughts rather than letting one or two people drive the conversation. One way to minimize this is to ask for individual responses from each participant, then discuss what's been said. This can feel very stilted, though. You can accomplish something similar by asking a question of someone in particular, then asking other members of the group how their own thoughts or behaviors differ.
If the group consists of more than two or three interviewees, it can be difficult to conduct the interview as a team, since group facilitation requires more attention as the group size increases. Consider a more explicit division of labor, with one person focused entirely on taking notes while the other just facilitates.
INTERVIEWS IN THE HOME
When visiting someone's home for research, you may be imposing on their hospitality as well as their time. Depending on the time of day, you might offer to bring food, such as bagels for breakfast or pizza for dinner. This is a good way to break the ice and meet the family. In any case, interviews in this environment feel more like a social call than they do in other settings, so plan to start off with small talk about the interviewee's lovely house, evident hobbies, or adorable children.
The home environment is often more filled with interruptions and distractions than an office setting, whether it's the telephone ringing, the pets grabbing for the snacks, or the kids needing something. Consider whether this is part of what you need to observe in your interview or whether it's likely to present a problem, then let the interviewee know in advance if you need them to plan on not taking phone calls or dealing with the home's other residents.
Also be aware that many people feel compelled to neaten up their homes before someone visits. This is likely to gloss over things you need to see, so it's worth asking people explicitly not to do so (and mentioning that your place has a pile of laundry in the hall and dust bunnies on the stairs).
NO RAPPORT WITH THE INTERVIEWEE
Every now and then, you might see that you're just not developing a good rapport with an interviewee. This could be a matter of personality or style. My female colleagues and I have sometimes seen male interviewees more inclined to converse with our male teammates, even if the female team member is clearly leading the interview; I've encountered this more often outside the U.S. I've also seen female interviewees more inclined to converse with me than with a male colleague. Whatever the reason, if you don't see a rapport developing, try switching interview roles
150
Chapter 7 Understanding Potential Users and Customers
with a teammate. You certainly don't want to give offense by saying, "I'm not connecting with this person, so you try," but you can pull it off if you say something that sounds like you planned it ahead of time, such as, "Great, that's all I had. Steve, I know you had some other questions..." Discuss this sort of signal with your partner ahead of time so he's not taken by surprise.
UPSET INTERVIEWEES
Most design research won't dig into anything more sensitive than collaboration with difficult coworkers, but some topics, such as dealing with medical conditions or personal finances, can be difficult to discuss. It's obviously important to be sensitive to this, but you may still hit a nerve without intending to. If someone becomes very upset, acknowledge his distress: "That seems like it must be very difficult for you." After that, you might sit quietly while the interviewee collects himself or perhaps excuse yourselves for a glass of water to give him a bit of space. Ask if he would prefer to continue the interview or end it.
"BAD" INTERVIEWS
Happily, truly unpleasant interviews are very rare; in hundreds of interviews, I can only think of one or two interviewees who were downright uncooperative or rude. More often, a "bad" interview is the result of someone not fitting the right profile, such as someone whose job doesn't really involve the activities you need to learn about. There's often one person in a set of consumer interviewees who doesn't fit the parameters, but this is more rare in enterprise projects. If you find there are several participants who don't meet your criteria, review your screening questions to see if any of them hint at the answer you're looking for—unfortunately, there are people who will answer screening questions incorrectly because they want to participate in the research or get the honorarium. If the problem isn't with your
questions, then complain to your recruiter; you shouldn't have to pay them for sloppy work.
Of course, there's the problem of what to do with the informant who's sitting there in front of you. Unless you did the screening yourself, you have to assume this person is there with good intent. It might be fine in a consumer study to say, "I'm sorry, it seems like we made an error; you don't quite fit the parameters of our study. Of course we will pay you for your time." However, if this is someone recruited by your sales team or for whom helping out is the incentive, then it would be rude to send her away unheard. Your time is scheduled anyway, so the best approach is often to interview this person even if it's not going to be helpful. You will need to adapt your questions to what the interviewee has to offer. A half hour is usually enough to make someone feel like she's provided valuable information.
Project Management for Interviews
Research with customers and users is a significant investment, so you'll want to make the most of it. This usually means packing a lot of research into a short period. However, it's important to make sure you aren't moving so quickly that you start to miss details.
Between interviews
If possible, spend a few minutes after each session clarifying your notes and debriefing with your teammate(s). If that's not possible, do so at the end of each day. This helps you get the most out of each precious interview.
Discuss what you saw that was interesting, consistent with other interviews, or surprising. This helps solidify the data in your mind. It also shows whether you're interpreting the information the
Designing for the Digital Age: Creating Human-Centered Products and Services
same way as your teammates. Consider whether you have enough depth on particular topics; this affects whether you try to spend more or less time on them in subsequent interviews.
Also bring up any interview techniques or interactions that worked well or not so well. Was there a point when you were stuck and didn't know how to get help from your partner? Did you have follow-up questions but not enough opportunity to ask them? This should become less necessary after you've conducted a number of interviews with someone.
You should be starting to see behavior patterns emerge as you do more interviews. If you find yourself able to predict what an interviewee will say, you probably don't need to continue interviewing. Don't worry if you're not seeing sharp distinctions, though, especially in cases where the boundaries between roles are blurry. Provided you've gotten the necessary information, later analysis will find the patterns where intuition doesn't see them.
Staying sane
It's entirely possible to do 20 or more interviews in a week if they're all in the same region and can be scheduled tightly. However, it's essential in laying out your research plan to allow for travel time, as well as the reality that interviewees won't always be available when you'd like. If your manager or client asks that you interview during the day and hop on a plane for the next city in the evening, point out that interviewing takes a great deal of focus, so it won't be long before this kind of schedule makes you less effective at getting value out of the research. There's not much point in spending money on your time and travel if you're going to be half asleep during the interviews.
If at all possible, plan out your whole interview schedule before you hit the road. It's extremely difficult to manage logistics and focus on interviewing
at the same time, so ask for project-management help from someone not traveling if your schedule isn't finalized by the time you start.
Team roles and responsibilities
If you can afford to have every member of the team do most of the interviews, that's great, though you'll want to avoid having a big crowd overwhelm the participants. If your budget is as constrained as most, send the two flavors of interaction designers to every interview, since they are the team members who most need to understand the behavioral details, then send the project lead, visual designer, and industrial designer (if there is one) on just enough interviews to get a sense of the users and domain. However, the team members doing the interviewing should stay in touch with the rest of the team and share what they're learning, since it gives the other team members a chance to suggest other lines of inquiry as the research progresses.
If two interviewing partners have different levels of skill and experience, it's common for the senior team member to drive most of the interviews while the other is primarily focused on capturing information and asking clarifying questions. However, it's a good idea for both team members to lead at some of the discussions; switching roles can help a team survive a long interview day.
Communicating outside the team
Project owners or stakeholders outside the design team may get a bit nervous during research, since the project's success may depend on how well it goes, and the design team is likely out of sight for several weeks. Be sure to reach out at least every few days to let the project owner know how it's going. Don't feel that you need to synthesize on the go, but do provide general feedback about how things are going and perhaps share an interesting observation or two: "The group manager at site
152
Chapter 7 Understanding Potential Users and Customers
X was exceptionally helpful. We got several excellent interviews there, plus a couple of good ones at site Y. We're getting what we need so far. One technician at site Y showed us something we've never seen before..."
Of course, you should alert your project owner as soon as possible if things aren't going as expected. If you're not getting enough interviews or you're getting the wrong interviews, you need to discuss whether to extend the schedule or work with what you're getting. If you're finding that the research contradicts important assumptions the product team is making, it's best to alert the project owner to this early on, so stakeholders can assess whether you're getting the wrong interviews or whether their assumptions are off base.
Not all unexpected news is bad. The interview team may discover a new role or other unanticipated factor that provides important insight. I remember the first time my teammates and I encountered a case manager in healthcare, while doing research for a comprehensive facility information system that combined financial and clinical data. This new role straddled the clinical and financial worlds, looking at which medical approach to a problem was the least expensive. With the growth of managed care in the United States, it seemed clear to us that this role would become increasingly common, so we called up the client project owner that evening, told him what we'd found and why it seemed important, and asked if we could find any more such people to interview.
Summary
The quality of your interviews will determine whether you're designing on a foundation made of bedrock or one made of sand. A good set of interviews need not anticipate every tiny question you might have during detailed design, but should equip you with a good understanding of goals, major tasks, mental models, and opportunities for design to improve the effectiveness of a business or the quality of someone's life.
Just remember that if you understand how people think and behave, the design will follow. You won't do perfect interviews, especially at first, but if you avoid the worst mistakes—asking users what they want you to design or whether they agree with your preconceived notions—keep things conversational, use your active-listening skills, and refer to a cheat sheet of topics and question types inside the cover of your notebook, you'll probably do just fine.
153