Interviewing Users

How to Uncover Compelling Insights

Steve Portigal

• Publisher: Rosenfeld Media
• Year: 2013
• ISBN:
  9781933820811
• Edition: 1
• Topic: Negocios y empresa
• Subtopic: Investigación de mercados

Interviewing is a foundational user research tool that people assume they already possess. Everyone can ask questions, right? Unfortunately, that's not the case. Interviewing Users provides invaluable interviewing techniques and tools that enable you to conduct informative interviews with anyone. You'll move from simply gathering data to uncovering powerful insights about people.

CHAPTER 1

The Importance of Interviewing in Design

User Insight in the Design Process

When to Use Interviewing

To Interview Well, One Must Study

The Impact of Interviewing

Summary

This is a great time for the design researcher. Within user-experience design, service design, and to a lesser extent, industrial design, user research has gone from being an outsider activity, to being tolerated, to being the norm. Across industry events, conferences, online forums, school curricula, and professional practice, there’s a tacit agreement that designing for the user is the preferred way to think about design. As with any generalization, there are exceptions. Maybe you aren’t feeling the love right now, but you probably can agree that things are much better than they were in the past. To design for users, you must begin with a deep understanding of users. If you don’t already have that understanding, you need to do some
form of user research.

TIP YOU ARE NOT YOUR USER

You may be a user, but be careful of being seduced into designing for yourself. Jared Spool calls that “self design” and identifies the benefits and risks at www.uie.com/brainsparks/2010/07/22/uietips-self-design/. I think he’s too easy on self design. Lots of niche companies make the snowboards, outdoor equipment, and mixing gear that they, as enthusiasts, would want. But some have trouble expanding their offering in an innovative way, because they are so caught up in being the user.

NOTE GAINING INSIGHT VS. PERSUADING THE ORGANIZATION

While doing ethnographic research in Japan, I sat with my clients while they conducted another study. They brought users into a facility and showed them the most elegantly designed forms for printer ink cartridges. They were smooth, teardrop shapes that were shiny and coated with the color of the ink. They also showed users the existing ink cartridges: black rectangles with text-heavy stickers.

Can you guess what the research revealed? Of course. People loved the new designs, exclaiming enthusiastically and caressing them. Regardless of methodology, there was no insight to be gained here. I’ve gone back and forth about whether this was good research or bad research. It didn’t reveal new information, but it provided tangible evidence to persuade someone else in the organization. This team’s approach suggests that there are other issues with their design process, and while their research might have been the best solution in that situation, ideally this isn’t the best use of a research study.

User Insight in the Design Process

Although there isn’t a clear alignment about how much time and effort to invest and what approach to use, at least we, as user researchers, share a common goal: to gather information about users in order to support the organization when creating products, services, and more.

What I’m calling interviewing is also referred to by other names: user research, site visits, contextual research, design research, and ethnography, to name a few. Regardless of nomenclature, these are the key steps in the process:

• Deeply studying people, ideally in their context

• Exploring not only their behaviors but also the meaning behind those behaviors

• Making sense of the data using inference, interpretation, analysis, and synthesis

• Using those insights to point toward a design, service, product, or other solution

We go to visit our users (in their homes, their offices, their cars, their parks, and so on) most of the time, but not always. When planning a project, we ask ourselves if it’s more insightful to bring participants in to see our stuff (say, prototypes we’ve set up in a facility meeting room) than it is for us to go out and see their stuff. Overall, our objective is to learn something profoundly new. There are points in the design process where quickly obtained, if shallow, information is beneficial, but that’s not what we’re focusing on here.

NOTE IS THIS ETHNOGRAPHY?

If you are interviewing users, are you doing ethnography? I don’t know. What I do know is that if you refer to your use of interviewing of people as ethnography, someone will inevitably tell you that no, you aren’t doing ethnography (you are doing contextual inquiry, or site visits, or in-depth interviews, and so on). The term ethnography seems to be particularly contentious for some folks, but...whatever! That’s really their problem, isn’t it? I’d rather we move on from definition wars and focus on what it is I’m getting at when I say interviewing—which means conducting contextual research and analyzing it to reveal a deep understanding of people that informs design and business problems.

Of course, there are varying perspectives on any “best practice.” Everyone from Henry Ford to Sony to 37 Signals has offered up their reasons not to incorporate direct customer input into the development process. The subtext of those claims is that people in those organizations possess an innate talent for building stuff that people love. Yet some companies that publicly make those claims have hired me to interview their users. The insights that come from studying users not only inform design but also inspire it. Across organizations, different design cultures have more or less of an appetite for inspiration or information, although in my experience it’s hard to interview users without taking away a hearty dose of both.

Sometimes, the stated goal of interviewing users is to uncover their pain points (often known as needs). Embedded in this mindset is the mistaken notion that research with users is a sort of scooping activity, where if you take the effort to leave your office and enter some environment where users congregate, you’ll be headed home with a heap of fresh needs. People need an X and Y, so all the designer has to do is include X and Y in their product and all will be good. What? No one really thinks that, do they? Well, take a look at Figure 1.1

Microsoft’s ad campaign for Windows 7 implies an unlikely approach to research, design, and product development. The customer asks for some feature—in this case, for the OS to use less memory. Microsoft, seemingly unaware of the need—or opportunity—to optimize the memory footprint, smacks their corporate forehead as they see the light, sending their engineers scurrying to fulfill this surprising new need.

Without endlessly debating what Microsoft and their ad agency knew and when they knew it, suffice it to say that this advertisement reinforces this semi-mythical scooping model of user research.

FIGURE 1.1
Microsoft’s ad for Windows 7 suggests that their approach to innovation comes from fulfilling user requests.

I’m calling it a semi-mythical model because this is exactly what some teams do. Although it may be better than nothing, the fact is that a lot of important information gets left behind. Insights don’t simply leap out at you. You need to work hard and dig for them, which takes planning and deliberation. Further complicating the scooping model is the fact that what the designers and engineers see as “pain points” aren’t necessarily that painful for people. The term satisficing, coined by Herbert Simon in 1956 (combining satisfy and suffice), refers to people’s tolerance—if not overall embracing—of “good enough” solutions (see Figure 1.2).

Frankly, I discover satisficing in every research project: the unfiled MP3s sitting on the desktop, ill-fitting food container lids, and tangled, too-short cables connecting products are all “good enough” examples of satisficing. In other words, people find the pain of the problem to be less annoying than the effort to solve it. What you observe as a need may actually be something that your customer is perfectly tolerant of. Would they like all their food in tightly sealed containers? Of course. But are they going to make much effort to accomplish that? Probably not.

Beyond simply gathering data, I believe that interviewing customers is tremendous for driving reframes, which are crucial shifts in perspective that flip an initial problem on its head. These new frameworks (which come from rigorous analysis and synthesis of your data) are critical. They can point the way to significant, previously unrealized possibilities for design and innovation. Even if innovation (whatever you consider that to be) isn’t your goal, these frames also help you understand where (and why) your solutions will likely fail and where they will hopefully succeed. To that end, you can (and should!) interview users at different points in the development process. Here are some situations where interviewing can be valuable:

FIGURE 1.2
In my family room, you can see a telephone (with cord askew) stored near the floor on a VHS rack that I also use to store CDs (which don’t fit) and empty CD cases. (Why am I keeping them?) Incidentally, the orange cord goes through the floor to an outdoor sump pump. And why do I even have these nearlyobsolete VHS tapes and CDs?

• As a way to identify new opportunities, before you know what could be designed

• To refine design hypotheses, when you have some ideas about what will be designed

• To redesign and relaunch existing products and services, when you have history in the marketplace

NOTE THE CASE OF THE IPOD PEOPLE

Our company began working with a client after they had completed a quantitative study about where people used iPods. They had a list of top environments (such as Home, Work, In the Car, and so on), and they asked us to uncover the unmet needs that people had in those particular environments. It turned out that the specific within-environment needs people had were just not that big a deal, but what people really struggled with was moving between environments, or moving between contexts: from being alone to being in a social situation, from being stationary to being mobile, and so on. These were the real challenges for people. For example, if you’ve worn one earbud and let the other dangle so you could stay somewhat engaged, you’ve dealt with this particular issue.

So, we excitedly reported to our client that we had found the “real” problem for them to solve. We were met with uncomfortable silence before they told us that they had committed organizational resources to addressing the problem as it currently stood. In our enthusiasm, we had trouble hearing them, and for a few minutes, the conversation was tense.

Finally, we stated definitively that we had learned some specific things about the environments, and we saw a rich and complex opportunity in this new problem. And that was all it took. We deli...