Last fall, my wife and I walked into a San Francisco bar, sat down, and ordered drinks. It was then that a thought occurred to us: Here we were in a major American city during the height of the Major League Baseball playoffs, and we didn't know whether our local team had won or lost. We stared at each other for a moment like deer in headlights until a smile emerged on my face. "Ah, don't worry," I said smugly. "I'll find out what happened."
From my pocket, I pulled my Palm V attached to my latest gadget—an OmniSky wireless modem. I clicked through a screen or two to find the browser, then asked for the site I thought would give me the score. "Connecting to Service..." my screen told me. Seconds ticked away. Then, through the miracle of IP technology, information started to appear. Slowly, the screen revealed the logo of the sports-information site. I scrolled through the list of its offerings. Aha, baseball! I clicked and more seconds ticked by. Scores! That's what I need. Click. Tick tick tick. National League! Tick tick tick. The San Francisco Giants. Tick tick tick. Euphoria! "They won!" I proudly proclaimed. "Jeff Kent hit a three-run homer in the eighth!"
"I know," said my wife, lifting her half-empty Cosmopolitan. "The waitress told me five minutes ago."
Invisible Technology
Some of you who are reading this are thinking that the woman I chose to spend my life with is too pragmatic. Sure, she obtained the information faster. But I harnessed the Internet's power in a social context without the limitations we typically attribute to the task of knowledge gathering with a computer. And while the technology may be new and not as fast as I would have liked, it still proves that we're approaching a paradigm shift in how we consume media and interact with each other.
You're right, of course. All those things are true. But I'm an admitted gadget junkie who constantly needs the cutting edge toys. I'll put up with an experience like the one I just described because I see the value in examining the way technology changes our lives. However, most folks—my wife included—wouldn't have the patience. Nor should they. Technology seldom becomes important until it becomes invisible.
Problems in Context
Problems like this can be baffling. A development team may have slaved away on a new product for months, building what they felt was a great product. The team may have even invested time and resources in usability testing. After all, sitting down with users and watching them try to accomplish tasks with the product can be incredibly valuable. However, usability testing assumes that there's something to test—either a prototype or final version of a product that's on the path to being launched. But how do you know what to build in the first place? Design, ultimately, is problem solving. And the best way to discover which problems need solving is to look for them in context.
Contextual inquiry is an increasingly popular method for discovering this information. Also known as ethnographic research or field studies, the idea is deceptively simple: Build useful products and watch your users as they work. The process itself sounds even easier: Go to where your users are and tag along with them.
An Ethnographic Approach
Hugh Beyer and Karen Holtzblatt coined the term "contextual inquiry" in the early 1990s. At the time, many developers and designers had been using techniques based on the work of anthropologists and ethnographers—observing users and incorporating those observations into future iterations. Beyer and Holtzblatt formalized the technique to fit into the specific constraints of software development and engineering processes. These days, there's a growing segment of user-experience researchers applying the process to Web-site design.
One of Beyer and Holzblatt's more interesting guidelines advocates that a designer act as an apprentice when performing an ethnographic study. A master craftsman isn't a teacher, they suggest, but someone who talks about his work as he does it. An apprentice watches and listens, and is corrected by the master over time. While you may not have months or years to spend with your users, you can learn a lot in a couple of hours.
User Shadowing
You probably have a strong notion of who your users are. They may be your customers if you're developing an e-commerce site. They could be coworkers if the intranet is your responsibility. Whoever they are, you'll need to find a few and ask them if you can shadow them for a few hours one day. Contact them well ahead of time and describe the process you'll take them through. Ask them which days in the near future will be particularly representative of the work they do with your product, and schedule around those. And be sure to mention the incentives, both theoretical and practical. Your subjects are becoming partners in the design process, plus you'll be paying them.
While you're following your users, try to get them to talk about real events, not abstract process or convention. You'll always get better responses out of people when they tell a story of something that happened to them once. Listen for clues in their answers to determine whether they're getting too abstract. Specifically, listen for the present tense. Stories are told in the past: "At the last weekly meeting, I had to walk from desk to desk to remind everyone it was time to start." Abstractions are told in the present: "We have a hard time getting meetings started on time." Solutions to problems are more interesting than a description of the problem. Other phrases leading to abstractions: "Our company usually..." or "In general, we..." When you hear something like that, immediately ask for an example. "Really? When did that last happen?" Better yet, be there when it does happen. One way to stimulate this type of conversation is to page back through the user's calendar. Look at what he or she has recorded, and ask specific questions about the events on a particular day. This can often shake loose incredibly valuable detailed descriptions.
Learning from the Masters
Remember that you're a student. You're there to learn. It's easy to fall into traps and step out of your apprenticeship role. This isn't a job interview, and you're not there to simply ask questions and get answers. People aren't used to talking about their work in a formal context. Asking them, "How do you file a report?" yields much different answers than simply watching them file a report while occasionally asking, "Why are you doing that?"
Users may also start to think of you as an expert. Often, users perceive the designer as someone who can solve immediate problems. They'll ask, "Hey, do you know why I can't get this to print in landscape mode?" You need to get them back to why they are printing, and suggest that maybe you can solve some of those problems after the session. You aren't there to help them with their current process; you're there to build a better tool with them.
Finally, try not to get caught up in casual or personal conversation until after the session. Following someone around for a few hours while he or she does his or her job is an intimate experience. People are social, and it's not uncommon for relationships to form. That's fine, but keep to the tasks at hand. You can look at pictures of their kids later.
Time Investment
So how many of these apprenticeships will you need to do? I'm afraid the answer is as many as you possibly can. Experts in this particular methodology suggest talking to at least 15 to 20 people, preferably at five or more different sites. With that much data, you'll gain both depth of detail and breadth of experience. Each session should be at least two hours long—it takes time to build trust and get past superficial talk into the meat of a problem.
Also, try to avoid having more than two of these sessions a day, and organize your notes as soon as you can afterward. You might, for example, visit a site in the morning and spend a couple of hours with two subjects. You could then spend the afternoon writing up your impressions.
Now reality sets in—what I've just described would probably take a single designer close to a month. How often have you been in a situation where you could spend four weeks researching what to do before even starting a prototype?
I know, I never have that much time either, but even a couple of sessions will get you in the right frame of mind. If there are more than one of you, do the sessions in parallel. Compare notes and try to paint a realistic picture of your users.
Ultimately, you want your design team to talk about the things you hear from your users, rather than what team members think the users want. It's a significant difference. I'd suggest banning phrases like, "Don't you think users will..." from your working sessions. Much more valuable are phrases like, "Well, when I was following Susan around, she would often..."
Guerrilla Research
Practicing these techniques can be difficult, but some researchers are finding that they add value to the development process. At the user-experience architecture firm Hanna Hodge, Chief Experience Officer Marc Rettig describes the process of guerrilla research, which his firm uses for early explorations that help it focus for later formal research planning.
When looking for potential applications in wireless e-commerce, Rettig and his team set off to the mall to observe what people do when they shop. "We are using ethnographic methods to help us think about how emerging technologies might fit into people's everyday lives," Rettig explains. "It is common practice for product conception to start with the technologies themselves, but most of the products look like previous categories of products made smaller, complete guesses about what people might want, or because we can' products—Web sites on your phone. There are whole product categories waiting to be invented."
Rather than chase these technologies, Rettig carefully observes the social implications of the shopping experience, and then determines where technology can help. By eavesdropping on groups of shoppers, snapping discrete photographs, or occasionally introducing himself and asking a few questions, he was able to build a clear model of how people interact in a commercial environment.
"It's amazing when you get at the web of relationships, influences, and communications that weave through people's days," adds Rettig. "The challenge is to translate the research into design implications and market opportunities."
User Empathy
Clearly, understanding the context of a user experience is critical for mobile applications. A design team can't hope to succeed without a deep understanding of how people interact with their work, their technology, and each other. Think of this notion of user empathy as the first step in a user-centered development process. Embellish the process with surveys, iteration, and usability testing. But whatever you do, get up from your desk and start stalking.
Jeffrey is a founding partner of Adaptive Path, a user-experience consulting group in San Francisco, CA. He is the author of the best-selling Art & Science of Web Design. You can reach him at [email protected].
