Overview

This document aims to provide a simple framework to help anyone that wishes to run user research interviews, aiming to learn more about specific topics, pain points, or simply looking for new opportunities that could be solved by our products.

Goals

• Learn more about friction and confusion users experience with a proposed design/wireframe/flow. Where do they get confused, get stuck, or do the wrong thing?
• Understand how well this design/wireframe/flow solves an opportunity/problem
• Create shared empathy and understanding within the product squads (and any other stakeholders), practice spotting goals, sub-goals, and opportunities.

Tips for running an interview

1. Help the interviewee feel comfortable with you, know that you are listening, not judging. You aren’t testing them or their skills, they are doing you a favour by sharing information with you. The following video is a good example on how to start.

   https://www.youtube.com/watch?v=Qq3OiHQ-HCU

2. Get to know them a bit at the start.

3. Give the interviewee a brief rundown of what to expect, including some time for them to ask questions in the end (that were not discussed during the interview).

4. Always establish clear research questions (one or more). Don’t run interviews to talk about anything, but have clarity in mind of what are you trying to learn. Even if it is a broader scope, you should have an end goal of what you are doing it. Examples:

   1. “How do DAO members get updated about latest proposals” - Narrow and clear
   2. “How do people onboard new members to their DAO” - Broad, but clear
   3. “Lets learn why people like DAOs” - Too broad, hard to get actionable insights

5. Focus on facts, not opinions - Always try to get to the bottom of an opinion to figure out the facts that led the interviewee to that opinion. For example, if someone says “I don’t think is a good solution to onboarding members”, start asking questions to deconstruct this into clear reasons. A good approach is to ask the 5-Whys

   Design Kit

   • Getting the interviewee to tell a real story they’ve been though is a plus, as you will have actual facts

6. Just listen. You are not there to teach or put your opinions into the interviewee's mind, but quite the opposite. If they ask you to answer something, try to hold back until you were able to get their side of how would they answer it. Of course, don’t do this to the infinity and sound like a jerk refusing to be cooperative :)

7. Play dumb. Don’t be afraid to ask “stupid” questions. Especially ones that you think you know the answer to. Oftentimes your assumption is incorrect and you’ll get an answer you didn’t even expect.

   • If there is something you don’t know or something you’re confused about, just ask. Take advantage of this opportunity to get your questions answered.
   • Paraphrase their answers back to them to clarify any confusion you might have.

8. Ask open questions not closed ones:

   1. Open (good): what were you trying to achieve when you created your DAO?
   2. Closed (bad): So you tried to create your DAO to increase trees being planted, right?

9. Never ask “Do you like it?”, this biases the interviewee into saying they liked it, as they're afraid of hurting your feelings.

10. Be respectful of the participants’ privacy and time. The individual data and videos should only be shared within the team. Take their names and information out of the place where you synthesize the data.

Extra resources