Remember the childhood game of “Telephone”? One person whispers a message into the ear of their friend, and that action is repeated until everyone in attendance has heard and relayed the statement. The last person blurts out to the group what they heard, and, usually, laughter ensues.
Everyone understands why this happens. Translation and less-than-pristine reinterpretation damage the fidelity of the message. There is no copy-and-paste equivalent for verbal storytelling. A photocopy of a photocopy of a photocopy of an image will always render that image indistinguishable from the original.
Unfortunately, the waterfall web design process and “Telephone” are similar, and too much valuable, primary research (in this case stakeholder interviews) ends up being reinterpreted to the point that the original sentiment and answers are lost. The process of conducting and then documenting stakeholder interviews can keep a team at an arm’s length from a project. Instead, place designers and developers closer to the project discovery and research phase. Maintaining the fidelity of the research helps our team craft the best user experience possible. While not everyone has a background in research, anyone can conduct a stakeholder interview.
The barrier to entry might be lower than you think. In the last 12 months, I’ve had to go from interviewer novice to Charlie Rose as the Happy Cog research process was revamped. Being thrown into the deep end of the pool has forced me to recognize quickly some of the more important aspects that make an interview successful. The following tips guide how I plan for and conduct any stakeholder interviews.
(Note: At Happy Cog, we work with our clients to determine what defines a “stakeholder” of the project. Stakeholders may just include the core members of a client team or can extend to content owners, key opinion leaders, potential audience types, users, etc. These interviews tend to take 30 to 60 minutes and are typically conducted by phone. To ensure our interviewee can focus on conducting the interview, a project manager captures notes from the call, and from time to time, we also record interviews.)
The script matters.
“Do you know how to have a conversation? Then you can conduct an interview.”
— Michael Johnson, Design Director at Happy Cog
Having the “gift of gab” doesn’t mean you can skimp on drafting a well-structured script for the interview. A strong interview script works from the general (big-picture project goals) to the specific (role-based concerns regarding features and functionality.) Start with the basics to get the interviewee comfortable. Ask about their role on the project and how they see themselves providing value. Allow interviewees to talk about themselves in their own words. Build confidence in the interviewee that their vision matters, because it does.
Once you outline the easy questions, work backwards. Consider the goals of the project and the goals set forth by the client. What questions will help you learn more about how this interviewee can help articulate the path to success? Always consider the uniqueness of the interviewee’s position and role on the project when deciding appropriate questions.
But, sometimes the script doesn’t matter.
Yes, the script is important, but it shouldn’t be carved out of stone. Just because questions are in a specific order shouldn’t dictate how the interview is conducted. Let the natural flow of the conversation govern the order in which you ask questions. Be cognizant of the topical threads in the answers the interviewee provides; look for the right moments to shift to a question in the script that might keep that narrative thread intact. Mentally check off the questions as you go, ensuring you still cover everything the session demands.
Prepare appropriately. Know who you are interviewing.
Knowing the right way to version the script means the interviewer must do some homework. Set yourself up for success by spending a brief amount of time familiarizing yourself with who you are interviewing and their role. This shouldn’t be a research project unto itself; a quick Google search should suffice. Don’t make the mistake of asking a question that exposes a lack of preparation. The same questions won’t apply to the Dean of the College and a prospective student. Respect the time that the interviewee is providing by making sure you aren’t asking questions that aren’t relevant.
Consider the difference between these two questions:
“What are the most important types of information on yourwebsite.com?”
Versus:
“As the VP of Marketing, how do you use yourwebsite.com to accomplish your team’s goals?”
While the purpose is the same, the second question is much more personable for our fictional VP of Marketing to highlight what types of content are valuable specifically to her and her team. Awkward bulleted-list responses can halt momentum in a productive interview. Avoid the inevitable “umms” found in responses from question #1, and, instead, focus on prompts that will promote free-flowing feedback. Let the interviewee be the storyteller.
Don’t be a robot.
Interviews should be a conversation, not an interrogation. Levity is not a bad thing. The conveyed expression in the interviewer’s voice, the manner in how questions are delivered, how introductions occur and the ice is broken—these all create an “air” enveloping the interview situation. Address this head-on. It starts with the tone in your voice. Keep it happy, upbeat, and generally interested. Let the interviewee know you are a blank slate, ready to learn. Not only does this help establish a more relaxing environment, but it also empowers the interviewee, letting them feel that their input is valuable and that their answers aren’t just checking off a compulsory check box in the project process.
Actually listen.
The best interviews often go completely off-script. Why does this happen? A topic or comment by the interviewee often leads to follow-up questions that can never be predicted. That can only happen if the interviewer is actually listening to the answers and not mentally multitasking. Listen for cues for follow-up questions. Never be afraid to ask “why?” Get comfortable asking for the interviewee to clarify an answer. You should be trying to get the best answers, not just the answers you expect.
Don’t have the last word.
End the interview with some humility. An hour-long conversation can never capture everything that the interviewee can contribute or exhaust their thoughts regarding a project. Quite often, they have more to say. To open a window for this last bit of insight, let the final question be phrased like this:
“What haven’t we asked you today that you think would be valuable for us to know?”
This allows them to shift the conversation to anything they find valuable that hasn’t been addressed yet.
Opt in to being better informed.
“Being able to tailor questions to different stakeholders based on their unique roles and goals gave me firsthand insights that I couldn’t (and didn’t) get from just reading requirements documents.”
–Yesenia Perez-Cruz, Designer at Happy Cog
Being closer to a project’s research phase can be beneficial to the design process. Working in a small(er) agency, UX often falls on the shoulders of more than one person or team. Use this as an advantage. I’ve never heard a designer or developer state “I want to know less about this project.”
Having firsthand exposure to what stakeholders are saying creates less chances for those findings to be watered down. Put an end to whisper-down-the-lane requirements and tactics. Keep what is learned in the interview intact by removing extraneous voices and filters from the process. Consequently, designers and developers can have more of a say in the overall project strategy and design process. Intimacy in the research phase instills project ownership. Ownership is an investment that will manifest itself in the project quality.
Everyone wins.