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.

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.

Example background questions:

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

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.

Example questions for any screen:

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