As consumers, we have our tried-and-true, reliable, and essential products that we use and rely on to enrich our lives and help us face and solve our daily challenges. They bring us joy, security, ease, and greater productivity. We also all know what it’s like to be frustrated by a product malfunction or absence of a component we’d like it to include to truly meet our needs and desires; that extra thing that would save us time, money or effort or increase our pleasure. The user experience is everything. It’s why we continue or discontinue to purchase certain products. That’s why understanding it through user interviews and directly designing for it in the making of a product is essential to customers’ satisfaction and the product’s success. 

User interviews are an increasingly popular way to gather user feedback quickly and easily and include it in the design of your product. They specifically focus on learning user perception of the product or service, versus its usability. Unlike focus groups, which source opinions from multiple users at one time, user interviews are one-on-one sessions to get to know the user’s perspective deeply. 

If you don’t talk to your customers, how will you know how to talk to your customers? – Will Evans, Design Thinker in Residence at NYU Stern

So when and how do you utilize user interviews? We break it down below: 

When to implement user interviews

User feedback is incredibly valuable. It can help advise the development of a product’s design in various stages of the design process. User interviews can be utilized in the following:

1. Before a design is created to enlighten product and workflow ideas
2. During the ideation phase of development to help inform the product’s purpose and usability
3. Throughout early concept development to collect and prioritize functional needs and challenges

How to conduct a user interview

1. Identify your customers

It is critical to interview people in the target audience you are designing for so that you can adequately understand their concerns and feedback and apply it to your design to best serve them. Who are the people that will be using the idea you are designing? They should be the participants in your user interviews. For example, say you are designing a fitness app for friends to workout together virtually. You would want to seek feedback from people who have an interest in fitness, who are seeking community, and who have a smartphone and an accommodating setting to workout out in.

2. Identify the interview objective

What do you or the stakeholders hope to learn from the user interviews? Identify a specific goal. Be careful not to make it too broad like to “identify what the user likes.” This is limiting because the results will not clearly address the questions you are hoping to answer about your design. Instead, identify a concrete goal that is based on a specific attitude or aspect of the end-user you would like to distinguish and cater to. A finer focus will also help you to create compelling and informative interview questions and conduct the interviews most effectively. 

3. Prescreen interviewees

Once you have identified your target audience, it can be beneficial to conduct a pre-screening to reduce numbers to a manageable size before engaging in a full user interview. Establish your criteria–what qualities/interests do people need to have to qualify? Preliminary questions that are given through an online screener, for example, help you to identify which candidates you would like to move forward with. An example question could be, “Are you interested in virtual workout programs?” Those who respond with a “no” will automatically be eliminated, reducing the number of potential participants. Ask additional questions to weed out people who do not fit the target audience criteria and create a finer focused group that does. 

4. Carefully craft interview questions

The best practice is to prepare interview questions beforehand that are thought-provoking, open-ended, nonleading, and support the identified objective. Ask interviewees questions that cover as many topics as possible to paint a clear picture of the information you are seeking. Avoid framing questions that can bulldozer over the opportunity for participants to express how they truly feel. For example: “Companies are exploring ways to offer workouts you can do at home but have the support of a community. That must make you excited, right?” Asking in this way implies that the participant is already excited. Perhaps they’re not. Guiding questions like this leave little room for interviewees to fully communicate their thoughts, which will alter your data. Sticking to neutral questions like, “what do you think about this?” will eliminate any potential filters that could affect interviewees’ responses.

5. Create a comfortable environment for the users

When people are relaxed, they are more likely to build a greater connection and trust with the interviewer and therefore will be more willing to talk openly and honestly. This type of dynamic delivers the best results in user interviews. A comfortable environment can be created in various ways. Start with unrelated, easy to talk about questions about the interviewee’s daily life, for example, to ease into a natural conversation. Then transition to questions related to obtaining your goal. What are the interviewee’s desires and dislikes about the product design? Next, return to rapport with questions about their interests, hobbies, and demographics. This will lighten the conversation and also provide you with additional context and information to identify any possible patterns that could be useful to consider for your design. 

5. Adapt and be flexible

Not all interviewees are the same, and you shouldn’t treat them as one unit. They are individuals with unique interests and backgrounds, therefore they will likely respond to questions differently during the interview. With that in mind, it’s important to avoid strict scripts when asking questions and adapt to the individual. You may need to alter a question or deliver it in a different way that is compatible with their understanding. They may need additional prompts or explanations. Listen to the interviewee and respond appropriately. It’s also important to note that while it is okay to guide participants, don’t lead or influence them to deliver a certain response. After all, their ability to respond and authentically share their needs, desires, likes and dislikes with you is vital to understanding how to best serve them.

6. Incorporate the results in the product design

The results of the user interviews will inform you if users find your product valuable. By observing the data, you will be able to identify the top priorities and problems that users currently have with your design, and if your product is truly needed. The data will also reveal any competitors. Often users will use other products or companies as references. This is a great opportunity to learn more about the competitors in your field, what they are doing, and how to make your design different. Hearing what users value and find important will also show you if your design truly meets their needs. If not, the data can direct you to other potential uses of your design to better address the user’s wants and needs. 

User interviews are an effective and time-saving tool to adequately understand how users feel, think, and perceive the world. An intimate snapshot of the user’s experience in daily life and how your product design can help them or satisfy their needs is essential to creating a product that truly serves them. No matter where you are in your design process, user interviews are a lucrative asset to creating the best product possible. 

Want to know more about how to implement design thinking?

Voltage Control designs custom engagements for clients, including design thinking workshops, innovation sessions, and Design Sprints. Please reach out to us at info@voltagecontrol.com for a consultation.

The post 6 Steps to Conduct User Interviews appeared first on Voltage Control.

I once took an entrepreneurship course with prominent businessperson Gary Hoover. One evening, the class went to the mall, where we observed different retail spaces and customers. In the end, we shared our observations as a class.

What struck me is how divergent we all were. Hearing what others “saw” versus what I “saw” was fascinating. We were in the same place, supposedly seeing the same thing, and yet we all noted contrasting information and takeaways.

For me, it was an excellent reminder of how important diversity of thought is in design work. Only through this diversity do we gather enough information to paint a more accurate picture of a business challenge.

I think it’s widely accepted that innovators and designers should to talk to a range of users in discovery or design researchto get wide-ranging perspectives on your particular focus area. Even if you are speaking to a relatively “homogenous” group — let’s say you’re talking to luxury travelers; for example — you still want a range of perspectives, whether in race, age, marital status, etc.

“We can be blind to the obvious, and we are also blind to our blindness.” Daniel Kahneman

But, what I don’t think we talk about enough is how helpful and essential it is to have a diverse set of listeners and colleagues taking in these interviews or during meetings we facilitate.

Even when we apply an unbiased approach, we are still bringing our prior experiences, world view, and a unique perspective to the table when we observe things.

You want different people with diverse experiences to come to the table. It’s not about expertise; it’s about different ways of listening, synthesizing, and internalizing information.

Additionally, with more expansive, divergent thinking in the room, it has a ripple effect on the team; it encourages new, unexpected thoughts and solutions from everyone.

Diverse Teams Outperform

There is a ton of data out there that also proves that diverse teams outperform homogeneous ones. The Harvard Business Review article “Why Diverse Teams Are Smarter” cites this study: “A 2015 McKinsey report on 366 public companies found that those in the top quartile for ethnic and racial diversity in management were 35% more likely to have financial returns above their industry mean, and those in the top quartile for gender diversity were 15% more likely to have returns above the industry mean.”

Embrace the “Onlyness”

When we include more people as listeners and participants in design work, we increase the amount of “onlyness” in the room. Nilofer Merchant wrote a book about the concept of “onlyness,” which she describes like this: “Onlyness is that thing that only that one individual can bring to a situation. It includes the journey and passions of each human. Onlyness is fundamentally about honoring each person: first, as we view ourselves and second as we are valued. Each of us is standing in a spot that no one else occupies. That unique point of view is born of our accumulated experience, perspective, and vision. Some of those experiences are not as “perfect,” as we might want, but even those experiences are a source for what you create.”

Increase the nuance

As economist Daniel Kahneman writes in Thinking, Fast and Slow: “We can be blind to the obvious, and we are also blind to our blindness.” We all have our life experiences, skills, and expertise that we bring to the table. This is our strength, but we often aren’t aware of our weaknesses.

We all have some blinders on, but sometimes we aren’t even aware enough to name them. The more observers we have and the more varied their experiences and background, the more nuance we can include in the synthesis of our insights.

For these reasons, I encourage you not only to think about how your participants create a “representative sample” in your next round of user interviews but to consider the perspectives of your listeners and note-takers as well. Or, in your next meeting, bring in people from outside your team to shake up the views and experience in the room.

If we don’t have diversity in our observations, we may miss a critical perspective. With more variety in listeners and team members, you’ll identify key insights and question common assumptions, instead of carrying them into your work.

The post Embracing Observational Diversity appeared first on Voltage Control.

If you have participated in a Design Sprint, I’m sure you can relate to how exhausted you are by Friday at 4:00 pm. The last thing you want to do after that last interview is to start sorting Post-it notes. Well, you’ll be glad to hear that Voltage Control has developed a much better approach. Introducing our 5 Act Interview Scorecard.

You can download the sprint scorecard here, but please read on for detailed instructions of how and why to use it!

Our custom scorecard

The scorecard is a simple concept. Create a shared Google Sheet that all of your interview observers can use to take notes simultaneously. With Google Sheets, you start with digital notes so you don’t have to type up a bunch of handwritten notes later. We assign a worksheet to each sprinter, so everyone has their own workspace, yet we can see each other’s work.

Each sprinter’s worksheet has a column for each tester with rows of questions. During each interview, the sprinter’s job is to answer Yes, No, or ? to each of the questions. While the interviewer won’t ask these questions directly to the tester, they are aware of the questions and will prompt and nudge the tester in order to tease out answers to the question.

Write your sprint questions as Yes/No questions

The questions are derived from the 3–5 Sprint questions that were written on Monday as well as prototype questions. First, we start with the 3–5 Sprint questions and re-write them as Yes/No questions. Often these questions seem OK until you are listening to an interview and realize they are ambiguous. It’s important to be as explicit as possible and even discuss the intent of the questions with the team so everyone is aligned on how to interpret them. I also recommend that you write Yes/No question variants such that Yes would be the desired answer. This consistency helps during scoring and later on when synthesizing the results.

In addition to the Sprint questions, we also include a few questions that we have about the prototype. (Will the user appreciate the case studies? Do users understand that the KPIs are configurable? Do users want the ability to try before they buy?) We recommend limiting your scorecard to 10 questions, including your Sprint questions and prototype questions

Start our Design Sprint course today!

Learn tips and tricks for facilitating a Design Sprint (whether it's your first or 101st) and for incorporating these techniques into normal meetings.

Get Started

The insights section

Below the Y/N questions section is the insights section. This section contains 3 columns:

1. Tester: You can select the name of the tester from a dropdown.
2. Timestamp: Enter the timestamp for the moment when the insight was revealed. Using the CMD + Shift + Semicolon hotkey makes this a breeze.
3. Insight: The insight or tester quote you want to capture. It’s important to only capture the big ideas, ahas, and big concerns. You shouldn’t transcribe the interview; you are recording it after all.

@Pro Tip: Bold quotes so they are easy to locate later.

The graph

The final component to the scorecard is the graph. In the graph tab, you’ll find a bar chart that shows the distribution of answers for all your observers across all testers for each question. This is a great way to see which questioned you got right, which ones need more work, and which ones are inconclusive and need to be studied further. The graph updates in real time and I enjoy keep an eye on it throughout the day to see how it is evolving.

How to Use The Voltage Control Sprint Scorecard

I’m happy to share the official Voltage Control Scorecard so you don’t have to struggle with overwhelming notes like we did at first. The scorecard is simple to configure. Once you open the scorecard, simply make a copy and rename it. Then follow the steps below to set it up for your Sprint.

Setting Up Your Scorecard

1. Click File/Make a copy to create your own version of the scorecard.
2. Open the Inputs sheet.
3. Edit the questions to match your Sprint and Prototype questions.
4. Edit the interview times to match your interview schedule.
5. Edit the tester names to reflect your testers.
6. Hide the Get Inputs sheet.
7. Rename the Sprinter sheets to the names of your team members. Note: We have support for 10 observers. If you don’t have that many feel free to hide those sheets. Do NOT delete them.
8. Share the sheet with your team along with the instructions below on how to use the scorecard.
9. Share the instructions below with your Sprint team.
10. Hide the Get Started sheet.

Using the Scorecard

1. Open your scorecard.
2. Click on the worksheet with your name on it.
3. At the top you’ll see columns for each tester and the rows of Y/N questions.
4. On the bottom, you’ll see an empty section for recording insights.
5. Take a moment to read each of the Y/N questions.
6. While observing the interview, if you can confidently answer any of the Y/N questions with a Yes or No, record your answer. If the tester wasn’t completely clear or said contradictory things, mark that question with a “?” for that question. If the topic didn’t come up at all, leave it empty.
7. When you hear interesting, provocative, or concerning things from the testers, record them in the insights section at the bottom.
8. For each insight, use the drop down to select the current tester’s name, enter the timestamp using the hotkey, and type in the insight.

Remember: don’t transcribe the entire interview! Everything will be recorded anyway.

Tips for capturing insights

1. When you record a quote, put it in bold.
2. If you hear something negative, set the text color to red.
3. If you hear something exciting or super helpful, set the text color to green.

Reading the Scorecard

There is a graph sheet that collects your teams’ collective observations into a simple and easy-to-understand graphic that can be shared and used to reflect on next steps. We also recommend skimming through the insights from your team. Review and sort through the insights, gathering up the big ahas and noting patterns that are consistent across all the interviews. Feed these into your action plan. Also, quotes that have been highlighted are great to include in announcements or updates to the broader team about the Sprint.

I hope that our scorecard helps you as much as it has helped us. We no longer have to sort through heaps of hand written notes or worry about recency bias (i.e. showing preference for the most recent interview versus that one from 6 hours ago.) Instead, all the notes are digital, terse, and organized. We can safely leave them in place, and revisit them when our minds are fresh and we can think about all of the interviews objectively and equally.

The post The Voltage Control Design Sprint Scorecard appeared first on Voltage Control.

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!

Start our Design Thinking Foundations course today!

Learn and practice Design Thinking to help your team solve problems and seize opportunities.

Get Started

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.

The post Mastering the 5 Act User Interview appeared first on Voltage Control.