Using a customer research script for user interviews is the best way to ensure quality research outcomes.
Customer interview scripts, or conversation guides help to:
Here’s a quick teardown of a script I’ve been using for research into how user researchers & product designers leverage research for our own product Great Question.
It’s very meta.
This is a solid base for team relatively new to user interviews, particularly those building B2B SaaS products, but there’s likely useful ideas in here for anyone doing user research.
Scroll to the end if you want to download the script in its entirety.
Don’t let the script stop you from exploring any topics or questions that might come up; often the golden insights come out from these tangents.
Just make sure you come back to the script questions so you get answers to all of your questions.
2. Notes or it didn’t happen.
At the end of the interview tag up all of the answers so you can reference them later.
I’ve used a spreadsheet with a row for each question in the past, I've seen folks use an extended Google Doc, and I’ve also used custom UX repositories like Dovetail too.
Whatever works for you
The first few minutes of your interview are critical to set the scene, and make your interviewee feel comfortable.
You want to make it personable. Who are you and why should I be talking to you?
First of all thanks for taking the time to talk to us.
As background I’m a software engineer & entrepreneur, having sold my last company to GoDaddy and currently advising other companies on building scaleable products.
Tell them what you’re going to do up front .
The start of an interview can feel quite vague.
“Why are you asking me about this stuff? I thought we were going to talk about your product?”
I’m now trying to scratch our own itch by making it easier for folks who build product to get closer to their customers & do better quality customer research.
Today we have a series of questions to better understand you, the work you do, and what role research takes in your organization. We’re going to start fairly broad and get more targeted as we go.
The payoff for the interview will come at the end if they just stick it out. Sign posting that you're going to tell them more about what you're building at the end reduces the risk that they'll ask you too many questions up front, which risks clouding their answers.
Finally we’ll finish off by giving you a brief outline of what the product actually does to see how it resonates.
Make it clear that this is a research call, not a sales call. No one wants to feel like they’re on a sales call where anything they say in the affirmative might be used against them.
Before we start we have two pieces of house keeping.
The first is that we’re not trying to sell you anything. We just want your open and honest experiences and opinions to help us understand if there is a need for a product like this in the market.
Recording the interview means you can play it back for your own recollection, and to share with your team. You’ll surprise yourself how often you can misinterpret a customers comments.
Recording isn’t always the right path - sometimes folks won’t open up as much if they know they’re being recorded - but should be a default where possible.
The second is that we’d like to record this call so we can focus on what you’re saying and take our notes formally later. Do you mind if we record?
To get started can you tell us about yourself, ‘company_name’ and your role as a ‘title’?
What made you want to join ‘company’? What did you do before this?
From a practical perspective this is helpful for identifying the customer if you’re doing a lot of interviews, but it also helps to understand the individual - their seniority & their motivations.
I tag each participant by this demographic data so I can cut up the results later to identify trends between types of participants.
Can you tell me about the work you’re doing - maybe some of the projects you’re working on, your goals for the quarter, and the challenges you’re facing or trying to solve?
We want to get a sense of a day in the life of the interviewee. What’s driving them? Who are they working with? What problems are they solving? These questions will help us to do call-backs later in the interview that a) affirm you’ve been actively listening and b) ground your questions on their lived experience vs hypotheticals.
What kinds of user research do you do at ‘company’?
We now want to frame the conversation based on what we’re trying to learn with our interviews. For us this is about user research so we want to first understand what activities they’re already doing here.
What gets in the way of doing great research?
“What gets in the way of doing great X” is a setup I’ve used multiple times across a range of products.
It’s probably not a question they’ve been asked lately, and perhaps haven’t thought about before so it often breaks them out of any rote responses they’ve been giving you so far.
You want to get a better sense of what they’re proud of. You might find that they’re doing everything to industry best practices - and you might learn a trick or two.
What do you think you could improve in terms of your user research processes?
How conscious are they of their own weaknesses? Ultimately this question helps to identify problems that your product might be able to help solve.
How do you find candidates to speak to?
This question is potentially overly specific but talks to a series of questions you might ask about the customers work flow. How do they do X, how do they do Y? What problems get in the way of them doing this?
What tools do you use for user research?
What products might you need to integrate with? What things might you replace for the customer?
Looking at my notes you’ve listed a bunch of challenges you’re up against:
Did I miss any challenges you’ve mentioned or are experiencing?
Would you mind stack ranking these for me? What are the most important ones for you to solve?
This is the most pivotal question of any interview. You’ve unearthed a range of problems the customer experiences, but getting them to prioritize these is invaluable. If the problems you’re trying to solve with your product isn’t in the top 3 problem set than you might not be building something people want - or at least not this person / persona.
However if the problem you’re solving is in their top 1-3 problems to solve, you can dive deeper again.
OK so making user research operations more self-serve and scaleable for your product teams is your 2nd biggest pain point. How likely are you to solve that this quarter?
How do you plan to solve this problem?
Who else will be involved in helping you fix this?
Do you have a budget allocated to solve it?
These questions are variations on the question of how high a priority the problem is to solve. We then go further to understand how they might solve the problem - which reveals where they might search for a solution and could aid our marketing; and whether there is budget allocated that could be spent on our solution.
This has been incredibly valuable - thank you!
Now we’d like to tell you a little about the product we’re building to see how it resonates with you.
We’re building a product to help ‘customer_type’ solve ‘big_hairy_problem’
We help you ‘product_benefits’, by ‘product_features’.
How does this product resonate with you? How would something like this fit into your user research practice?
This pitch is less about selling the customer, more to see how your solution fits into their world view. I always take any reactions here with a grain of salt - unless they’re keen to trial or use the product.
“Sounds awesome!” is a common refrain, but unless the credit card is coming out I chalk this up to a polite reaction.
Thanks for taking the time to talk to us, I think we have plenty to go on.
Two last questions for you: We’d love to keep in touch to get your feedback on our prototypes as we incorporate feedback from product folks like yourself. Do you mind if we send you the odd question via email?
It’s nice to get an opt in for future research. If you have a product you can show them you might ask if you can do a demo and setup time for a future meeting.
The second is we’re wondering if there is anyone else you think we should be talking to? We’re less looking for introductions than an insight into the types of people and companies you think could provide some insight into their user research process.
In our case we started talking to product designers, who were awesome but often not responsible for research tooling. They quickly lead us to “you should talk to our product manager / research lead” which was valuable to focus our outreach efforts, and lead to some warm introductions too.
So that’s our anatomy of a customer interview script. Click here to download a copy for yourself to use / edit etc.
And if you found it helpful at all, or even want me to take a look at your script, fill out this form and we can review together.