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!
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.
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.
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.
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.
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.
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.
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.
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.
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.