Читать книгу Interviewing Users - Steve Portigal - Страница 12

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 delivered findings about each environment, and then we delved into the harder problem. It turns out that our client was eager to innovate, but they just needed to have their initial brief addressed. It became an important lesson for me: Reframing the problem extends it; it doesn’t replace the original question.