Make an interview plan
Before you conduct your interview, you should have at least a rough idea of why you’re doing it: what do you want to learn about your users and your product? I write down a few questions that I can use as a checklist, so that I don’t have to worry about remembering everything I want to ask while I’m conducting the interview. Thinking about what to ask can be really difficult, but I find it helps to start by just listing some features. This will help to put you in the mind of your users. What are your users trying to do? How will they try and go about it? Will they use different features together?
Try not to make your plan too rigid. I’ve found that questions act more as jumping-off points than something to be answered directly. Your interviewee might go off on a tangent about why they do something in a particular way, and this is where you’re going to learn new things.
If you are taking lots of notes during the interview, you might make your user feel uncomfortable, like they are a specimen under a microscope, or being grilled for a job interview. Additionally, you’re not going to capture all of the detail that you’ll need when you come to do your analysis later. In particular, it’s hard to capture all of the body language and nuances in how people speak, and these cues can be really valuable. Do people feel delighted when they are using your product, do they find certain features frustrating or confusing? You can capture all of this by recording a video of your interview, and watching people’s expressions as they use your product. Also, if you record the audio then you don’t have to write down their responses, you’ll have a full recording of everything you both said. This keeps the interview conversational, and maintaining that flow will keep you both relaxed and ensure you get the most out of the interview.
If possible, you should also record your user’s screen, so you have a reference for everything they did during the interview. If you record the screen and the interview, you probably won’t need to take any notes. You can make GIFs from the screen capture – which is great for demonstrating your findings to other people –, and it’s another way to find aspects of your UX that are particularly easy or difficult.
For conducting remote user interviews, I recommend Skype, because you can get a high-quality recording of the screen and interview very easily, and it works across Windows, macOS and Linux!
The only caveat here is that you must not record the interview without the interviewee’s express permission. Before the interview, tell your user you’d like to record your conversation and their screen, so that you can use it as a reference while you build your research. Some people will not want to be recorded, and we have to respect their wishes, even though it makes our job harder.
Keep it short(-ish)
I aim to make my interviews take 30 minutes. I keep 2 to 5 minutes at the beginning and the end so we can break the ice, and provide an opportunity for the user to ask any questions or show me anything that we haven’t discussed. This leaves 20 to 25 minutes for the bulk of the interview. This might not sound like much, but when you’re talking and demonstrating in-product you’d be amazed how much you can cover! Sometimes an interview will run short, or there might be much more to talk about and it can spill over, but 30 minutes is a good target to aim for. People will be more apprehensive to agree to a longer interview, and both you and your user can get tired, and then you won’t be gaining as much from the discussion, at worst you could annoy your interviewee! Also consider that you have to sit down and analyse the interview, and this is the most time-consuming part of the process.
Let the user lead
Ask open questions, and encourage your user to show you real examples of how they use your product. You might have very specific questions you want to answer, but if you ask yes/no questions then you’re not going to learn as much as you could, and you might even be leading your user into an opinion that doesn’t reflect the full reality of how they feel about your product. Encourage your interviewee to tell you stories, show you things they’ve made, and demonstrate how they use features.
Users and products don’t exist in isolation. People will be using your product for a reason, they might be using it in certain places or at certain times in the day or week, and they will often use it in tandem with other products built by other people. In our last interview
, Elle detailed a workflow that involved pencil and paper and Adobe Photoshop in addition to the digital painting application Sketchable which was the focus of our interview, and we also discussed the hardware she uses. If you feel like your at the end of a workflow, ask the user what they might do next, or if they would have another app open, or what might be on their desk! There is incredible opportunity for development at the periphery.
Transcribing your interview isn’t strictly necessary, but I think it’s a good discipline to try at least once or twice. For starters, it forces you to go through the whole interview again, and really pay attention to what your user is saying. If you just watch the interview and scrub through looking for gems, the odds are that you will miss something useful. It’s also a great resource to have in your collection of data because you can search plain text very easily. If you want to refer back to something later, you can just search for keywords in the transcript. And, if you have gathered a few transcripts, you can conduct keyword analysis to see if there are any common themes.