3
Principles of Contextual Inquiry
Abstract
Contextual Inquiry is the core field research process of Contextual Design. In this chapter we describe Contextual Inquiry: the four principles of Context, Partnership, Interpretation, and Focus; how the Cool Concepts affect the interview situation; how to structure the interview itself; and how to tailor the interview to different kinds of projects. These field visits immerse the designers in the users' world so their designs can respond to users' real issues.
Keywords
Business analysis; Contextual Inquiry; Cool Concepts; Design; Design thinking; Ethnography; Field research; Human-computer interaction (HCI); Human-machine interaction; Marketing; Mobile design; Product design; Requirements elicitation; Requirements gathering; System design; Tacit needs; Usability; User-centered design; User experience; User research; UX
The core premise of Contextual Inquiry is very simple: go to the user, watch them do the activities you care about, and talk with them about what they’re doing right then. Do that, and you can’t help but gain a better understanding of your user than ever (Fig. 3.1).
That is the basic idea, but we find people are generally happy to have a little more guidance. What should you do at the user’s site? What should you pay attention to? How do you run the interview? Unless you’re trained as a social scientist or anthropologist, running a field interview can be daunting. Contextual Design is structured so that product managers, engineers, user researchers, business analysts, and UX designers1—anyone on the product team—can be part of collecting user data.
The process used to conduct a field interview stood the test of time for 20 years, and the basic principles have not changed. But in this book, we expand the focus and scope of data collected to understand the users’ wider life and core human motives. We’ll introduce the interviewing process and explore the expanded focus in this chapter.
Figure 3.1 Contextual interviews in different life contexts: work, home, and car. Interviews are conducted wherever the activities of interest take place.
In Contextual Design, we always try to build on natural human ways of interacting. It is difficult and unnatural to act out of a long list of rules; instead we suggest a simple, familiar model of relationship. A list of rules says “do all these things”—you have to concentrate so much on following the rules you can’t relate to the person being interviewed. A relationship model says “be like this”—if you can stay in the appropriate relationship, you will naturally act appropriately.2
Many different models of relationship are available to interviewers. A formal model might be scientist/subject: I am going to study you, so be helpful and answer my questions—it doesn’t really matter whether you understand why I’m asking. A less formal model might be parent/child: I’ll tell you what to do, and you’ll do it because you want my approval (or else you’ll rebel to show your independence). Each of these models brings with it a different set of attitudes and behaviors. A student telling a teacher he is wrong may be deferential or rebellious, but either way, it’s a different situation than the teacher telling the student he’s wrong. Relationship models have two sides, and playing one side tends to pull the other person into playing the other. Find a relationship model that is useful for gathering data, and as long as you play your role, you will pull the user into playing theirs. So what’s a good relationship model for gathering design data?
The master/apprentice model
The relationship we offer as a good model for a field interview is that between a master craftsman and apprentice. Overall, it embodies the attitudes and behaviors that will produce the highest quality data. Just as an apprentice learns through being immersed in the world of the master, interviewers can learn by immersion in the world of the user, discovering what’s important from the people who know best.
The master/apprentice model creates an attitude of inquiry on the researcher’s side and an attitude of disclosure and sharing on the user’s side. So people with no special background in ethnography can rapidly learn to conduct effective interviews.
In this situation, users, as the masters, don’t need to be natural teachers; a master craftsman teaches while doing. This makes imparting knowledge simple. Users can talk about what they are doing as their activity unfolds, and the interviewer can ask a question or discuss the user’s actions in the moment. Users don’t have to develop a slide show to reveal the activities and emotions of their life. All they have to do is do their life, which reveals their motives and feelings. Consider this woman planning a vacation for her family:
“I’m looking for something my husband and kids will both be happy with. Look, my husband would love this—a golf tour of Scotland. But what would we do with the kids? Here’s a cruise—maybe that would work. Lots of kid activities, and my husband has always wanted to do a cruise…Getting it right really matters to me. I want everyone to have a great time!”
Seeing what people do is relatively straightforward. Understanding why they do what they do is harder. Some actions are the result of years of experience and have subtle motivations; other actions are habitual, and there is no longer a good reason for them. Like an apprentice, the best time to unravel the vital from the irrelevant and explain the difference is while in the middle of doing the activity.3
A scientist came to the end of a painstaking series of mechanical calculations manipulating data from an experiment, turned to us, and said, “I guess you’re surprised that I’m doing this.” He was surprised at how inefficient he was, once he thought about it.
Because interviewers are present and immersed in the context of the user’s life, they see the steps of an activity, and they see what matters to the user, including the emotion associated with it. They see the intensity when the user is invested or frustrated, the satisfaction when a product makes life easier to live, the pride of being a better professional, and the relief when technology or life hassles are removed. By being present, the interviewer can sense the user’s emotional energy and start to understand it. This is how a team finds latent needs and delighters—the core opportunities for a product to transform life.
Because they talk about their activity while doing it, it’s easy for users to see details that would otherwise be hard to discover. Every action they take and every object around them helps them talk about what they are doing. So users can describe the details of what they are doing, their motives, and even interesting stories of related things that happened.
Talking about what they are really doing keeps users from speaking in generalizations. And the interviewer watching what is happening can ask about what they see, rather than asking general questions that elicit generalizations.
A doctor said he read journals outside his specialty because they often had information of interest to him. How did he decide what was of interest? “Oh, I just scan the article titles.” That wasn’t very specific. But when asked to do it, he was able to say, “Look, this article is about another use of a drug I prescribe. I’ll read that. And here’s an article about a procedure that uses a device I use a lot. There might be good stuff there…”
Sometimes users cannot describe an activity at all when they are not doing it. Their memory of how to do the task is partially incorporated into the objects they use, so without those objects and the context of the activity, they really don’t know what they do.
A secretary was unable to describe how she made her monthly report. But when asked to create it, she brought up her last report and started filling in the parts—the old report was her reminder of how to produce the next one.
A product team can’t spend weeks with a single user to learn what they do—and they don’t need to. When grounded in the present activity, the user can tell stories about the last time something similar happened. Doing the activity naturally triggers memories of similar events from the recent past.4
A financial manager received a stock alert on his phone while we were talking. This reminded him about the time recently when he had gotten an alert of a PayPal transaction while he was watching a ballgame. But he knew he hadn’t made any transactions—so he called, discovered it was fraudulent, and was able to resolve it immediately.
Together, user and researcher can walk through past events in detail, staying focused on what really happened. These retrospective accounts expand the time frame the field interview can cover.
Interviewers have the opportunity to observe the same set of behaviors across a number of users or across multiple instances by one user. What appears to be an idiosyncratic action when seen once, upon repetition reveals a pattern and suggests a strategy for getting things done—an unarticulated strategy which could be directly supported in a new product design. It is often hard to see these strategies precisely because the user’s actions are everyday and ordinary. But by paying attention to repeating detail, the structure of daily life can be revealed.
An enterprise worker used his smartphone at lunch to check and quickly answer emails, set up some appointments, and look up small bits of information. We learned he also did it at breakfast, and right before leaving work, and again last thing at night—and we saw other users do the same thing. Checking off small tasks and minor chores seemed to occur before getting on to the main activities of the workday or evening.
The design team named this strategy “clearing the decks,” reflecting that people sweep away the little things they need to do to keep life going before entering a period of concentrated activity. Once the strategy was found and named, the team could design for it.
Taken together, the master/apprentice relationship makes the rich detail of everyday life available for observation and discussion. It steers the interviewer and user away from high-level abstract questions. It suggests an attitude of inquiry, attention to detail, and humility. And it recognizes that the user is the only true expert on their own activities. The interviewer acts like an apprentice, watching and probing and letting the users teach them about their lives. This relationship model allows users to shape the interviewer’s understandings of their lives naturally, as they perform the activities of their day. And staying grounded in the real life of the user helps the interviewer let go of preconceived ideas that don’t map to reality. Adopting the master/apprentice relationship model is the best starting point for an interviewer—if it is tuned as follows.
The four principles of Contextual Inquiry
Apprenticeship is a good starting point, but it is only a starting point. Unlike apprentices, interviewers are not learning about the user’s activities in order to do them, of course—they are immersing themselves in the user’s world to transform it with technology. But apprenticeship is a good model for how to act when interviewing in the field. The attitude of inquiry and humility natural to apprenticeship when combined with the principles of Contextual Inquiry will allow you to collect high-quality data for your project.
In a Contextual Design project, a cross-functional team carries out the work. Individuals conduct one-on-one field interviews lasting 1½–2 hours with users wherever they live and work, focusing on the aspects of the practice that matter for the project scope. Four principles guide the Contextual Interview: context, partnership, interpretation, and focus. Each principle defines an aspect of the interaction. Together, they allow the basic apprenticeship model to be molded to the particular needs of a design problem. We will describe each principle and how to use it in turn.
Context
The principle of context says to go wherever the user is and see what they do as they do it.5 This is the first and most basic requirement of Contextual Inquiry. All the richness of real life is there with the user, available to jog the user’s memory and for study and inquiry. The user makes a phone call in the middle of doing a task: Was she calling on an informal network of experts to get help in a task? Was she making a break from a heads-down stretch of work? Someone stops by to get a signature on a form. What is the user’s role in this approval process?
So get as close to the activity as possible. The ideal situation is to be physically present while the activity unfolds. Then interviewers can see how the target activities fit into the context of daily life. They will see how an activity fits into time and place, what platforms, products, or devices are used, how people collaborate or coordinate to get things done, and how policy or organizational structure affects what people are doing. And interviewers see the core motives driving the experience—the meaning of the activity within the person’s life, revealed verbally and nonverbally. But getting this rich data requires real, concrete instances of the activity as it plays out in people’s lives.
Gathering field data in context results in this real-life, detailed data—if interviewers are mindful of three key distinctions. Our goal is to gather ongoing experience instead of summary data; concrete data rather than abstract data; and experienced motives rather than reports. We’ll describe each of these distinctions in turn.
Summary data versus ongoing experience
People are taught from an early age to summarize. If you ask a friend about a movie she saw last week, she does not recount the entire plot. She gives overall impressions, one or two highlights, and the thing that most impressed or disgusted her. (Never ask a seven-year-old that question—they haven’t yet learned to summarize and will tell you the entire plot of the movie in excruciating detail.) Ask people to tell you about their experience with a new product, and they will behave just the same way. They give their overall impressions and mention one or two things that were especially good or bad. After the fact, they have a hard time saying exactly why the good things were important, or why the bad things got in the way.
But if you’re there to see the activity happen, you’ll see all this detail and be able to talk to the user about what is really happening. Reality is never summarized.
Abstract versus concrete data
Humans love to abstract. It’s much easier to lump a dozen similar events together than to get all the details of one specific instance really right. Because an abstraction groups similar events, it glosses over all the detail which makes an event unique. And since a product is built for many users, a product team already needs to abstract across all the users’ experiences. If the product team starts from abstractions and then abstracts again to go across all users, there is little chance the resulting product will actually be useful to real people. So interviewers need to be aware of the signals that indicate the user is abstracting and should be brought back to the real instances of life.
If the user is leaning back and looking at the ceiling, he is almost always talking in the abstract. This is the position of someone who will not allow the reality all around him to disrupt the concept he is building in his brain. Someone talking about real experience leans forward, either working on or pointing to some representation of what he is talking about. Words indicating the user is generalizing are another signal. If the user says “generally,” “we usually,” “in our company,” she is presenting an abstraction. Any statement in the present tense is usually an abstraction. “In our group we do…” introduces an abstraction; “that time we did…” introduces real experience. Instances described in detail from the near past are real—instances imagined about the future are not.
If the user starts to get lost in abstractions, just pull him back to real activity. “When was the last time you did that? Can you show me?” Every time you do this, you reinforce that concrete data matters, and you make it easier to get concrete data next time. If the user says, “I usually start the day by checking messages,” ask, “What are you doing this morning? Can you start?”
If you can’t be present while the user engages in the target activity, you have two other options for getting to concrete data. One is artifacts—the things the user creates and uses in doing the activity. If the user says, “We usually get reports by email,” for example, ask, “Do you have one? May I see it?”
Your other option is a retrospective account. This recovers the full story of something that happened in the recent past. Retelling a past event is hard because so much of the context has been lost. People automatically summarize, omitting necessary detail. Most people will start telling a story in the middle, skipping over what went before. They will skip whole steps as they tell the story. The interviewer’s job is to listen for what the user is leaving out and to ask questions which fill in the holes. Inquiry that focuses the user on their step-by-step action in order shows the user the level of detail we want. Going in order helps the user remember.
A car owner (U) talks to the interviewer (I) about how he handled a road trip to another city:
U: I got in the car in the morning, and used the GPS to get me to my first appointment.
I: You entered in the address?
U: That’s right.
I: Where did you get the address? Did you have it on your phone?
U: Yes, but I actually entered the address the night before.
I: The night before?
U: Right. Before I go on a trip, I enter all the places I’ll go as destinations.
I: You mean you saved them as favorites?
U: No, I just entered them like I was going to go there, then I canceled. That’s what I did the night before. Then, the day I left, they were all right there, easy to pick. [He shows the recent destinations list].
I: So you never have to delete them.
U: Right—they just disappear off the bottom of the list. I may never go to these places again, so If I entered them as favorites I’d have to delete them later.
I: Okay. So the night before, where did you get the address from?
U: My first address was a client we do business with all the time, so I got it from the contacts on my phone.
I: Can I see?
At each point, the interviewer listens for steps that she thinks might have happened but the user skipped and then backs the user up to find out. In this process, the user walks through the steps in his mind, using available artifacts to stimulate memory. He recalls more, and is more accurate, than he would be if allowed to simply tell the story without interruptions or discussion. Using retrospective accounts, the interviewer can recover past events and can also learn more about events in progress.
If the end of a story hasn’t happened yet, the most reliable way to learn about that part of the activity is to pick up the retrospective account at that point in a previous occurrence which did complete. Asking “What would you do next?” forces the user to make something up; going to a past instance allows the user to stay concrete.
Retrospective accounts can be used to gather data on activities that happen over a longer stretch of time or to collect data on multiple instances of the same activity. These grounded, case-based retrospectives bring a richer view of how a target task may play out in a person’s life.
Experienced motives versus reports
Because researchers are with users in their real-life contexts, they can sense the user’s feelings and emotional energy when talking about or doing the activities of their lives. If asked “How do you feel about this (product, activity, or event),” when out of context, users are prone to treat it like a report. They just tell what they thought they felt without any of the visceral response that is coupled with actions and thoughts when actually in situ. This emotional background is just as much concrete data as the user’s specific actions, and it is important for collecting data relevant to the Cool Concepts. When people are experiencing something that matters to them because it’s related to their identity, their words are accompanied by palpable pride or distain, for example. Data on sensation is present in the sensual delight they visibly experience. When Identity and Sensation
He pointed out the vertical LEDs on the headlights of his new Cadillac: “They look really sharp. Other high-end cars have LEDs on their headlights, but they just look stupid.” Reacting to the emotional charge in his voice, the interviewer said, “So the lights really matter to you—you seem sensitive to style.” “Oh yes,” said the user. “I care about the things I have around me and how I show up. I could never have something that looked so terrible as those other lights! I bought this car for the lights.”
When you want to find the cool elements of a product, what truly matters to the user is strongly connected to the user’s sense of self—so it is apparent in deeply felt emotions. Interviewers have to be present in the moment the user is having these strong feelings to uncover them. Then we can probe to understand what is driving the feeling or to find a core motive. But if interviewers only collect reports, another kind of summary, we will miss what really matters.
The principle of context is the key to getting good data: Go where the target activity is happening, observe it, sense the user’s feelings, and talk about it, all while it happens. Keep the user grounded in concrete actions both by doing activities and by walking specific recent incidents in the past—step by step. Probe emotional energy and find its origin and motivations. Don’t allow the user to summarize, abstract, or report on their world; it removes too much of the real, important data. In this way, interviewers will have access to the data they need to design for life.
Partnership
The principle of partnership creates a collaboration between user and interviewer to understand the user’s life. The only person who really knows everything about his or her life is the one living it, so Contextual Inquiry creates a context in which the user and the interviewer can explore the user’s activities together, both influencing the direction of the exploration.
In an interview with a designer using page-layout software, the user was positioning text on the page, entering the text and moving it around. Then he created a box around a line of text, moved it down until the top of the box butted the bottom of the line of text, and moved another line of text up until it butted the bottom of the box. Then he deleted the box. Here is how we probed for insight:
Interviewer: “Could I see that again?”
User: “What?”
I: “What you just did with the box.”
U: “Oh, I’m just using it to position this text here. The box doesn’t matter.”
I: “But why are you using a box?”
U: “See, I want the white space to be exactly the same height as the lower-case letters in this line of text. So I draw the box to get the height.” (He repeats the actions to illustrate, going more slowly.) “Then I drag it down, and it shows where the next line of text should go.”
I: “Why do you want to get the spacing exact?”
U: “It’s to make the appearance of the page more even. You want all the lines to have some regular relationship the other things on the page. It’s always hard to know if it really makes any difference—you just hope the overall appearance will be cleaner if you get things like this right.”
I: “It’s like everything you put on the page defines a whole grid of appropriate places for the other things to go.”
U: “That’s right. Everything affects everything else—you can’t reposition just one thing.”
We collected this data back in the 1990s, and this user was revealing a strategy for laying out a page which the actual page-layout tools wouldn’t support directly for another 10 years. Now, the tools have features to help with this kind of positioning—but you’ll still see users measuring distances on the screen. What are the tools missing?
Withdrawal and return
The example above illustrates the pattern of interaction in a Contextual Inquiry. The user is engrossed in their activity; the interviewer is busy watching the detail, looking for pattern and structure, and thinking about the reasons behind the user’s actions. At some point the interviewer sees something that doesn’t fit or figures out the structure underlying an aspect of the activity and interrupts to talk about it. This causes a break in the action, and both user and interviewer withdraw from the activity to discuss what the interviewer saw. This break to reflect creates a separate space in time to think about the practice—right when it just happened. Users, interrupted in the moment of taking an action, can say what they are doing and why. The interviewer, looking from the outside, can point out behavior users might not notice or take for granted.
When the conversation is over, the interviewer directs the user to return to the ongoing activity, and the interviewer returns to watching. This withdrawal and return is a basic pattern of Contextual Inquiry: periods of watching activities unfold interspersed with discussions of the events that just happened.
By paying attention to the details and pattern of the activity, the interviewer teaches the user to attend to detail and pattern also. Over the course of an interview, users become sensitized to their own actions. Questions reveal the structure of their own activity, and they start thinking about it themselves. Sometimes users then start interrupting themselves to reveal aspects of their activities that might otherwise have been missed by the interviewer. Because of the withdrawal and return over the course of the interview, a true partnership develops to inquire into the activities of the user’s life.
Because interviewers are also product designers, they will naturally generate design ideas just by being immersed in the user’s world. The user is in the middle of doing the very activity the new idea is intended to support—there is no better time to get feedback on whether the idea works. If it does, the interviewer now both understands the needs of the activity and has a potential solution. If not, he finds out he did not really understand the issue after all. Sharing designers’ first, unformed ideas with the user allows them to alter the team’s initial thinking, opening the possibility of radical changes in product purpose and structure. In addition, the design idea suggests to the user what technology can do. Users can start to see how technology might be applied to their problem—and they may start inventing too. But watch out—a Contextual Inquiry should be an inquiry into the user’s life. Return quickly to the activities important to the project focus, or you’ll find yourself only discussing possible designs out of context.
Avoiding other relationship models
Adopting the attitudes and behaviors of the master/apprentice relationship model ensures the best data. But sometimes, interviewers fall back into more familiar models of relationship that get in the way. Here are some common pitfalls:
Interviewer/Interviewee: The interviewer and user start to act as though there were a questionnaire to be filled out. You ask a question which the user answers and then falls silent. You, anxious that the interview go well, ask another question, which the user answers and then falls silent again. This continues. The questions are no longer related to ongoing activities, because real activity has ceased. The best fix is to return to the action by asking the user to take their next step, which effectively cuts short this question/answer interaction.
Expert/Novice: Like it or not, you start with the aura of the expert. You are the one designing the product, with all the technical knowledge. You have to work to get the user to treat you as an apprentice. So set the user’s expectations correctly at the beginning of the interview. Explain that you are there to hear about and see their activities, because only they know their own practice. You aren’t there to help them with problems or answer questions.
Then, if the user asks for help (or should you forget and volunteer help) step out of the expert role explicitly: “I’ll never understand the problems with our product if I spend the whole time helping you. Why don’t you go ahead and do what you would do if I weren’t here, and at the end I’ll answer any questions that remain.” But if the user is so stuck that he cannot continue doing the activity you came to see, give them a hint to move them along.
Guest/Host: Because it is the user’s workplace and the user is a stranger, it is easy to act like a guest. A guest is polite and not too nosy. A host is considerate and tries to make the guest comfortable by seeing to his needs. You’ll know this has happened because you find yourself feeling like a guest. Respond by moving quickly past the formal relationship to the role of partner in inquiry. This is where sensitivity to culture matters—if, as in some cultures, the user won’t be comfortable until you’ve had a cup of coffee, then have it and move to observing their real life quickly, or you’ll be wasting all your interview time.
Being nosy is part of a good interview. A good field interview feels like the kind of intimacy people strike up on airplanes, where seatmates may tell each other very personal things. The user has already agreed to help by doing a field interview, so let them help. Move closer; look at what they are looking at; ask questions; be nosy. This way you create a real partnership in inquiry. Soon you’ll have the user saying, “Come over here—you want to see this.”
Partnership transforms the apprenticeship relationship into a mutual relationship of shared inquiry and discovery. It retains the close working relationship from apprenticeship while equalizing the power imbalance between a master and apprentice. It invites the user into co-inquiry. This results in an intimate relationship which allows for inquisitiveness, honesty, and good data.
Interpretation
It is not enough only to observe and bring back observations. Interpretation is the assignment of meaning to the observation—what it implies about the behavior and experience of the user or how it reveals the structure of the activity. The typical language used to describe gathering data for design—data gathering or requirements elicitation—suggest that a researcher can go out in the field and pick up the nuggets of what to build next in the same way that one collects shells on the beach, as if they were just there for the taking. When we go out into the field, we are not just collecting the facts of what the people are doing—we must come back with an accurate interpretation of those facts. We must collect meaning. The principle of interpretation says that good facts are only the starting point; good product design is actually built on the designers’ interpretation of those facts. Here’s an illustration:
The fact: A high-powered managing partner at an accounting firm has a client with a question about depreciation. The partner does some research into the issue using Google and their financial information tool, and then hands it off to a staff member to handle.
Why did she do some research herself before handing it off? Here are some interpretations of what that fact might mean.
1. She doesn’t trust her staff. She wanted to get the right answer herself first, then lets her staff do the full research and write-up.
2. She plans to do the work herself, but finds it’s more complicated than she expected and so she hands it off when it starts to become more than she wants to do.
3. She’s curious; she wants to understand the issue rather than just passing the work off to her staff.
If (1) is correct, we might want better ways to do quality checks on staff work; (2) suggests building an easy way to package work in progress and hand it off to someone else; (3) suggests ways to get quick answers and do quick exploration without heavyweight tools for documentation and referencing sources.
Which of these designs is best? It depends on which interpretation is correct—the fact alone does not allow a designer to choose. (In fact, from discussion with the user, (3) turned out to be the right answer). But taking design action means choosing which interpretation to lay on the fact. It’s the interpretation which drives the design decision.
Interpretation is the chain of reasoning that turns a fact into an action relevant to the designer’s purpose. From the fact, the observable event, the designer makes a hypothesis, an initial interpretation about what the fact means or the intent behind the fact. This hypothesis has an implication for the design, which can be realized as a particular design idea. This entire chain of reasoning happens implicitly any time anyone suggests a design idea. Usually it happens so fast, only the final idea is made explicit. But the whole chain must be valid for the design idea to be put in the product.
Design is built upon interpretation of facts—which may be observed behavior or observed emotion. For any fact, the interpretation must be right. Validation of the interpretation happens when you share it with the user.
Share your interpretations
If the data that matters is your interpretation, you must make sure the interpretation is correct, and you can only do that by sharing it with the user. So share your hypotheses about the motives underlying the user’s behavior, their apparent feelings, and any strategies you observe. Share what you think they are trying to accomplish and how you think they go about accomplishing it. Let them tune your understanding in the moment, when they can remember what they were just experiencing. Sharing your interpretations and asking users to tune those interpretations will get you very reliable data. In fact, it’s the only way to get reliable data; if you don’t check with the user immediately, you’ll take away an understanding which is at least partially made up.
When exploring emotional energy and motives, the same process holds: sense the emotional energy; make a hypothesis about its origin; and share that hypothesis for the user to validate or provide you with a better explanation. Through this discussion you will understand the user’s core motives and feelings about a product or situation. And if you listen for sources of joy, you will come to see the opportunity for building the cool user experience into the product.
Also share design ideas as you think of them, as we discussed in the section on Partnership. Sharing design ideas ensures that you come home with a well-founded understanding of the user’s life by walking the chain of reasoning backwards—if the idea doesn’t fit, some link in your reasoning was wrong. Probe and discuss why your idea doesn’t work so as to discover what you misunderstood about their activity.
When it’s the user coming to you with design ideas in the form of wish lists, treat them the same way—probe to find out the situation which gave rise to the wish. Understanding the underlying work and life context gives a design team much more flexibility to respond to the real problem instead of trying to implement hundreds of user requests. Often, a single solution will be able to deal with many apparently different requests, once you understand the motive behind them.
But won’t sharing your interpretation bias the data? Can you really check an interpretation just by sharing it with the user? Won’t users be prone to agree with whatever you say? No—in fact, it is quite hard to get people who are in the middle of living their lives to agree with a wrong interpretation. It’s not at all hypothetical for them, because they are in the midst of the activity. This is an experience they are having now. The statement that doesn’t fit is like an itch; they feel that the description doesn’t fit their inner experience and so they rephrase it:
“It’s like a traveling office,” we said, looking at how a salesman has set up his car. “Well—like a traveling desk,” he responded.
The difference between the two is small but real, and people will be uncomfortable until they get a characterization that fits exactly. We have had people run down the hallway after us as we were leaving to ensure that we had some minor point exactly right.
Finally, since users are not generally experts in seeing the structure of their own life, the interpretation you suggest shows them what to pay attention to. Open-ended questions give the user less guidance in thinking about their activity than an interpretation and result in less insight.
Because users respond to the interpretation in the moment, they can fine-tune it quite precisely. Users commonly make slight changes in emphasis such as those above to make the interpretation exact. They can do this because they are given a starting point which they can compare with the experience they are actually having and adjust it, rather than having to start from scratch.
“So you’re acting like a master coder,” we said to a development project manager. “Yeah,” he said. “Except I wasn’t looking at code. More like master QA.”
Listen for the “no”
An interviewer’s assumptions can easily be wrong, their interpretations may be wrong—and so their goal must be to correct their understanding if they are to design something that responds to the real lives of users. Interviewers need to be committed to hearing what the user is really saying. The users may mean “no” but to be polite may not say “no” directly. Here are some indirect ways users say “no”:
“Huh?”—This means the interpretation was so far off that it had no apparent connection to what the user thought was going on.
“Umm...could be.”—This means “no.” If the interpretation is close, the user will usually respond immediately. A pause for thought means that they are trying to make it fit their experience and cannot.
“Yes, but...”, or “Yes, and...”—Listen carefully to what follows the “but” or “and.” If it is a new thought, this is the right interpretation and yours was wrong. If it builds on yours, this is a confirmation with a twist adding information.
Users say “yes” by twinkling their eyes at you as they realize your words match their experience—or by saying “yes” flatly, as if the whole point was obvious. They will nearly always elaborate on what you said, even if all they do is put it in their own words.
All this means that, in a Contextual Inquiry, the interviewer needs to talk. They need to vocalize their interpretations, their design ideas, and their understanding of what the user is up to and feels. This may be uncomfortable to those trained in other data gathering methods, but it is necessary to be sure you have a credible interpretation.
Focus
The project focus tells designers what to pay attention to—of all the overwhelming detail available, what matters for the design problem at hand. Before starting a project, the team defines the problem to be solved, the users who are affected, the users’ activities and tasks that matter, and the situations and locations that are relevant. This project focus extends and refines the core focus on work and life practice given by Contextual Design and the Cool Concepts. It guides how the user interviews are set up and what the designers pay attention to during the interview.
The interview focus defines the point of view interviewers take during the interview. What should they pay attention to? Which aspects of the activity or its surrounding context matter and which don’t? Without a list of questions, how can the interviewer steer the conversation at all? An apprentice learns whatever the master knows—the master decides what’s important. But the interviewer needs data relevant to the project. The principle of focus gives the interviewer a way to keep the conversation on topics that are useful without taking control away from the user entirely. Focus steers the interview the same way that friends steer conversations with each other. The topics the friends care about—the topics in their focus—are what they spend time on. Anything one friend raises that the other doesn’t care about is allowed to drop naturally. Similarly, an interviewer shares the project focus and then pays special attention to things related to that focus. The user picks up on this and the user and interviewer end up costeering the conversation naturally.
Taking a focus is unavoidable—everyone has an entering focus, a whole life history defining what they notice and what they don’t. Their focus is formed by their personal and professional interests, by their initial understanding of what matters for the project, and what they think is true for the domain. Consider three interviewers talking to a homeowner about her TV and entertainment systems:
One interviewer just bought a home theater setup and sees how the user has laid out her family room for watching TV and listening to music.
Another interviewer is familiar with audio technology and notices the brands of speakers and amp and how she’s gone about connecting them.
The third interviewer is deep into mobile technology and notices how the user has workarounds for listening to music in different parts of the house and outside.
Each interviewer sees a different aspect of the entertainment systems, all of which are “true” in that they are all real. But each interviewer’s different focus reveals different details. The third interviewer sees the larger context of entertainment in the home—but does he notice the connectivity issues? A focus gives the interviewer a framework for making sense of the user’s life. Having multiple people with different job roles and experiences naturally builds in multiple entering focuses. Together, the team will see more than any one person could see alone.
Setting project focus
To move the team forward in a shared inquiry, the team needs a shared understanding of what the project is about—a shared initial focus. The project focus guides how the user interviews are set up and what the designers pay attention to during the interview.
A project focus is defined explicitly. It tells the team what to pay attention to—of all the overwhelming detail available, what matters for the design problem at hand. Before starting a project, the team defines the problem to be solved, the users who are affected, the relevant activities and tasks, and the relevant situations and locations.
The project focus defines what a team needs to find out to design a particular product, solve a particular problem, understand a market from a particular point of view or redesign a service or process which includes technology. A project focus is not the same as project goal: “Port our product to our new platform,” “Create a mobile app for our product,” or “Define the next feature set.” These may be the organizational statement of the project mission, but they don’t say how to get the right data. The team needs to identify the behavior and experience that they must understand to accomplish that corporate mandate. The project focus clarifies what the project is about from the point of view of user behavior within the context of the corporate mission. A clear, articulated project scope and focus ensures that all interviewers are probing into the experience and activities relevant to the project. We talk more about project scope and focus in Chapter 19.
This project focus is extended and refined by the focus on work and life practice given by Contextual Design and the Cool Concepts. The Contextual Design models (described in the next section) broaden the team’s focus beyond design for single tasks by revealing issues around design for life. To design for the Cool Concepts, it’s not enough to focus on the steps of a task, the usability or problems of the current product, or current customer complaints. Accordingly, we will define Experience Models that express the issues of the Cool Concepts within the Wheel of Joy in Life. These models push the team to see the whole of how the target activity fits into life—both the structure of the life and users’ core motives. They broaden the team’s viewpoint and expand the data the team collects.
Experience Models are new to Contextual Design V2.0. The original Contextual Design models were structural models, focused on the details of task and practice—and those details still matter. They address the Cool Concepts in the Triangle of Joy in Use (Direct, Hassle, and the Learning Delta), and push the team to look at the low level detail of interaction and reaction to the tool itself. They do not help to reveal the concepts of the Wheel of Joy in Life.
So the project focus augmented by the Cool Concept focus becomes the initial lens that guides the interview. Depending on the project goals and the nature of the activity to be studied, the team picks a set of Contextual Design models appropriate to their problem. These models, both Experience Models and the older structural models, will then be the lens through which more specific data is collected.
But each interviewer also brings their personal focus—their beliefs about the target activity and users and their professional way of looking at things—both of which are likely to be unconscious. The actual interview focus taken by any team member will be an amalgamation of all these different focuses. Their job is then to let the participant and the facts of the interview to shape the focus so it reflects what really matters for the project.
Focus reveals and conceals
If focus reveals detail within the area it covers, it tends to conceal other aspects of the user’s world. Someone who notices physical room layout cannot help but notice when the home entertainment system has dictated the layout; someone who never thought about interior design cannot help but overlook it until his attention is drawn to it. Meanwhile, the first interviewer is ignoring how the family room is not the whole entertainment story—which may be equally important to the design problem. The first interviewer’s focus has revealed rich detail in room layout; but how can he expand his focus and learn about the other aspects of life practice?
In Contextual Design, we seek to deliberately expand focus and break our entering assumptions. To expand focus during the interview, Contextual Design defines intrapersonal triggers, cues that help the interviewer recognize where their entering focus does not fit the reality of the user’s life so they can probe to broaden their understanding. This encourages interviewers to deliberately create a paradigm shift rather than simply confirming their existing expectations. Intrapersonal triggers are flags alerting the interviewer when an opportunity for breaking a paradigm and expanding the entering focus exists. They work because your own feelings tell you what is happening in the interview and how to act to fix it.
Surprises and contradictions: The user says or does something that you know is “wrong.” It’s something, you think, no one else would do, something totally idiosyncratic. Or else it’s just random—they had no particular reason for doing it. Any one of these reactions is a danger signal. It means that you are—right now—allowing your preexisting assumptions to override what the user is telling or showing you. The tendency is to let it pass as irrelevant; the solution is to do the opposite. Take the attitude that nothing any person does is done for no reason—if you think it’s for no reason (even if they tell you it’s for no reason), you don’t yet understand the point of view from which it makes sense. Take the attitude that nothing any person does is unique to them—it always represents an important class of users whose needs will not be met if you don’t figure out what’s going on. Act like the apprentice, who always assumes a seemingly pointless action might hide a key secret of the trade. Probe the thing that is unexpected and see what you find.
Nods: The user says something that fits exactly with your assumptions, and you nod. This is the reverse of the first trigger, and it is tricky. What are you doing when you nod? Implicitly you are saying that what you hear in the user’s words matches with your own experience, and so you assume that everything that happened to you and everything that you feel is also true for them. Is this a safe assumption? Instead, take the attitude that everything is new, as if you had never seen it before. The apprentice never assumes the master has no more to teach. Is the participant’s experience really the same? Speak it back to them in an interpretation and find out. Or make their world strange: Why would they do that? What’s motivating them? Look for the paradigm shift—look for ways people are different from what you expect.
What you don’t know: The user says something technical you didn’t understand or is explaining something and you just aren’t getting it. Now what? Are you going to admit your ignorance? Wouldn’t it be easier to research the topic a bit back at the office? No. Admit your ignorance. Make the user go back and describe what they are doing step by step. Remember you are the apprentice—you don’t need to have all the answers. Treat this as a good opportunity to step away from the expert role. You are there to learn—you might as well learn about the activities and technology you don’t understand. No one else will be able to tell you better what is going on with this person than the person themselves. Even if the user doesn’t really understand it either, the extent of their knowledge and misinformation can be valuable for design. Furthermore, if you don’t ask, you’ll get more and more lost as the conversation continues.
Where the emotion is: When you feel emotional energy in the room, positive or negative, this is a signal to pay attention and probe more. The users’ emotional reactions reveal what they truly care about—and so, what they will care about in a product you deliver. Don’t assume that you understand the source of the emotion. Offer your interpretation to prompt a response and discover where it’s actually coming from.
U: “Most reserved blocks are released a week out,” said the nurse. “Except for Dr. Smith’s. His release the day before.” (Her face closed down and she compressed her lips.)
I: “Oh, he has a special deal?”
U: “Yes. He’s special.” (She tried to repress her disapproval.)
I: “So if a doctor is ‘special’ enough, they get their own rules?”
U: “That’s right.”
I: “I bet that makes it harder for you.”
U: “We live with it. It’s our job to make everything work.”
Everyone has a set of assumptions about product value, usage, and what creates joy or coolness; treat these as what they are, entering assumptions. The Cool Concepts provide a structure for seeing emotions, but they also come with their assumptions—albeit widely validated ones. Although they provide a framework for understanding what might be happening in the user’s experience, unless you validate your interpretation, you can’t be sure. So if you see, hear, or feel emotion, probe to clarify the source, and use it to expand your focus.
It’s easy to design a product from your own assumptions and prejudices. Breaking out of your preconceived notions of what the product should be and how it should work is one of your hardest design tasks. Allowing users to break your entering paradigm counterbalances the natural propensity to design from your own assumptions. The principle of Focus makes you aware of your assumptions. Paying attention to triggers to expand that focus reveals opportunities to probe and so widens your focus. This is how to find new delighters and opportunities for a product’s design.
The Contextual Interview structure
The principles of Contextual Inquiry and the Cool Concepts guide the design of the interview. The principles say what needs to happen to get good data, but the design problem and the nature of the activity being studied constrain the exact procedure to use. The most common structure for Contextual Inquiry is a contextual interview: a one-on-one interaction lasting 90 minutes to 2 hours, during which the user does his or her own activities wherever they naturally occur, while the interviewer engages them in discussion of what they are doing and why. During the interview, the interviewer gathers the additional data suggested by the Contextual Design models selected for the project. This structure has been used to study everything from office work to shopping, television use, vehicle driving, mobile device use, construction equipment, clean room chip fabrication, factory floors, medical devices, operating rooms, and real-time collaboration—to name just a few. It’s all you need to collect field data for virtually any project type.
Each interview has its own rhythm, set by the activity and the user. But they all share a structure which helps interviewer and user get through the time without losing track of what they are supposed to do. Every interview has four parts:
Starting: getting an overview
You and the user need to get used to each other as people. Running the first part of the interview as a conventional interaction helps with that. You introduce yourself and your focus, so the user knows from the outset what matters and can participate in the inquiry. You promise confidentiality and get permission for any recording. Explain that the user and their actions are primary and that you depend on them to help you understand what they are doing and to correct your misinterpretations. Ask for opinions about the tools they have (if relevant) and get an overview of the larger context of their life as it pertains to the activity and what is to be done that day. Start the discussion about identity elements and see where it goes.
This is summary data, not concrete data, so don’t pursue any issues in detail—instead, watch to see if they come up in the body of the interview and pursue them then, when they are in context.
Also get an overview of how the activity fits into the times and places of daily life. This may be a convenient time to start walking the day, looking at behaviors relevant to the target activity, including place, time, and platform used. This Day-in-the-Life data will feed the Cool Concept of Accomplishment later. This is just the beginning of collecting this type of data; you are about to make the transition to observing and discussing ongoing experience. But it’s natural to backtrack and ask about the activities that occurred before the interview started.
The traditional interview step should last no more than 15–20 minutes. If you collect Day-in-the-Life data, it may be a bit longer but never extend beyond 30 minutes or you won’t get to the contextual data you need.
The transition
In the transition, lay out the new rules for the Contextual Interview: the user will do his or her activities while you watch; you will interrupt whenever you see something interesting; and they can tell you to hold off if it’s a bad time to be interrupted. Anytime one wants to break social norms, it’s best to define the new rules for social interaction explicitly so everyone knows how to behave appropriately. Here, you want to create the new rules for the Contextual Interview, so you say what they are. This should take all of 30 seconds, but it’s a crucial 30 seconds; if you don’t do it, you run the risk of spending the entire time in a conventional interview.
The Contextual Interview proper
During the overview, you got an idea of the user’s life and work and what is currently on their plate. At this point, suggest that the user start doing one of his or her activities (relevant to the project focus) while you observe and interpret. This is the bulk of the interview. You are the apprentice, observing, asking questions, and suggesting interpretations of behavior. Analyze artifacts and elicit retrospective accounts. Keep the user concrete, getting back to real instances, using artifacts, and drawing on paper when the user draws in the air to describe something she doesn’t have in front of her. Look for emotional energy and probe when you find it. Look for the ways tasks span time and space, and how the user’s devices enable that. Look for connection and for moments of sensation. And take copious notes by hand the whole time—don’t depend on a recording or a second person to catch everything.
Be nosy—after a phone conversation, ask what it was about. If the user goes to the files, look over her shoulder. If a text message comes in, ask about that. If she goes down the hall, tag along. If someone comes to the door and looks diffident about interrupting, tell them to come on in. And, of course, if the user says she needs a break, let her have one. The principles of context, partnership, interpretation, and focus guide your interaction during the interview.
Cool Concepts in the Contextual Interview
The Cool Concepts augment the data to be collected during the interview. Above, we indicated the type of data needed and where in the interview to collect it. In Chapter 7, when we discuss the Experience Models, we will describe how to get data for the Experience Models in detail. Data for the concepts in the Triangle of Design are handled like any data on the use of a product. This data focuses the interviewer on the interaction design of the product and whether it supports a coherent intent with direct, hassle-free function that requires little to no learning.
To get the right data for the Triangle requires continual attention to interaction throughout the interview. The interviewer watches tool interaction closely to identify issues of Direct into Action, Hassle, and the Learning Delta. See the box given above for reference. When observed we pause to discuss the impact of the interaction on the activity and tool experience. Look for examples of what works and what doesn’t; what brings a smile and what irritates. Watch out for that joy in magic and surprise when something works so well. Notice where the user hesitates in confusion or smoothly glides through activity—all of this indicates their response to the tool’s design.
Talk to the user about their reaction to the tool as it impacts the activities defined in the project focus. Take some time to observe them using consumer tools they love to get an idea of what brings them joy even when you are collecting data relevant to a business too.
Seeing the details of the interaction and the emotional response to it is hard—you may have to devote 15–20 minutes of the interview to focus on getting data for these Cool Concepts. You can do this at the end of the interview if it did not come out along the way.
The wrap-up
At the end of the interview, you have a chance to wrap up your understanding of how the target activities play out in the user’s overall life and motivations. Skim back over your notes and summarize what you learned. Don’t repeat verbatim what happened; describe the patterns you saw in the activity you observed, what you thought was important, roles they play in collaboration, and identity elements you discovered. Share the drawing of the Relationship and Collaboration models you drew in your notebook, if you haven’t already. Identify roles the person may play in their organization, describe the overarching strategies they use to get things done, and talk about what worked and what didn’t. Review any Day-in-the-Life notes for emerging patterns. This is the user’s last chance to correct and elaborate on your understanding, and they usually will—allow 15 minutes for the wrap-up.
Tailoring the interview
To get the appropriate data for task-focused activities, interviewers need just to observe people doing the task and discuss what is happening. Retrospective accounts let you find out about activities over a longer time than the 2 hours of the interview. If an activity is done by multiple people as part of a larger process, do interviews with the different people in the process to get a complete picture. Some activities have several stages—for example, first planning a vacation, then traveling to the location, and then doing things while there. In this case, interview people at each stage. And some activities, such as tax preparation, are seasonal—you have to gather the data at the right time. If you are designing a service, look beyond interaction with technology or activities where you plan to introduce technology—instead, look at all the players and the physical context involved in service delivery. To get the best data, make sure you are in the field with the right people at the right time while they are doing the right things.
Some project foci can present challenges that change the way you gather data. Typical software products supporting consumers or businesses can be studied easily with the observe-and-interpret structure outlined above. But other contexts require modifications. Here are some examples:
Travel: Plan interviews with people at each stage of travel: planning, getting to the location, and being at the location. Planning is regular research activity and traditional contextual interviews work well—but remember it’s not just a heads-down, focused activity. It is likely to happen in small moments throughout the day, so use Day-in-the-Life retrospective accounts to see those small events. Plan to be with users at their vacation destination—try to find users who are vacationing where you are located. In addition, use retrospective accounts to gather similar data more easily. Unless there’s a particular reason to go on the voyage itself, retrospective accounts of traveling to a destination are probably good enough.
Driving vehicles: Start at the user’s home and get an overview of the experience of the car while standing next to it. Then get in and drive, talking about the aspect of the car you care about as you go. Plan for both long and short trips; you may need a chaser car to pick the interviewer up after 2 hours into a longer road trip.
Shopping: Start at the user’s home looking at online shopping. Focus on the research or buying they are doing and do retrospective accounts of recent shopping from the last few days. Replay any online interactions to get the detail. Then go to an actual store to pick up an item. Alternatively, start in the store: meet them there to see what they do, their use of mobile information, and any communication. End the interview back at home if that is where they do most of their searching.
Group activities: (such as a meeting, a doctor appointment, surgery, or a teacher’s class): These group events are hard to interrupt without disrupting the activity you came to see. So identify key individuals to shadow. Talk with them one-on-one first, then watch what goes on during the group activity. Write down your observations and interpretations but do not interrupt. Immediately afterward, debrief one-on-one with your user to go over what just happened.
Construction equipment: The problem here is there is often only one seat in the vehicle. For any activity where it is impossible to accompany the user, talk to them before they start their day to introduce the focus and do the traditional interview. Instrument the activity with a camera and capture about 30 minutes of videotape. Then watch the video with the user right after the event and talk about the experience. Do all this in a single 2–3 hour session.
Consumer electronics: When studying consumer electronics such as TV or music, go into the home and watch people use their products in the traditional way. But use of these devices often takes place all over the house, so also do a “room walk.” Go from place to place in the house to talk about the experience within the context of each room and discuss how the experience changes as the family moves around. In each room, observe the family using the target products or replay what they did in the days before—asking them to do it again for you now. The room walk creates the opportunity to discuss the experience as families live their lives throughout the house.
Products for children: Working with children poses a new set of challenges for collecting data and doing design. We asked Allison Druin, an expert in the field, to share her thoughts on this. See the Box below.
The Contextual Interview structure forms the framework for designing any interview situation. Setting project focus so you know what you need to observe and discuss allows you to plan the data collection strategy so it ensures that you get the best data you can to drive your product design forward. There is always a way to get the data you need!
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.