Mastering the 5 Act User Interview

Tips for the best user interviews

The 5 Act Interview is a structured 1-on-1 interview format developed at Google Ventures as part of their Design Sprint workshop methodology.

At Voltage Control, I often moderate interviews on behalf of my clients. Some of our clients don’t have UX Researchers on staff, their teams aren’t experienced in this type of interviewing, or they are too overwhelmed with other work to help out. When not running the interviews, I’m often coaching my clients or startups that I mentor on how to get the most out of their interviews. These coaching sessions are full of tips and tricks from my experiences moderating nearly a thousand interviews and watching countless others. I hope this post helps you refine and improve your 5 Act interview.

Respect The Craft

Just because you didn’t go to school for something, it doesn’t mean you can’t be good at it. I did not go to school for UX research, but it’s a craft I’ve honed because I’m passionate about it.

Becoming a great researcher begins with a commitment to the continual improvement of your process. You should always be looking at your last interview—think about how it went and what you can do better next time. Focus on evolving and deepening your skills with each interview.

Be Friendly and Set Expectations

With only an hour to spend with each tester, you need to set things up for success quickly. Be friendly and set expectations to avoid fear, uncertainty, and doubt. Provide context about the project and discuss how the process works. Remind them why they were chosen and thank them for their perspective.

If relevant, let them know that team members will be observing from another room. Point out that while the team will be watching, you’ll be the only one interacting and talking with the tester. Get their permission to record the session.

Scrutinize the Screener

It can be easy to blame the recruiting when you hear feedback that is unsettling or that challenges some of your beliefs. Spend plenty of time on your screener and make sure that it is bulletproof.

Start with your Goal and Target in mind, and build a list of attributes that define the individuals you’d like to gather insights from. In addition to considering inclusive criteria, explore the things that would cause you to exclude someone from your study. When writing the screener, combine the inclusive and exclusive criteria in ways that obfuscate your desired test subject’s attributes. I even like to throw in extra questions or answers that will throw off applicants that are just trying to interview for the compensation.

I recommend sharing your Screener with your entire Sprint team before it goes out to get additional feedback.

Pro Tip: Use this worksheet from Google Ventures for writing a screener

Make a Mod Guide

A good interview starts with an interview guide, also known as the “mod guide.” Start by re-writing your Sprint questions as “Yes/No” questions such that the desired answer is “Yes.” This will help reduce confusion on the team with scoring the interviews. Collect questions from the team about the prototype, capture all their curiosities and concerns as “Yes/No” questions.

Additionally, write a series of “context” questions that dive into the tester’s prior experiences, opinions, desires, fears, and concerns. Include a prototype guide that maps out each page and lists the active hot spots. If there are specific concerns or things to explore, they can be placed on this map. Last, write a set of debriefing questions.

I also like include a reference section and a set of reminders. The reminders are there to remind me to turn off notifications, clear my desktop, prepare necessary links, etc. When I first started running interviews, I would add things to this reminders list as I tripped over things or bumped into issues while conducting an interview. Over time you’ll have a mod guide template that is tailored to your needs.

Pace Yourself

Pace out your interview so that you can make the most of your time with the user. Don’t go too quickly. Allow time for the user to explain themselves. Probe deeper if needed.

Plan out your schedule ahead of time. Decide how much time you want to spend on section or topic. Put this schedule in your mod guide and stick to it. Relying on this pre-defined schedule will help you keep the lower priority conversations from taking up the whole interview.

Context Questions

Take your time to build rapport, see what comes out, don’t move onto the prototype too quickly. The context questions are a great way to learn more about a user and how they think about or use your product.

Ask questions to understand the interviewee’s background as well as how they’ve used your product in the past. These insights can be helpful additions to existing research that has been done. They can also help to bucket the tester into a “Jobs To Be Done” category or other affinity groups you are using for your users.

These questions also allow you to put the user at ease before introducing the prototype. They provide a moment for the tester to transition into the more detailed work of responding to your prototype. This transition is vital for collecting honest and accurate insights.

Introducing the Prototype

Start with a simple explanation of prototypes. Explain that some things may not work and that’s ok. Tell them that there are no right or wrong answers and that they can’t hurt your feelings or flatter you.

Ask them to speak out loud. Point out things they love, things they hate, things that confuse them, or things that jump out for some reason or another. Remind them that you’ll be there to guide them and will encourage them to speak up when they get quiet.

Don’t Skip the Segue

Design Sprint prototypes always start with a segue. The first few screens of a prototype are dedicated to transitioning the user into the experience. Even though we’ve warmed them up with context questions and got their “head in the game,” we don’t want to drop them deep into a prototype without any context.

Typically we will start them off with a screen or visual that sets up our scenario. They may be looking at a Google search bar if we expect them to do a Google search, they may be looking at a fictional TechCrunch article or a mock ad on a popular website. We’ve even started with an email from their boss.

Even though we aren’t “testing” these initial screens of the prototype, it’s essential for the user to start here. This is their tunnel into the prototype and helps them deeply transition into the scenario.

Focus on Desirability

Often I see interviewers concentrating on usability. However, you’ll get much more significant insights if you focus on desirability. While your mod guide will have a list of tasks you’d like to complete, the interview shouldn’t be overly prescriptive about what the user is doing and/or how easy it is to do things. Instead, you are seeking to learn their level of excitement or intrigue for the solution concept. Listen carefully to the language they use and what peaks their interest and where they get bored.

Embrace Serendipity

Allow the user to choose their own adventure. You’ll learn some unexpected things that you wouldn’t have learned with a rigid approach. Instead of giving the user a set of tasks to complete, follow them through the experience and see where they go, in what order and why. If you missed some things along the way, back up and explore them. Ask them why they initially skipped over them.

Introduce Alternative Scenarios

Even when we’ve spent a lot of time upfront crafting the perfect scenarios, we can be confronted with new revelations during the interview. Either the user gets stuck or confused by the script, or the conversation reveals a new situation that might be useful to pursue. You can gather additional insights into how the user reacts to the solution by introducing these alternative scenarios.

I find this especially useful when the user is confused or gets tripped up on some details in the scenario. Sometimes they keep defaulting to something that is more familiar with them. In that case, it is helpful to introduce some nuance to the scenario to help them perceive it as a new and different situation. Other times the user will say something that prompts me to develop an entirely new scenario on the fly.

Flip the Yes/No

When moderating interviews, be conscious not to bias the tester by asking “Yes/No” questions. (Also, multiple choice questions are in fact “Yes/No” questions in disguise.) If you are anything like me, you probably still blurt out some leading questions by mistake. When this happens, just tack on something more “open.” When you hear that “Yes/No” question come out of your mouth, immediately follow it up with something that prompts them to expound on their answer.

If you can’t tack on before they answer or you didn’t even realize you did it until you hear them say “Yes,” you can just ask them “Why?” or “Could you expand on that for me?” It’s not ideal to prime them with that “Yes,” however, if you can get them talking, then you might just salvage the situation and get some really valuable insights which might negate that “Yes.”

Have you ever noticed that almost 100% of the time testers will say “Yes” when asked a “Y/N” question? Test subjects are prone to be agreeable, which can skew results. For this reason, I encourage founders and innovators to seek to disprove their beliefs. Instead of searching for confirmation, search for things that contradict your beliefs!

Be Vague

Another way to avoid bias is to be vague in the language you use when asking uestions. Avoid saying specific words that appear in the UI such as “Buy Now” or “Pricing” or “Learning Center.” You want to know what users see naturally and how they interpret them. Instead, you want to be vague and provide general guidance to nudge them toward the object in question. Spend some time when crafting your mod guide to write some of these unbiased prompts.

You should also avoid asking if they would click on a button or even what they would click on. A more generic prompt like “What would you do next?” gives them much more freedom in how they might respond, which will provide you with a more truthful answer.

Here’s some of my favorites probing questions:

• What’s that there above search?
• Can you explain what that blue thing does?
• Can you explain that to me?
• What would you do next?
• Can you elaborate on that?
• What do you think about that? How does it make you feel?

Make Them Repeat It

When a user says something that is vague or confusing, it is tempting to say “Did you just say XYZ?” If it is unclear what they said, ask them to repeat it. (“I’m not sure I understood that” or “Could you repeat that?”)

While you could argue that this is an OK time to ask a “Y/N” question, it is preferred to ask them to repeat themselves.

Sometimes I do this for the benefit of my observers, to ensure that they got a clear understanding of the tester’s line of thinking. Other times, I do it because I have a hunch that there is more to what they are saying than is immediately apparent. For instance, I may think that an innocuous statement may actually be more profound than it seems on the surface, so I’ll dig in and make them go deeper to expose this broader implication.

Probe For Expectations

One of my favorite techniques is to slow the user down and have them explain their expectations and interpretations of things before clicking through to reveal subsequent parts of the prototype. Sometimes we design “waiting” screens just to slow down the user and give the interviewer an opportunity to talk with them before they jump to the next important screen.

Once I collect their observations and thoughts, I’ll ask them to proceed forward to the next screen. Then I’ll ask them how this matches their expectations. Sometimes, it clearly doesn’t match, but it may be better than they were expecting. We explore all of this together. Did this shock them? In a good way or did it bum them out?

Tease Out Details

Dig into your tester’s responses and comments, ask follow-on questions and dive deep into the details. Your goal is to pick up on the user’s nuances and preferences and then ask them further questions related to those. Think about different ways to ask “why?” Asking “why?” repeatedly is an effective way to dive deeper into the inquiry, but it can exhaust your tester. Instead, think of ways to dress up the language, or how to ask why using different words each time.

Explore the Unknown

If your prototype only hints at features but doesn’t show the details, you can still ask the user about what they expect from that feature. One of my favorite things to do is to ask the tester what they would expect to happen if they clicked on something.

For instance, imagine they try to click on a button that is not actively in the interface. The button was placed there for a reason, maybe the team had talked about how they would like to support personalized content, and this button would allow the user to set those preferences. When the user tries to click on that button, I might say: “What do you think this is? What do you expect to happen if you clicked on it?” This gives us perspective on how the user thinks about this part of the solution and if they consider it helpful.

Embrace the Unexpected

If some feedback surfaces that isn’t directly related to the prototype goals, you can still seize the moment to get more understanding of the user’s past experience with both your product and competitor products. Explore these areas and allow the user to go deeper into those areas as time permits. Sometimes these insights will provide unique and unexpected insights that can be profound and transformative.

Always Debrief

Before ending the session, debrief to get final insights, such as how they would explain the prototype in their own words and what they would change. This moment of reflection is a great way to capture their major objections and overall impressions. I especially like to hear the words they use to describe the solution as they are reflecting on what they saw.

Some of my favorite debrief questions:

• What surprised you about what you saw today?
• Who do you think would use something like this?
• In your own words, how would you describe it to a friend?
• What are the pros and cons of this prototype?
• How does it compare to things you’ve seen in the past?
• If you had a magic wand and could add, remove, or tweak anything about what you saw today, what would you change?
• How would you feel about using this in the future?
• What else should we know?

Scorecard

Skip the post-it notes; they are too messy to deal with at the end of a long day. Instead, make an online scorecard that everyone can fill out in real time. At Voltage Control, we use a shared Google Sheets file. The sheet has all the Sprint Questions listed out and also includes Prototype questions. They are all Y/N question, 1 per row and 1 column per tester. This workbook is duplicated per Sprint team member. Each team member will score each question for each interview. There is a section at the bottom of capturing big insights and quotes!

The following week, the recap goes much smoother as all of the notes and quotes are already in the same Google Sheets file. We review this doc together, discussing any disagreements and synthesizing all our findings into an action plan.

---

Hopefully, these thoughts will help you improve your 5 Act Interview. I would love to hear about your experiences applying these ideas, or if you have additional ideas or tweaks. Please comment below and we can all become better listeners together! If you found this post helpful, please clap. Clapping helps the content reach more people like you.