Interviewing Users: How to Uncover Compelling Insights

INTRODUCTION

It’s been a joy to revisit Interviewing Users ten years after writing the first edition. I’ve had ten more years of running interviews with users and ten more years of teaching people to do user research. I’ve made interesting mistakes, observed how other people succeed or struggle, and broadly reflected on my own approaches. My work has expanded into helping organizations build successful user research practices.

Over those ten years, the user research profession has cultivated an entire discipline focused on the operations of user research. The ongoing discussion about who actually does user research has been taken up under the (absolutely totally nonbiased) heading of democratization. We’re talking (more than we used to, at least) about diversity, equity, and inclusion among researchers and research participants. And throughout a years-long global pandemic, a majority of knowledge work has been conducted from our homes.

In this updated version of Interviewing Users, I’ve worked to offer more complete guidance about user research and interviewing users with these changes in mind.

Still, as society, technology, and industry evolve, other challenges for user research will emerge. For example, new environments, like virtual reality (which isn’t actually new but is not yet mainstream) raise questions about how to conduct research about that environment and in that environment. Currently, there’s uncertainty about AI (artificial intelligence) and what it could mean for different bits of the user research process (there’s no shortage of opinions, but I’ll refer you to screenwriter William Goldman who wrote Nobody Knows Anything). And of course, we can assume that people doing research will continue to be under pressure to move quickly, even though the greatest value comes from investing time and engaging collaboratively with each other. We must choose wisely when and how to resist the demands for so-called efficiency, so we can make sure we’re getting to the good stuff.

Interviewing users is necessarily challenging, and I wrote this second edition to help us do our best work in the face of current and future challenges. I passionately believe that this is crucial work, and I’m confident that you’ll find value in this book.

—Steve Portigal

August 3, 2023, Montara, California

CHAPTER 1

Interviewing Addresses a Business Need

Learning About Users to Inform Decisions

A High-Level Research Plan

To Interview Well, One Must Study

The Impact of Interviewing

The Last Word

A few years back, I worked with a company that had the notion to turn a commodity safety product—the hard hat—into a premium product. They would incorporate advanced features and then charge a higher price point. I don’t actually know where their idea came from, but one can imagine that they had seen all kinds of everyday products be reformulated to generate a higher scale of profit (think about Starbucks, gourmet salt, smartphones, Vitamix blenders, or horsehair mattresses). They sketched out a set of features that would improve the functional performance of the hard hat.

When I interviewed people who wore hard hats for work, I didn’t ask them to evaluate the features my client had been considering. Instead, I asked them generally about their work, so I was able to uncover insight into the most significant aspects of their experience. What they were concerned about fell into an entirely different category. They talked about leaving the job site to get lunch (for example) and how awkward they felt among other people while dressed in their prominent, brightly colored safety equipment. Indeed, makers of other safety equipment like bicycling helmets, safety footwear, and safety goggles had already redesigned their products to echo fashionable caps, boots, and sunglasses, suggesting this concern was being felt broadly.

If there were to be a TEDx version of this story, then this team would have become very excited about this new and surprising area of opportunity, despite it being different from what they had already invested in (financially, intellectually, and even emotionally). They’d have torn up those plans, drawn up new ones, and eventually raked in the dough. But you know that isn’t really how these things play out! In these interviews, we uncovered a significant business risk in pursuing their existing idea, so they stopped product development for their hard hat with extra functionality. On the other hand, these interviews identified another opportunity: to produce a hard hat that would address the issue of social performance. That wouldn’t have fit with their organization’s technical or cultural competencies, so they chose to avoid the business risk of developing a fashionable hard hat. What we learned from these interviews informed their decision not to bring any product to market.

When you get down to it, that’s what we do as user researchers: We gather information about users in order to inform critical decisions about design, product, or other parts of the business or organization. To do this means that we go to people’s homes, their offices, wherever their context is. We ask what they do. We ask them to show us. We get stories and long answers where we don’t always know what the point is. We want them to explain everything about their world to us. People may not have a ready answer as to why they do something, but we have to listen for why. We have to ask follow-up questions and probe and infer to try to understand, for ourselves, just why something is happening the way it is. We make sense of this disparate information and show the way to act on what we’ve learned.

Interviewing is a specific method in user research to accomplish these goals. (User research is also referred to by other terms such as design research, user experience research, or UXR.) This book is about interviewing users (also referred to variously as site visits, contextual research, or ethnographic research¹) as a method to conduct user research, so beyond an in-depth examination of best practices for interviewing users, we’ll also consider user research in general. And we’ll also look at other user research methods that can be integrated and combined with interviews.

Nomenclature aside, the broad outline for interviewing users is:

Thoughtfully planning out objectives, who we’ll interview, and how we’ll go about it

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

Learning About Users to Inform Decisions

Typically, when you interview people, you visit your users in their homes, their offices, their cars, their parks, and so on. But this isn’t always the case. When planning a project, ask yourself if it’s more insightful to bring participants in to see your stuff (say, prototypes you’ve set up in a facility meeting room) than it is for you to go out and see their stuff. Overall, your objective is to learn something profoundly new. (There are situations where quickly obtained, albeit shallow, information is beneficial,² but that’s not what we’ll focus on here.)

NOTE EVERY ORGANIZATION CAN BENEFIT FROM RESEARCH

Sometimes, companies declare that they don’t need to do user research. What they typically mean is that they don’t need to do generative user research (learning about people in order to identify product opportunities), but they are probably doing evaluative user research (testing the thing they are developing to make sure it’s usable by people). Denying the value of generative research (because, as they might say, people don’t know what they want and it’s the company’s mission to invent that anyway) belies a poor understanding of how user research is conducted and applied. For one thing, it’s not simply asking people what they want.

For another, it’s not credible that they possess an innate talent for building stuff that people love. Even if they themselves are users of the snowboards, photography equipment, or mixing gear that they make, they will choose and use those solutions differently than someone who is not inside their industry. They will be blind to differences in income, access, use cases, and so on. And they will have difficulty expanding their offering in an innovative way, because they are stuck in this model of being the user.

Often, the stated goal of interviewing users is to uncover their pain points. This approach mistakenly characterizes research with users as a sort of foraging 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. You can observe that people are struggling with X and frustrated by Y, so all you have to do is fix X and Y, and then all will be good.

Although this may be better than nothing, 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 foraging model is that what people in problem-solving professions (such as 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.

Once while settling in for a long flight, I noticed that a passenger in the row in front of me had fashioned a crude sling for their iPhone using the plastic bag that the airplane blanket came in. They had twisted the bag into a makeshift rope, which they looped around the body of the iPhone and then jammed behind the latch that kept the tray table closed. They now had a (slightly askew) solution for watching their own device for the duration of the flight. Initially, I was critical of the ugly, inelegant result. But eventually, I realized it was beautiful in its own way—it was fashioned from the materials they had on hand. Since then, I’ve seen other examples of passengers making their own viewing solutions, and I’ve made a point of taking a picture. (See Figure 1.1 where the passenger has made an iPhone viewer out of the airline’s credit card brochure and some beverage napkins.)

FIGURE 1.1

An airplane passenger viewing stand, made from the materials found on board.

Contrast these good-enough solutions with a more purpose-built accessory (see Figure 1.2): the passenger would have to have known about it, purchased it, remembered to bring it, and carried it with them. Of course, the ideal solution—not just the raw materials—would be provided by the airline itself (see Figure 1.3).

FIGURE 1.2

TabletHookz is an accessory designed specifically to hold a mobile device in an airplane seatback for hands-free inflight viewing.

FIGURE 1.3

A device holder built into the airplane seatback allows passengers to watch videos on their own devices.

There have long been spaces online that exhibit samples of makeshift solutions. They are meant to amuse, but usually with a good measure of judgment and schadenfreude (this is the internet after all!). A good exercise for a user researcher is to seek out those images and reflect on what aspects of these solutions are successful for the people who implemented them.

I encounter satisficing in every research project: a computer desktop with an unfiled document icon in each element of the grid, an overflowing drawer of mismatched food container lids, a not-yet-unwrapped car manual, and tangled, too-short cables connecting products are all good-enough examples of satisficing. In other words, people find the pain of this putative problem to be less acute than the effort required by them 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 containers matched with the right lids? Of course. But are they going to make much effort to accomplish that? Probably not.

Beyond simply gathering data, 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:

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.

FROM MY PERSPECTIVE

GAINING INSIGHT VS. PERSUADING THE ORGANIZATION

While doing ethnographic research in Japan, I accompanied my clients as they conducted an unrelated study. They brought users into a facility and showed them 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 current ink cartridge design: black blocks with text-heavy stickers.

Can you guess what the research revealed? Of course. People loved the new designs, exclaiming enthusiastically and caressing the shapes. Regardless of method, 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 for the organization. This team’s approach suggested that there were other issues with the design process (perhaps that leaders wouldn’t make decisions without supporting data from users) and while their research might have been the best way to move their process forward, ideally it wasn’t the best use of a research study.

A High-Level Research Plan

The operational aspects of interviewing users will be covered in the next chapter (Research Logistics), but here let’s consider the three (plus one special guest) elements of a high-level plan. And by plan, it’s less about how you document the plan and more about the thinking that makes for an effective research project. A plan should summarize the project as you understand it at the time, including the business problem, the research questions, and the agreed-upon research method. Reviewing this plan with your team will ensure that you are aligned, with an opportunity to clarify, reprioritize, or expand the work.

NOTE THE ANSWER TO A NEVER-ENDING STORY

This book defaults to considering research as projects that have a beginning and an ending. But there are other models. Rolling research is a way of providing designers with regular access to participants who can provide feedback on whatever they are working on. Typically, a small number of participants are scheduled on a weekly basis. Designers and researchers determine earlier in that week what they’ll show to the participants, and what questions they’ll ask. Continuous discovery involves the entire product team, through the entire development cycle, and includes designing, prototyping, and getting feedback from users.

Even if you are interviewing users through one of these approaches, most of the guidance in this book (for instance, Chapter 6, The Intricacies of Asking Questions) will apply directly.

The Business Problem

The business problem (or business objective) is what your organization—the producer of products, services, solutions, and so on—is faced with, as shown in Table 1.1.

TABLE 1.1BUSINESS PROBLEM EXAMPLES

To get an in-depth understanding of the business problem, you’ll probably want to talk with your stakeholders. You’ll learn more about this topic in Chapters 2 and 10, Making an Impact with Your Research.

FROM MY PERSPECTIVE

UNCOVER MISALIGNMENT EARLY

I once worked with a client who made a digital platform used for particularly complex transactions. They already supported the buyers, sellers, and their respective brokers, and now were looking at opportunities to incorporate the other entities (known as third parties) in these transactions. This research was a strategic priority, traceable to goals assigned from on high.

To kick off the project, we scheduled two activities (loosely based on the Questions Workshop³) with different groups of stakeholders. We set up a spreadsheet to capture decisions they were planning to make and what information about these other users would help in making those decisions. In the first workshop, the main project sponsor halted the proceeding to ask Now, what do we mean by ‘third parties?’ I assumed they knew, and they assumed I knew! I was surprised, but glad they weren’t afraid to ask a dumb question. It was a disconnect, but an important one to uncover, and at the right time. We aligned on a definition and then moved forward with the questions. In the second workshop, a stakeholder kicked off the session by telling us Just so you know, we’re already coding a solution. Again, I was surprised, but this was very helpful to understand at the outset rather than later.

The Research Question

The research question identifies the information you need from users to provide guidance about the business problem. Whereas the business problem looks inward, the research question looks outward—in other words, the business problem is about you and the research question is about your users (see Table 1.2).

Sometimes the research questions are clustered and nested. For example, the business problem We are investing heavily in social media and want our customers to promote our services more might lead to this set of research questions.

What do people’s social networks look like? What tools do they use and how are their networks structured?

How are purchase decisions driven by the structure of people’s social network (on and offline)?

How do people leverage social networks for shopping and other kinds of decision-making? Who has influence with them currently?

Who among their social network (and beyond) are trusted sources of information for various decisions and purchases (particularly within the client’s area of business)?

TABLE 1.2RESEARCH QUESTION EXAMPLES

To further inform the research questions, you should review previous research reports, existing products, and in-development prototypes. Look for relevant research findings, explicitly stated assumptions or hypotheses, and implicit hypotheses in the decisions that have already been made.

NOTE FIND THE SPECIFICITY THAT’S RIGHT FOR YOU

When I ask teams to work on articulating their business problems and research questions, they often find it surprisingly challenging, but also enlightening. There won’t be a singular perfect answer, but the process of considering the specifics is valuable for developing a deeper intention and focus for the research. That process might include going back and forth on different variations and wordings. It might not produce a perfectly structured 1:1 relationship between the business problem and the research question. If you practice with a colleague, before long, you’ll have a feel for the right level of granularity and structure for you.

You should also conduct interviews with your stakeholders—they are often consumers of the research findings who are less likely to be involved in the day-to-day study. I typically aim for 6–8 stakeholders, although some clients ask for twice that amount. These are one-on-one conversations that run between 30 and 60 minutes and are used to dig deeper into objectives and set the stage for working collaboratively. Many of the interview techniques in this book (such as what I’ll cover in Chapter 5, Best Practices for Interviewing) apply to interviewing stakeholders, although you may find it less comfortable to ask dumb questions if you feel your credibility could be at stake. You should ask the stakeholders about the following:⁴

Their history with the organization and the research topic

Business objectives for the project and specific questions the research should answer

Current beliefs about the customer, the user, and the proposed solution

Organizational or other barriers to be mindful of

Concerns or uncertainty around the method

Even though what you learn will undoubtedly inform all of the activities throughout the project, the immediate output is the research questions—articulating what you want to learn from the interviews.

NOTE GET IMMERSED IN YOUR RESEARCH AREA

With the overall goal of trying to understand the problem space you’re exploring, gathering the language that is used to talk about that problem space, and planning what you’re going to ask your research participants, there are other activities that you can do at this point. Secondary research (also called desk research) gives you a sense of current and historical thinking through what’s been written about your topic already. Look at the mainstream press, the business press, academic papers, internal or external corporate reports, blogs, online forums, newsletters, books, and so on. Identify industry, academic, or other experts and interview them. You may also seek out a few experiences that will give you some perspective on the topic. Look at similar products and how they are being sold online or in retail. Try an experience yourself.

For a project that sought to understand how our client could facilitate a more emotional connection with their customers, we visited a handful of environments that had reputations for successfully bonding with their users (an Apple store; Powell’s Books in Portland, OR; the dog-friendly Fort Funston in San Francisco; a Wawa convenience store in Philadelphia; and Rainbow Grocery in San Francisco) and observed the environment, the people that were there, and hypothesized about what factors were either leveraging or contributing to the relationship. This led to topics to explore in the interviews and