Best Practices for Interviewing Users and Capturing Insights
As Product Managers, we aim to build and develop products that solve problems our users have. But we can only do that effectively when we genuinely understand them. So, we talk to them.
There are different types of research conducted during product development. For the purpose of this article, I’d like to concentrate on interviewing users during Exploratory Research. In all of my experiences doing exploratory research a few factors were constant:
We’d talk to A LOT of users.
Being the exploratory stage, our questions spanned over a vast range of topics.
Bullet point #2 would result in copious amounts of data gathered to be synthesized.
The team would get exhausted, both physically and mentally, and happy hours became routine. (Ok, that last bit might’ve been just me, not the whole team)
Interviewing is one of the key tools in creating a deep understanding and developing empathy for your users and customers. Without that, you run the risk of building the wrong thing.
The actual interviewing and parsing through insights is a bit of an art form. How do you interview your user without it coming off as an interrogation? You’re aiming to have a conversation, a conversation during which you hope to gain insights that will be valuable to you as a product manager.
Whether you’re interviewing users in person or via phone, there is some ‘science’ to the dialogue. Below are some of the best practices I’ve compiled over countless interviews I’ve led or been a part of.
Limit the number of interviews in a day — Interviewing users is a mentally draining process. You get a flood of information dumped on you (per your request), and you have to ensure you a) continue to stay engaged, b) don’t lose any valuable insights, c) stay sane. My recommendation has always been to limit it to 3 interviews per day.
Have prepared participants — Having your team prepared will help in quickly establishing a rapport with the user you are interviewing.
Have at least 2 note-takers, but no more than 3 (I like to include the product manager, designer and 1 engineer).
The interviewer should not participate in note taking, to ensure his/her attention is directed towards driving the conversation.
Both the interviewer and note takers should be very familiar with the interview script.
I always recommend to also have the script printed. It helps the interviewer to mentally (or physically) check off questions and topics that have been covered, and it helps the note takers to keep track of the topics they are capturing notes for.
Make sure your logistics are ready to go — This is especially important if you’re doing the interview via phone.
Ensure all of the technology is setup: your conference bridge is operational, you can present your screen (if needed), and your recording device is in working order (if you’re interviewing in person).
If the interview is in person, make sure you have all the note-taking equipment. (I’m a sucker for bright colored Post-Its)
When taking notes, be sure that you capture what the users are saying as exact quotes, and avoid trying to interpret or rephrase it.
Start off the interview with some housekeeping items— I’ve been in in-person interviews where the interviewer jumps right into the questions, without introducing people. I can’t stress the importance of introductions, even if you’re conducting the interview over the phone. Introductions can break down barriers of formality and make it more of a relaxed atmosphere.
Also, while doing introductions, give a little overview of the interview format, and what its purpose is. Just avoid getting into a great level of detail (i.e. “We are meeting with you so that we can understand exactly what you have a problem with” <- don’t say that). And if you are planning to record, make sure you ask for permission!
Note-taking during user interviews - During each user interview, there are copious amounts of notes taken. If you’re like me, you have stacks and stacks of post-its. Here are some things I do to preserve their long-term use:
If you’re using post-its, use different color ones for each interviewee. If different colors are unavailable, jot down initials of the interviewee on each post-it.
Use sharpies to take notes on post-its. (They’re much easier to read than pens or pencils)
Keep your post-its in the order of the interview script/questions. (It helps to flip each new post-it upside down, as you take notes, so by the end, when you have a whole stack upside down, you flip it over and voila, they are in perfect order)
Don’t paraphrase or interpret what the interviewee says. Use their exact words.
Write down one thought/statement per post-it (it’ll be useful when synthesizing and assembling insights!)
Be sure your note makes sense and has context. One-word notes can be difficult to decipher the next day. (Example: “iPhone’s camera” vs “iPhone’s camera has evolved so much in the quality of photos it produces, that I rely solely on it nowadays”)
Clearly mark the stack of notes with which interviewee they are from. (Here’s where the color-coding becomes extra useful)
Keep the interview flowing smoothly:
As an interviewer, avoid reading questions from the script. You should be familiar with the topics you want covered. Only glance at the script to keep yourself on track.
After asking a question, pause to let the user really think about the answer. Avoid trying to help them answer the question (this is really hard to do!). It’s in our nature to try to “lead the witness”, so be mindful. Get comfortable with uncomfortable silence.
In the same vein, avoid questions that box them into a choice, e.g. “What’s your favorite color, red or blue?”
Acknowledge the answer before moving onto the next question. This helps create a natural and smooth transition, and also shows that you are paying attention to the conversation.
If you ask a yes/no question, have a follow up ready. Asking why or how often helps you extract insights:
“What is your favorite feature of iPhone 12?”
“I really love the camera”
“Can you describe why the camera?”
It’s ok to go off the script as long as it’s within the context. As I’ve said to my peers many times: “If you see a thread stick out, forget the script and pull on the thread”.
A smooth conclusion is important — Don’t abruptly end the interview. Ask the user if they have any questions before finishing it up. It should go without saying, but thank the interviewee for their time. If appropriate, set expectations that you’ll be reaching out to them again in the future.
Synthesizing the output of interviews - Great, you have stacks and stacks of information from your users. Now what? This is the fun part — parsing through for valuable insights! (The quicker you do it after the interview, the better)
To help me parse through all of it, I’ve formed a habit of breaking up user feedback into 3 main groupings:
User Landscape Informational data, provides context around the users | What Users Like Feel-good portion of the interview | What Users Don’t Like Core of the interview |
Demographics, technical know-how, role in the company, seniority in the industry, physical location, etc. | Things that work well for users (specific technology, capability, feature, user experience, etc) | Pain points and challenges. |
Building and organizing robust context around the users in this way helps frame them and enables insights down the line to take on more accurate and meaningful applicability. | Understanding why it’s working well is paramount. Knowing that will help you make a lot more decisions. | Some usual subgroups to focus on are process, technology, user experience, and ease of use. These kinds of data points help shape the direction of your product by providing some breeding ground for testable hypotheses. |
These 3 categories work for me, but that doesn’t mean you won’t get some feedback that might not fit into any one of these. The goal is to structure the feedback in a way that produces insights that are useful and actionable.
While interviewing is not the only method of understanding your users and customers, it remains an extremely effective tool in the product manager’s arsenal. When used correctly, it helps surface the kinds of insights that can significantly influence the nature and trajectory of your product.