Never Ask What They Want — 3 Better Questions to Ask in User Interviews
Wouldn’t it be so easy if users just told you what they wanted? Nope.
The first rule of user research: never ask anyone what they want.
— Erika Hall, Just Enough Research
I rave about user interviews. They’re cheap (see: free), potent (you get more than what you ask for), and efficient (you only really need to talk to five people).
But good interviewing takes practice.
It helps if you’re naturally curious about people, but if you aren’t, you can still fake it till you make it. For example, Michael Margolis of Google Ventures likes to get into character.
Like Erika Hall states above, when you embark on your user interviews, you’ll want to avoid asking what they want. Asking people what they want will lead you to the wrong insights. You will not discover the root cause of a problem, but rather what they envision as their own ideal solution.
Don’t Make User Interviews Hard For Yourself
When you ask a person what they want, you let them think within the realm of possibility. And that makes user research harder than it should be. If you’re trying to create a new product or experience that doesn’t exist yet, you’ll want to know what’s causing people to not be able to do what they want with the tools they currently have. That way, you can design for an entirely new experience or incremental improvement that helps them get the job done.
At KISSmetrics, I spend a lot my time interviewing people about what they currently use to solve a problem. Here’s what I think are 3 better questions to ask. And I ask these all the time:
- What are you trying to get done? (Gather context)
- How do you currently do this? (Analyze workflow)
- What could be better about how you do this? (Find opportunities)
What are you trying to get done? Why?
Getting background information about what a person is trying to do is critical to understanding your users. Things like how big their team is and how their role fits into the larger organization helps frame the scale of a job that your product can help do better.
Imagine that you are a handy man. Wouldn’t you want to know whether you’re fixing a small leak or re-doing a whole room? You’ll need different tools for those jobs and the scale of those jobs are completely different.
It’s the same with user interviews. You’ll want to gain an understanding of what your users are trying to get done in order to get the necessary information back to your team. Your product and engineering teams will thank you for it.
Getting down to root cause of a problem requires you to also ask why. Use the 5-Why’s model to make this easy. You’ll naturally discover a process or lack thereof by asking “why” a couple of times (you don’t have to exactly ask “why” 5 times). I’ve been able to save our engineering team from working on low-value projects by uncovering customer needs that can be fixed with process or approach rather than developing a new feature.
Can you show me how you currently do this?
Edited based on many comments and suggestions. Big thanks to Jared Spool for sparking a discussion!
After knowing the scale of a problem, I like to find out how a user currently deals with a problem. This lets me step into their shoes and experience how potentially painful it is for them. Sometimes, users come up with alternative/hack methods in order to get what they want. These methods are sometimes pretty easy for us to implement in order to save someone hours a week doing something.
Here’s an example. I was recently doing research for the product team on a new feature we wanted to build. But we wanted to see how painful this problem was in order to prioritize it accordingly. By interviewing a bunch of customers on how they operate internally, I was able to draw something like this:
Knowing a user’s workflow also lets your team figure out what parts of the workflow you can improve. For example, at KISSmetrics, we’ve recently found out that our customers prefer to work primarily out of email than with the app itself for checking on stats. Given that KISSmetrics is part of their daily workflow and sometimes even the first thing a person works with when they come into the office, we’re now pursuing projects that will deliver better email summaries to our customers.
Can you show me what’s frustrating about your current process?
Edited based on many comments and suggestions. Big thanks to Jared Spool for sparking a discussion!
Most of your research has already been completed before you even get to this question. This question prompts the user to give you some ideas on what areas need the most help. Also, this is when they will help you validate or disprove your team’s hypothesis on building something.
If you jump to asking users about how they think something can be better from the start, you only get their opinion, not how they actually deal with their current problem.
It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.
-Steve Jobs
This is where you’ll find opportunities to improve or where customers will vent about their current solution and what’s missing. Either you find this opportunity big enough to pursue with your team, or you dismiss it as something that’s already solved and move on to another hypothesis.
This question can also help inform you about a prototype you can build to validate whether you can solve a problem. Note: I’m not saying you should build exactly what they say. The insights you glean from their answers will help steer you to some ideas you can try out. Test the prototypes to see if your designs end up solving their problem. Don’t just make whatever people want.
Using these 3 main questions, I’ve been able to validate hypotheses for my team with a very quick turnaround so that we’re able to work on things that provide long term value to our customers instead of just a bandaid to hold them over.
What questions do you like to ask your customers to figure out what to build or develop? I’d love to hear them. Feel free to ask me anything Charles Liu or @chuckjliu on Twitter.
