Frequently Asked Questions
These common questions about interviewing users and their short answers are taken from Steve Portigal’s book Interviewing Users: How to Uncover Compelling Insights. You can find longer answers to each in your copy of the book, either printed or digital version.
- Why is this even a book? Isn’t this really just talking to people? I already know how to do that!
To learn something new requires interviewing, not just chatting. Poor interviews produce inaccurate information that can take your business in the wrong direction. Interviewing is a skill that at times can be fundamentally different than what you do normally in conversation. Great interviewers leverage their natural style of interacting with people but make deliberate, specific choices about what to say, when to say it, how to say it, and when to say nothing. Doing this well is hard and takes years of practice.
Chapter 6 is devoted entirely to techniques for asking questions. - Why would we bother to talk to our users? We use our products every single day and know exactly what we need to build.
People who make a product think and talk about it fundamentally differently than people who don’t. While both groups may use the same product, their context—understanding, language, expectations, and so on—is completely different. From a user’s point of view, a Big Mac eaten in Moscow is hardly the same product as a Big Mac eaten in San Jose, CA. And neither one is very much like a Big Mac eaten at McDonald’s Hamburger University in Oak Grove, IL. A strong product vision is important, but understanding what that vision means when it leaves your bubble is make-or-break stuff.
In Chapter 1, I examine the impact that interviewing has on project teams. - We don’t have time in our development process to interview our users, so what should we do?
Developing insights about users doesn’t always have to be a milestone in a product development process. Insights can be an organizational asset that is assembled quarterly (or whenever) to feed into all aspects of product development, marketing, and so on. Once a baseline is established, subsequent research can enhance and expand that body of knowledge. Within time constraints, I’m constantly impressed by people I meet who are so hungry to bring user information into their work that they find ways to do whatever they can.
In Chapter 9, I discuss the trade-offs when time is the constraining resource. - Which team members should interview users?
While more design organizations are staffing a research role, the designated researchers aren’t the only ones who go out and meet customers. I’ve seen many times that as companies buy in to the value of research insights, the researchers shift from struggling for acceptance to being overwhelmed by demand. It’s not unusual to see them scaling up their own teams, working with outside partners, and training their colleagues to be better researchers themselves. Ultimately, who shouldn’t be interviewing users? There will always be a range of strengths in interviewing skills; leading research is a specialized function, but user research is something that everyone can and should participate in. In most cases, this will exclude functions unrelated to key aspects of the business, but given the cultural value of understanding the customer, everyone could be involved in consuming the results of interviewing users, even if they aren’t directly speaking to those users themselves.
In Chapter 5, I look at how to manage a team composed of seasoned interviewers and less-savvy colleagues. - We interviewed users and didn’t learn anything new. How does that happen?
Sometimes it’s perfectly appropriate to validate hypotheses or to confirm the findings from previous research. But often when stakeholders report they didn’t hear anything new, that’s a symptom of something else. Were stakeholders fully involved in planning the research? Did the researchers develop a rich understanding of what these stakeholders already believed and what burning questions they had? Not hearing anything new may be a result of not digging into the research data enough to pull out more nuanced insights. Finally, if customers are still expressing the same needs they’ve expressed before, it begs the question, “Why haven’t you done something about that?”
In Chapter 3, I discuss working with stakeholders to establish project objectives.
