A while back I clocked up my 1000th interview. This got me thinking how much my approach has evolved over the years.
Interviews with customers / end users of products and services are often the foundation of my research.
In the earliest projects I’d work from a page or two of questions all lined up in advance, in the shape of a ‘script’, or discussion guide. These were questions I’d literally recite to each participant. Sometimes these had been contributed to, signed off by, or even provided by the client.
I’d been told I should ask the same questions to all participants to maintain consistency, but found it awkward to work to the script, and at times like I was only hearing half of the story from the subject.
Over time, I found the questions I asked in response to the answers revealed more than the questions on my script, so I developed a more conversational approach.
Sounds like a convenient way to take the effort and rigour out of the process, but it doesn’t make it any easier.
Whilst interviewing, you’re running a mental cache of what’s been said, where you need to take the conversation, how much time is left etc. …and all the while you’re trying to make the participant feel like the conversation is following natural twists and turns, rather than being steered by you, the interviewer.
There are plenty of techniques to learn in the craft of interviewing; building rapport, non-verbals, open ended questions, asking ‘the 5 whys’, repeating their words etc.
In fact, there’s a great book dedicated to interviewing customers by a cohort of mine, Steve Portigal. Totally recommended for design researchers / UX people.
These techniques, combined with your curiosity will get you so far. …But they are not enough.
When clients ask (and they still do) “So, what are the questions you’ll be asking them” …
When it comes to asking the right questions, there is no substitute for actually wanting to know the answer.
Instead of a script, I agree on a set of objectives with the team. This describes the ground we’d like to cover during the conversations and reads like a list of topics around which we’d like to learn.
Some of these might be framed as questions, but it’s far from being a ‘script’.
As an interviewer, you need to truly understand the context and objectives of your client / project sponsor:
It all starts with a set of questions to which I need the answer in my own head, before I begin planning the interviews…
- Where is the business and product at in the development process?
- Why is this the right time to conduct the study?
- Which aspects stakeholders agree / disagree on?
- What assumptions exist about the market, end user or value of the product to end users?
- How will the client measure market success for the product / service?
- How will the research be used, by whom?
- What design decisions do the team need to make based on the insights you uncover?
- Why are we including these types of participant in the study?
- Which areas does the team have enough insight about already?
This goes beyond the due diligence of taking the brief, scoping the study etc.
It’s a deep understanding of the business, product and design context and should be embedded in your curiosity.
The flow of the conversation and lines of questioning should all come naturally if you’ve built this level of empathy for your client’s position.
In the end it’s about user centred design – The user of the research is your client, so you need to understand your end users’ needs to be able to design the product (interview structure) to give them the best outcomes. In this case, rich and useful insights.