How to conduct user research — when you already have a hypothesis
A while back I wrote about design thinking, the critical third pillar of any great hardware development effort. I wanted to emphasize that you need more than engineering and business skills to make a great product and company. You need to focus your efforts around real people’s problems. There are plenty of hardware companies that have gone bust because they built solutions to problems that they didn’t really understand (or that didn’t exist at all), and you don’t want to be one of them.
Here’s a 1-liner from that writeup:
I say that design thinking is about developing a deep understanding of people and their problems - and then developing a creative solution to those problems.
So, let’s say you start acting like a designer. You leave your preconceived notions at the door. You take a few steps back, and start building a human-centered understanding of the problem. You use the tools design thinking lays out – careful observation, immersion, effective interviews – to build up your empathy. You listen to a lot of stories, pull them apart, and start finding patterns.
Good work! But, at some point, you’re probably going to run into a dilemma.
You have a strong understanding of the problem, and you're building a solution to match. But you want to keep talking to users (after all, as a designer or product manager, you never stop learning from your users). You’re looking to corroborate and refine your understanding of the problem, and with it your ideas for the optimal solution.
How do you approach customer conversations at this point? It becomes less productive to start every conversation from the highest level of “tell me about your day.” But you also don’t want to jump straight to “tell me what you think of this problem statement, and this potential solution.” You run the risk of injecting too much of your own bias and undoing the design-centric foundation that got you where you are.
You want to explore a specific topic while satisfying the “rules of engagement” and without biasing your interviewee.
Some of the "rules of engagement" they taught at Stanford
It’s a thin line, and a tough balance. But, here’s how I’ve been approaching it.
1. Set the category of the conversation
Let’s say you’re interested in how office buildings are cleaned and maintained. You might have started off your design thinking effort with a high-level, unbiased look into how office maintenance works do their jobs. You shadowed them on their shifts, asked a lot of questions. Maybe you and your teammates tried to tackle a floor of an office by yourself to get the experience.
Now, you’ve focused in on garbage collection as a key pain point. Knowing where all the trash cans are and which ones are full enough to bother with is hard (Yes, I’m ripping off Compology. Love them!). But, you have more research conversations lined up. How do you approach it?
The first thing I’ll do when setting up the interview is to be clear about the category of the conversation. I’ll go ahead and specified that I’m interested in talking to them about waste management challenges and best practices, though I won’t be any more specific than that. This lets the interiewee opt out if they’re not the right person to talk to about this, and sets me up for a more targeted and productive conversation.
2, Ask a “directional question”
Before the conversation starts, I try to think up a handful of questions that...
- guide the conversation to the topics I want to learn more about
- prompt stories
- don’t put words or ideas in my interviewee’s mouth
For example, I might ask “When was the last time you got a complaint about garbage?” This question satisfies our rules of engagement, prompts a story, and gets us going in the direction I want to learn about.
3. Use their own words
As the interview goes on, you’ll be guiding it. You’ll be looking to corroborate things you learned in the past, challenging your current assumptions, exploring new or conflicting perspectives on the problem. Unlike some of your earlier interviews, you’ll be specifically swirling around the topic you’re now focused on. In my experience, the trick to handling the tension around focusing a conversation while not leading the conversation is to frame questions in your interviewee’s own words. For example:
- "You mentioned that how much time it takes to gather all the garbage varies. Why is that?"
- "You said you prefer working in offices with open floor plans. Why was that?"
Visualize this. You’re in a new place, and you know want to go North, but all you’ve got is a blank map. Everything your interviewee says is paths opening up on that map. These paths are the tools at your disposal. Not all of them will lead straight North – they’ll twist and turn and zigzag and backtrack. But they’ll get you there, and you’ll be better off for having absorbed the scenery on the way.
Don't be afraid to get lost along the way!
Running a high quality user research effort is a lot of work, and there’s no one way to get it right. Right now, this strategy is what I’ve been using to carry out late-stage user interviews. So far, I feel pretty good about it – I’m getting new stories to crunch on, refining my understanding of the problem, and not losing too much time re-covering the basics. Give it a shot, or get in touch if you have a better idea of how to approach this issue.
