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.
CONTENTS
The Importance of Interviewing in Design
User Insight in the Design Process
To Interview Well, One Must Study
A Framework for Interviewing
Check Your Worldview at the Door
Make the Interview About the Interview
Embrace How Other People See the World
Be Ready to Ask Questions for Which You Think You Know the Answer
Be Selective About Social Graces
Be Selective When Talking About Yourself
Acknowledge That the Interview Is...Something Unusual
