Don't write interview guides
If you are going to meet with users and do some qualitative research then I expect (hope, even) that you have had it drilled in to you to carefully construct an interview guide. Now, I ask you to remember that lesson, but throw away the interview guide!
The very reason we take the time to go and meet with our users is to learn from them and to discover new insights about their behaviours, needs and desires.
The very concept of an interview guide implies that you are taking the lead and guiding them. Which, in turn, implies that you know what needs to be talked about … so what is the real chance of uncovering new discoveries here?
Thus, of course, you are throwing away the interview guide, not to have nothing, but in order to create something better …
This represents the first, but lesser, of two issues with ‘interview guides’ – it should be more of a conversation than an interview, and it should be about discovering what the person genuinely knows, thinks or feels. Thus, one is searching for spontaneous comments and tidbits, rather than those that come in response to a well-structured question. It is more akin to a Hercule Poirot (or Miss Marple) conversation – aimed to get someone to reveal something without prompting them – or more akin to a pub conversation that might go anywhere than an interview.
Some teachers of user research methods say that you should never talk about yourself, but in conversations, stories need to come equally from both parties – a story shared leads to one returned. Of course, your stories might be rather deliberate (e.g. “I was talking to someone the other day who said that they never customised the interface …”) but they need to be slipped Ito the conversation as and when appropriate.
The bigger issue with a focus on writing the interview guide is that it gets the team immediately focussed on what they want to learn from the people they are meeting, which is usually closely related to the current state of the design and development project. However, the people you are going to meet are not steeped in your design project and the questions you need answered are unlikely to be questions that make sense to them.
So, the solution to this challenge is to change your perspective … The first step is to capture very clearly (and as a team) the looming decisions, or high-cost-of-failure decisions recently taken – these are what needs to be explored with input from your users and other people.
Once you know what decisions you are concerned with, then you can shift to what data (that users might be able to provide) would help you make those decisions, or validate those already taken.
And then finally, you need to make the hardest shift in perspective – what can your users (and other people) tell you, or show you that would enable you discover the data you would like to have? It is very rare that users know the answers to the team’s internal questions, but they can provide stories and experiences and opinions (aka data) that might just enable you to uncover the answers you need.
