Conduct user interviews

It's finally time! We're going to put all of your ideas, fears and questions to the test. Over the years we've learned lots about what makes interviews a success. It would be easy to think that this is the simplest step of the sprint process, but there is lots of things to consider before diving in. Here are some best practices.

Before the Interview

We find that good preparation can make all the difference between good and not so good interviews, here are some tips to make sure you are prepared.

Instruct yourself

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.

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?

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.

During the interview

Here are a few things to keep in mind during your interviews to help you facilitate better interviews.

The script is more what you call guidelines, than actual rules

While it is important to develop a script beforehand that will dig into the assumptions you’re making about the product’s design, following it in the order that it is authored isn’t a hard and fast rule.

The interview is a conversation, and conversations are fluid things. Trying to force the interview so as to better check off your talking points in the order you authored then beforehand may make things feel artificial and forced. It’s better to memorize your agenda and only reference it for talking points if you need to.

Small talk can be big

Ask them how their day is going, or what the weather is like.

Not only will it help the person being interviewed feel more comfortable, it may segue into topics covered in your script. If you’re free to approach the script more conversationally, you might be able to check some topics off before you even get to the prototype.

For one client, learning about one participant’s background gave us insight into a high impact portion of the product that made assumptions about circumstances that would have otherwise not have been uncovered. This allowed us to make adjustments that would preemptively address issues about a potentially very sensitive topic area.

Don’t be afraid of uncomfortable silences

Interviews are conducted to get insights. To get insights, you need to get people talking. While it helps to have a friendly and approachable demeanor, sometimes that means staying mute until they fill the void with chatter. It’s an old psychologist’s trick, but it’s a good one.

That doesn't mean being completely silent for the entire process. You should answer questions if prompted, and should chime in from time to time to prompt or nudge them along. However, you also need to let your new friend squirm through uncomfortable things and resist the very real urge to help them out.

Pump the brakes

One of the times it is appropriate to speak up is when the participant is blowing through a prototype and not saying anything. While it’s great that things are working well enough that the participant can navigate with little effort, the problem is it’s working a little too well.

If they’re not talking about their experience as they go, it’s not a very helpful session. Positive interaction can be just as important as negative, but without the details of what they like and why articulated, it’s difficult to then later quantify this without guessing intent.

Don’t be afraid to walk a participant back and prompt them to explain themselves. A quick, neutral question can be great for getting the conversation flowing (“I noticed you chose X right away. Why’d you go with it?”).

You don’t have to look smart

Trying to demonstrate to the participant that you know your stuff might not work out as well as you think it will. Lording your expertise over the participant may be interpreted by the participant as their opinions not being worthwhile—the exact opposite of what you want.

Try to stick to neutral questions asked in plain language. It can be helpful to do your homework and know what industry jargon means beforehand, but getting the participant to explain what the terms means to them to an outsider can oftentimes lead to important revelations.

Be mindful of the Hawthorne effect

Conducting user interviews is important, in that it helps uncover otherwise unvoiced motivations, frustrations, desires, and needs. That being said, it is very easy for a whole host of biases to worm their way into the process.

One bias to specifically address is the Hawthorne effect. It occurs when “individuals modify an aspect of their behavior in response to their awareness of being observed.” It permeates the entire user interview process.

Most user interview participants will probably want to give you what they perceive as the “correct” answer—the answer they think you want to hear, even if isn’t personally what they are feeling. This occurs even if you tell them not to be concerned about it. While things like analytics and A/B testing can combat this phenomenon, you have to be sneaky to address it during a user interview.

Use a head fake: ask the participant to complete one task, but make sure that the task’s completion flow covers the thing you actually want feedback on. It’s a little bit devious, but ultimately a victimless crime.

A practical example: Let’s say we want to test the effectiveness of the redesign of a product customization feature. Ask the participant to complete a checkout flow, making sure the redesigned product customization screens are included as part of the session. This way you’ll get your participants interacting with the thing you want to test, with less concern that they’ll be giving you the answer they think you want to hear about the thing you actually care about.

Introverts are people too

The final piece of advice is to remember that while it may be easier to talk with a participant who is outgoing and charismatic, you need to not disproportionately weigh that feedback when compared to the points raised by quieter individuals.

The observations voiced by introverted and introspective participants are just as valid as their more gregarious peers, they just may be communicated in a less outwardly excitable way. It’s your responsibility to determine what feedback is worth integrating into the product during the synthesization process, regardless of how that feedback was expressed.

User interviews, when conducted with care and discretion, are great to help shape your product into something people find desirable and meaningful. Hopefully these tips can help your next interview session be the best it can be!


This guide has been adapted from Elaina's post 'Steal this interview script', and Eric's post 'How to Lead Better User Interviews'.