User interview guide
“A problem well stated is a problem half solved.”
If you ever get your hands deciding product issues or features - that article may be for you. Here we will try to look into essential part of any product research, such as user interviews.
Assumptions vs. Data
Let me save you a couple of bucks on different courses and tell you this - successful products are those that meet crucial customer requirements. They must assist a particular user job or pain.
How many times have you heard about a business that was so exciting on a paper, but when it hit the market - no one was buying it just because no one needed it? One of the great examples is the New Coke controversy. In the 1980s Coca-Cola was losing its profits to Pepsi and decided to renew the classic Coke recipe. But, unfortunately, the public reaction was so bad that they returned Classic Coke taste in just six months. Of course, I’m not telling you that Coca-Cola hasn’t investigated the market, but they definitely solved the problem no one had. And it happens too often. We find the problem, get attached to it, and then realize people won’t buy that solution.
We won’t mention more nuances to that topic, such as possibly hitting the wrong market segment or incorrect pricing policy. But believe me, false assumptions about your customers are crucial in product&design.
Take a look:
Statement: we want to increase website traffic.
The solution that we did: more advertisements.
The real problem was: the cookie popup would overlap the whole page on some devices, which was impossible to close. And people left the website.
And it’s not a unique case. You need to hear stories from users to gain these insights. For example, we may sometimes polish features that aren’t bringing any added value. To avoid this, it’s better to design and improve the product using user data rather than assumptions.
Whenever you are having a product meeting, always watch out for assumptions. They may come from anyone on the team, and our job is always to question things. It may be annoying, but we keep the product and users in mind here. A question such as “Why” would go a long way. The key is not to oppose everyone but to ensure the decisions are made for the target audience, not the team.
Compare these two situations:
- I think we need a new label here. I want to see “Done” on these documents.
- Why do you think users may benefit from them?
- Because I think it’s a mess right now.
- I think we need a new label here. I want to see “Done” on these documents.
- Why do you think users may benefit from them?
- Because our users want to see unfinished documents at the top of the list, and this badge may help them identify which are which and filter by that.
It may look utopian, but this is what makes some products great. You use real data and create stories. And support all of them in your decisions.
To have more situations like in the second example, this is where we need research. We need to gather that data from our customers to solve the right problems.
User research comes in many forms and shapes, and I recommend you on reading this article by Maze: The ultimate guide to UX research.
The two main types of research are qualitative and quantitative. Usually, you discover things via the last one and then validate your hypotheses using qualitative methods. Deciding which type of research you currently need is a topic for a whole other article. Here we will focus on the user interviews type of it.
A user interview is usually a conversation that may happen online or offline. You would typically have a script to guide this communication, but you are not obligated to follow it strictly. The beauty of meeting with a customer is that you never know where it will lead you.
General advice for user interviews:
Do not interrupt
Avoid using closed questions to which the user can respond Yes or No
Avoid providing an answer in a question itself
Try not to judge
There are never too many Why questions
User interview helps you to find users’ motivation, routine, buying choices, etc. In addition, you get to see how they work, spend money, and what they love. For that, it’s essential to build trust during such sessions.
Finding participants
The most popular resource for finding participants is User interviews. Here you can set all necessary search properties to find the correct customers. Also, this website supports search for professionals, which are the users with a specific job title.
The important thing here is to create a suitable screener to filter through all the potential interview participants. Avoid having too many questions here. I usually like to have 2-3 closed questions and one with a short answer, which gives me an insight into whether this participant suits my current research or not.
Example of one of my research screenersHowever, you can also search for candidates on Facebook and LinkedIn. For these purposes, you might need to write a cover letter. Feel free to use the example down below:
Hello {participant name}, my name is {your name}, I am a {your role} at {your company name}.
We are currently discovering a product where {user can make regular rent payments}. Would you be interested in talking about this experience? The interview is rewarded and will take {60} minutes over the {Zoom}.
You won’t need to share any sensitive data. Please let me know if you have any questions!
The interview reward could be held by a website such as User Interviews, or you can do it manually. I usually opt for gift cards of the user’s choice. Prices can vary from 10 to hundreds of dollars. It all depends on your target audience and budget.
Also, if you need to talk about a specific product, you may need to have participants sign an NDA. Here is a good example written for user testing.
Interview script
It’s a rule to have a script for each interview. However, you are not obligated to follow it strictly. You need it to avoid getting lost in the conversation and follow the research purpose. Its content will significantly depend on your research goal - getting to know how users use the product, how they solve current problems if they have any, validating their user journey, or learning more about their buying decisions and payments.
I will provide you a general template, feel free to edit it as mush as possible.
Intro
Hi, {respondent name}. Thank you so much for agreeing to have this conversation. My name is {your name} and I work as {your title} at {your company name}. And I’m here to learn more about {how you make investment decisions}. I am working on a product that may help people like you, and I want to know more about your experience.
The interview will take no more than {60} minutes. Please feel free to skip any question if you feel like it, and we can interrupt the interview at any given point or time.
Can I record our meeting? The conversation will be used only for discovery and shared within my team.
Start recording
Base
1. Tell a little about yourself
2. Recall and describe the last few cases when you {encountered problems/used this product/flow}. Describe how did you cover your need?
3. How many times in the last {week/month/hour} did you {encounter problems/used this product/flow}?
4. In what cases do you usually {encounter problems/use this product/flow}? {What emotions did you experience when you faced these problems/flow}?
5. Do you need help with {encountered problems/flow}? Or do you manage on your own?
6. How do you deal with {encountered problems/flow}?
7. If you had to {encounter problems/use this product/flow} now, what would be your steps?
8. What are the advantages of this solution? What are the cons?
9. How much did it cost you? How much are you willing to pay for a solution to {encountered problem/product/flow}?
10. How did you try to eliminate the disadvantages in the process of {encountered problem/product/flow}?
11. What would an ideal solution look like for you?
{Add specific questions related to the flow or product. Try to ask more the why questions.}
{Questions from other interview research participants.}
Outro
Thank you so much for your participation. I’ve learned today some great insights. Could you please tell me if I can keep your contact for future research and/or testing?
There could be multiple people present during the interview. However, avoid too many. Also, it's better to have only research team members present (avoid inviting anyone who might not be able to avoid judging or is holding too much onto the current experience). Usually, one person leads the interview while others observe, make the notes, and have additional questions at the end. It's recommended for the interview to be conducted only by one person to avoid confusion.
One more thing. Sometimes people refer to the famous quote by Henry Ford “If I had asked people what they wanted, they would have said faster horses”. However, the research goal, in that case, would be to learn that people want to access places faster or any other pains and jobs.
Working with the results
After you have finished with an interview, it’s usually good to have a quick recap for 15 minutes to make some notes, especially if you had colleagues on the call. But after everything, it’s time to work with the data.
You would usually end up with a video or audio track of your interview, which you now have to transcript. There are many excellent resources for that, such as Trint or Descript. You can pick whatever suits your taste and budget. As a result, you will have your interview as a text.
I’m a big fan of Value Proposition Design Canvas (VPD), which helps you to highlight essential steps in a user interview text. The key items here are jobs, pains, and gains. Those are data snippets you can use for your product and design purposes:
Jobs: “I open the app”, “I go to work”, “I order pizza”
Pains: “It takes 2 minutes to load”, “I wish they had this feature”, “It’s too expensive for me”
Gains: “That really helps me to do my job better”, “They always have great discounts”, “I use this app for 3 years now”
Sometimes you need the context to distinguish one or another. For example, the phrase “it costs 10 dollars” tells us nothing, but the facial expression and voice tone can indicate what it is for the user.
You can create a dedicated Miro or FigJam board and put those quotes onto the stickers. You will also notice that some of them are repeating themselves, and you can group them into meaningful topics.
Example of organizing data from the interview in MiroHere comes the fun part: you can create your product or feature around jobs or pains. Both methods are valid, and the only difference is the expected decision lifetime. Products built around jobs tend to live longer since users can adapt to the pains and aren’t always willing to pay for them.
As a designer you can probably stop here and use this data for improving your designs, as a product manager you can do the full VPD by adding painkillers, and gain creators and products/services. You can find more about it here.
Usually, for one research iteration, you can aim for 5-7 participants for user interviews. After a certain point, the answers tend to repeat. As a result, you have the data to build your products and designs upon.
Conclusion
I hope this article showed you why user research is essential and how to conduct user interviews. Do not worry about feeling like you are nosy - people enjoy talking about themselves and their experiences. I once had an interview at work where the participant said that it was the first time in 10 years that someone listened to her about the product. We can make a significant impact and create valuable products for the people. This is what I stand by.
Share the article with people who have design in their hearts 💙
