Sometimes when we have a poor interview, we blame the person we’ve interviewed. That person might be a design stakeholder or current or potential customer. You might be conducting behavioral or stakeholder interviews or running usability test sessions. The interviews may have been at participants’ offices or homes, in your offices, or in the field. Regardless of the situation, you may be tempted to label a participant unengaged, inappropriate, inarticulate, or worse. But there is one constant in all of these different interview scenarios: you.
Bad interviews can result in missing data, incomplete detail, misleading results, partial insights, and lost opportunities. Your reports, presentations, and recommendations document what you’ve learned from your research and the decisions you’ve made based on it, so you need to ensure your research is the best it can be—that you get good interviews.
What a Good Interview Sounds Like
NPR, a public radio station in the United States, shared an interview they thought was so bad it was comical, on their Bryant Park Project YouTube channel. The interview was with the popular Icelandic band Sigur Ros. Watch the footage in Figure 1 and consider what went wrong.
What NPR thought went wrong was Sigur Ros. In their description of this YouTube video, they claimed the band gave the worst interview in the history of electronic media and suggested you never invite them to an interview. But the interviewer broke nearly every rule in the book by
- posing hard questions first
- asking closed questions
- overloading questions
- asking boring questions
- answering his own questions
- posing questions in a random sequence
- doing little followup on responses
- using negative body language
- failing to build rapport
In some cases, your research participants can feel like the proverbial stone from which you’re trying to draw blood. So what constitutes a good interview? In his book Interviews: An Introduction to Qualitative Research Interviewing, Steinar Kvale outlines some criteria for evaluating an interview:
- To what extent are the participant’s answers spontaneous, rich, specific, and relevant?
- Are the interviewer’s questions shorter and the participant’s answers longer? The longer, the better.
- What is the degree to which the interviewer follows up and clarifies the meanings of relevant aspects of the participant’s answers?
- Did the interviewer interpret the meaning of the participant’s answers throughout the interview? Ideally, this should occur to a large extent.
- Did the interviewer attempt to verify his or her interpretations of the participant’s answers during the course of the interview?
- Was the interview self-communicating? Did it communicate a self-contained story that requires hardly any additional description or explanation?
These criteria relate to characteristics of both the interviewer and the research participant, so let’s consider what is within your control, as an interviewer, to make an interview successful—regardless of whether your interview is with stakeholders or users.
Preparation is key to ensuring that, when you sit down with that complete stranger, you know exactly what you need to get out of the conversation.
Immersing Yourself in the Problem Space
To design appropriate research and tease out new insights, you need to understand the status quo and a project’s goals. You can think of this as validating what you know you know, recognizing what you actually know, and becoming aware of what you don’t know. This starts with fully understanding a project’s context by building domain knowledge and being crystal clear about why there is a need to do research and how the results will inform the project. However, this is not about becoming an expert in the subject matter you’re investigating. Instead, it’s about getting familiar with the boundaries or frameworks within which to explore the subject matter.
Domain knowledge includes the product, Web site, or system; the industry basics; a product’s business goals and value proposition; industry jargon; competitor offerings; the product’s past success and failures; and previous research findings. Amassing this knowledge equips you to write an appropriate interview script, gain insights during the interviews, and be nimble with your questioning.
Your immersion in a domain extends to understanding the design context. You don’t want your interviews to focus on solving design problems others have already solved. Nor should you ask questions about issues that widely reported industry research has fully explored. Instead, investigate how others have tackled the same design challenges by building functional knowledge. Become familiar with best practices and alternative approaches.
Functional knowledge includes concepts, interactions, processes, vocabulary, taxonomies, and design patterns. Securing functional knowledge helps you to ascertain where to probe further when getting feedback on a user interface, as well as recognize what is trivial and not worth discussing, because tried-and-true solutions apply.
Through your full immersion in relevant domain and functional knowledge, you can confidently develop a set of research questions that can help you find the answers to what you and the project team really don’t know, providing enormous value and, hopefully, learnings that are of genuine interest.
Getting Access to the Right People
Finding people who have sufficient knowledge, experience, and interest can be difficult, especially for stakeholder interviews. You may have to think beyond the organizational chart and an organization’s usual relationships to get truly useful interviews. Staff who interact with the most departments, who come into contact with people of varying levels of seniority, and who their colleagues listen to and respect are often gold mines of information.
Once you know who you’ll be talking to, make sure they know what the interview is going to be like, so they’ll be in the right head space when you meet. If you’ve ever had a job interview or prepared a presentation you thought would follow one format, but was actually in another, you know this can be very disconcerting. Your anxiety level immediately goes up, making it harder to communicate confidently. This is equally true for both stakeholder and user interviews. You also want to avoid situations where a stakeholder answers every question by saying, “I’ll have to find out for you / follow up on that with you / run a report to find out.” Often such supplementary information never materializes.
You can prevent these kinds of scenarios through some clear and timely communication. Set the right expectations for the people you’ll interview by letting them know in advance what participating in your study will be like and about any priming activities you’d like them to do. Don’t leave it to a participant recruitment firm or your client to craft this message for you. Supply the copy yourself.
Finally, plan your interview schedule to ensure an even exposure to different participant types. Mix up experts, intermediates, and novices or participants from different market segments or business units, so you’ll hear a broad set of perspectives each day during your study. Ensuring this breadth is especially important if you’re reporting observations during the research or iterating designs between sessions. You don’t want to report skewed results or modify your design inappropriately as a result of participant-type bias.
Setting the Stage
Both the settings in which you conduct interviews and your presentation as an interviewer influence the way interviews proceed and the results of your research.
Ideally, select a meeting place that has some relevance to a research topic or participant. This gives a greater sense of context and make participants more relaxed and open. The environment needs to be conducive to chatting intimately, so consider its physical layout, ambience, potential distractions, and the social warmth of the room. If you’re in a lab setting, get any mirrors, video and audio equipment, and in-room observers out of a participant’s field of vision.
You also need to craft your own presence by planning your attire. Here your aim is to make yourself credible and participants comfortable. It might be necessary to imitate your participants’ dress code. It’s also worth thinking about any accessories you’re wearing that might indicate hierarchy, status, or belief. You don’t want participants to have their defenses up in reaction to a religious or political statement.
Deciding on Your Script’s Structure and Scope
Once you’ve determined who you’re meeting with and the meeting setting, it’s time to turn your attention to what you’ll talk about.
Depending on who your research participants are, a one-size-fits-all interview script or moderator’s guide might not be appropriate. If you’re interviewing stakeholders from business units whose terminology, culture, level of interest, responsibility, or key performance indicators are different, write different versions of your script. In such a situation, you might tailor your questions to reflect their subject-matter expertise, touchpoints with design, or their relationship to a project or client. This can be especially useful if a project might potentially be besieged by internal politics. Alternative scripts can help you uncover and tackle the long-held assumptions, fiefdoms, and decision-making power that emerge when new knowledge threatens the status quo.
In a user interview, you can use conditional and branching questions to cover a multiplicity of possible scenarios. Since you are unlikely to have much information about participants up front, ask questions early in the interview that can reveal what line of questioning you should take for the rest of the session.