Write a Testing Script

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!

Introduce yourself

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.

A 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?

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?

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

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?

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!

Everything above was adapted from Elaina's blog post 'Steal this interview script'.