User interviewing can be a pivotal part of validating a product idea, flow, or feature. Designers and researchers often use 1:1 interviewing to gut check assumptions and to quickly get feedback.
You’ll want to set yourself up for success before even beginning your interviews. Part of that preparation will include writing a script. But what should you include? How should you frame your questions? What kind of instructions do you need to provide if any?
There’s no correct way to write a script. And you may need to tailor different scripts depending on what you’re testing, who you’re testing with, and what industry you’re testing for. It’s always good, however, to start from somewhere. The following is the boilerplate script I use for 1:1 remote user interviews for prototypes. Steal it!
1. Instruct yourself
Scripts aren’t just a list of questions for your user interview, but instructions and an agenda for you and your team. Everyone should be aware of roles, responsibilities, and how the interviews will be conducted. While your team may decide on this in a synchronous conversation, having it written at the beginning of your script is a great way to document your plan and provide insight for others that need context.
For example:
- One person (the facilitator) will ask the questions of the interviewee.
- Another person should take notes (for everyone else).
- Write down anything you think was important.
- Capture exact words but paraphrasing is okay.
- Capture exact quotes from users when possible.
- Capture significant non-verbal reactions, like a very long pause before an answer.
- If you have a feature idea, or insight beyond what the participant said, mark it in your notes as such.
- This person should also be responsible for keeping track of time and notifying the facilitator if they are short on time.
- Try to limit the amount of observers in an interview; it should feel like a 1:1 conversation.
- Have everyone except the facilitator and interviewee turn off their cameras and microphones.
- If needed, notify the interviewee ahead of time that there will be others on the call.
- Ensure that you have screen sharing, recording, captioning, or any other technologies or accommodations ready.
- Try to have a back-up plan if a technology fails on either side. For example, if the interviewee has trouble sharing their screen to test a prototype, in some circumstances the facilitator can attempt to share their screen and “drive” while the interviewee gives feedback.
2. Scope your interview
Product thinking requires some amount of scoping to help frame the constraints of your process. We often use a problem statement in design sprints to help guide our conversations and reign the team in when we’re drifting outside those boundaries. User interviews (which are sometimes a part of a sprint) should also include their own scope. This can come in the form of questions we want to answer. These questions don’t have to be particularly complex or long, but should capture why the team is looking to get user feedback. They also might inform your script as well as broadly target assumptions you’d like to test.
For example:
- Do users want to use technology like a mobile device or iPad to order coffee?
- Do users have access to all the information they need to make a coffee selection?
- Is a user able to use their mobile device to order coffee in less than 5 minutes?
- Is a user able to successfully checkout on their device?
- Do users feel assured that their order was received and that they’ll be able to pick up their order in a timely manner?
3. Prep for your interviewees
After you’ve scheduled your interviews, have your interviewees’ information ready at the bottom of your script document (or linked elsewhere if you prefer). It can be helpful to have these in order of how they appear on your calendar. You can prepare each interviewee section with their name and any other relevant background information for your conversation. This is especially handy when you have back-to-back interviews with little time in between to review the next person. Have your background and prototype questions (detailed later in this post) copied into their individual section so the note-taker can easily write answers underneath.
For example:
Maya Rodriguez, long-time customer, uses mobile ordering
Background questions
// List out background questions
Prototype questions
// List out prototype questions
4. Introduce yourself
We’re finally at the part where you’re talking to an interviewee! Before diving into questions, you’ll want to introduce yourself, your team, and give your interviewee a brief overview of what to expect. If you’re recording the interview, you’ll want their informed consent to do so.
Another caveat is that not all interview topics are benign. You may be talking to people dealing with trauma around your interview topic. It’s important to do the work ahead of time to prepare. This may mean letting the interviewee know they can skip questions or stop the interview at any time without any repercussions (e.g. they’ll still be paid for the interview if they choose to stop it). This also may mean having another person who is trauma-informed facilitate the interview.
For example:
Thank you for taking the time to talk with us today. My name is [your name]. Also on the call with me are [other teammates]. We’re looking to talk to you today about your experience [using x product, feature, etc.]. We’ll also have you interact with a prototype and ask you questions along the way. You’ll be sharing your screen during the prototype portion. This interview will take about [x minutes]. You’re free to skip any questions you don’t want to answer.
Just so you know, this conversation will be kept confidential within this team. It will only be used to help further our design and understanding of this product. With that in mind, would it be OK with you if we record this session for internal use?
5. Kick it off with background questions
A lot of interviews, especially first-round interviews, start off with some background information before getting feedback on a prototype. These questions may be about habits, behaviors, or experiences that are relevant to what you’re testing. There are no specific rules around writing these questions, except to keep them open and conversational. The idea behind keeping these questions open is to sometimes go off-script! Nuance is pivotal in user interviewing; getting someone to tell a story about their experience is much more informative than asking a yes or no question.
For example:
- What’s your experience ordering coffee at Coffee Depot?
- There are a lot of options for ordering coffee. How do you typically go about ordering coffee there?
- What kinds of products do you order on your mobile device if any?
- Do you order coffee from other shops? What was that experience like?
- How long does it typically take for you to order coffee and then pick it up?
- Can you tell me about a time that ordering coffee at Coffee Depot didn’t go as expected? What happened?
- What would be the one thing you wish you could change about ordering coffee at Coffee Depot?
6. Explain the prototype portion
After asking background questions, you can transition into the prototype portion. Before diving into it, you’ll want to give the interview a rundown of what to expect for this portion. This is also a great time to double-check that screen sharing is enabled as well as review your backup plan if technology doesn’t abide (which happens more often than you think). Internally, you may want to have a link to your prototype at the ready for easy copy and pasting.
Another important aspect of this introduction is assuring the interviewee that there are no wrong answers and that honesty is encouraged. Interviewees may feel pressure to give you answers they think you want, but your aim is to create a space that allows for frank reactions and discussion.
For example:
Now, we’ll have you look at a prototype of [x product, feature, etc.]. We’ll ask you questions about it as you interact with it. We’re looking for you to talk about what you see and your initial reactions to it. This is just a prototype, so many things will not work and there will be incorrect data. That is okay! We’re looking to understand how you use [x product] and what questions and/or expectations you might have while interacting with it. You’re not being evaluated; this is not a test and there are no wrong answers. We’re looking to learn from your feedback!
I’ll send you a link in the chat and have you share your screen when you’re ready. You should see [description of what they should immediately see when viewing the link].
To share your screen you’ll need to [explain how to screen share with the video chat client you’re using].
FOR INTERNAL USE: Link to Prototype
7. Guide, don’t lead
Much like your background questions, keep your prototype questions open and conversational. Don’t lead the witness with questions that imply a particular answer. Your interviewee may ask something along the lines of “What would happen if I clicked this button?” and your reply should be something along the lines of “What would you expect to happen?”. This response may be a delightfully annoying refrain throughout the interview, but it will provide you with a wealth of honest user feedback.
Prototype questions can usually be broken down into 2 types:
- Questions that can be asked on any screen
- Questions that are specific to a screen or particular interaction
The below example describes questions that can be asked on any screen, but you may have more that cover granular interactions. It’s helpful to title those sections with the name of the screen. Or better yet, provide a screenshot of the prototype screen in the script section so others on your team have context.
For example:
- Walk me through this screen. Think out loud and explain what you see.
- Tell me what [x] means and what you would use it for. Why?
- What information is missing on this screen? Why?
- What would you do next?
- What do you think will happen when you tap [x]. Why?
8. Wrap up the interview
You did a user interview! Good work! Wrap up can simply be thanking the interviewee for their time and letting them know you’ll follow up with whatever agreed-upon compensation (please compensate your interviewees!) and when they can expect it.
For example:
Thank you so much for taking the time to speak with us today! Your feedback is incredibly helpful and we’ll be using it to make improvements to this experience. I’ll be marking you as complete and you’ll receive your gift card this week. Thanks again!
9. Debrief and synthesize
After your interview, you may be chatting about it with your team or preparing for your next interview. At some point shortly after an interview, synthesize the raw notes into main takeaways. Takeaways may consist of overarching themes or salient quotes. This section can go at the bottom of the individual interviewee’s notes section and serve as a summary to compare all your interviews. You may also want to link to the interview recording here if applicable.
For example:
- Only uses mobile ordering when short on time (especially in the mornings before work).
- Often has the same order every day and wants access to that order easily without having to search.
- Expects that mobile ordering will take the same amount of time if at the front of the line and ordering in-person (i.e. ordering without the wait).
- The checkout button wasn’t apparent on the first few screens and user only interacted with it after a bit of searching.
- “I’m done with my order but I’m unsure where to go next!”
- Countdown clocks aid in user assurance with their order.
- “I really like the countdown clock after I submit my order. It’s nice to have a timestamp of when my coffee will be ready.”
