Stakeholders, simply put, are those who have a stake in the success of your research and in the end result. What you do matters to them, and what they think of your work certainly matters to you. In order to do your job well, you need to know what they know, and you need to know what they want or need to know in order to execute a successful build. For all these reasons, it’s essential to communicate early and often.
This is where stakeholder interviews come in. We recommend a process that is a bit more formal than just calling somebody up for a chat, but the heart of the matter is just a few good conversations away.
A successful UX design is dependent upon stakeholder involvement. Stakeholders will provide most of the detailed information you need to set the parameters of your work. There’s almost never a reason not to conduct this sort of interview. Even when you work closely and regularly with the big decision makers, you’ll still need to sit down with them to understand their goals for any given project. If your project has stakeholders who aren't on your immediate product development team, you’ll need to conduct stakeholder interviews with them as well. It’s the best way to gather valuable information about your project parameters.
Stakeholders largely get to define the success of your project. If you build a great product that in the end isn’t what your users or stakeholders want, it is not a success. It’s a failure. Initial project briefs are likely to include ambiguity that could lead to misunderstandings. Extended discussions eliminate ambiguities and can help you update project goals.
It is not uncommon for stakeholders to have project requirements in mind that they don't vocalize or put in initial scope documents, either because people wrongly assume them to be obvious, or because they are actually not consciously aware of them. As with user interviews, stakeholder interviews help tease out all such unmentioned goals.
Stakeholders are the people who get to define your project's success. If you’re hired to build a widget, and you built a wadget instead, your project has failed—even if it’s a really super great wadget. Your stakeholders needed a widget, and early and consistent communication with these stakeholders ensures your project will stay on its widgety track.
Likewise, you're essential to helping define what the product will become. Stakeholders will help to make the product successful but you’re part of defining what it is. They might have started a widget conversation, but if you discover that what users really want is a wadget, and that a wadget better meets the business goals, you can help reshape the project throughout the course of stakeholder interviewing.
Conversation provides for a sussing-out of details. Good interviews can illuminate nuance that might otherwise stay under lock and key.
We spoke with Zach Lamm, Senior User Researcher at SoFi, about his process for stakeholder interviews. He highlighted three key questions you can use in your stakeholder interviews to get to the heart of the problem you’re trying to solve:
Using these questions as a base can help you have similar conversations with multiple stakeholders, so you understand where everyone stands.
Product decisions makers by and large, understand the need that your product must fill. In many cases, they will understand the nuances better than you do. On the other hand, it's your job to identify user goals that internal stakeholders may not be focused on. Stakeholder interviews can help identify what will make a product a success from the business side, and what's possible. In many cases, the success of a project depends on your ability to adapt your expertise to the needs and interests of internal decision makers and stakeholders.
What is the vision? What is the need? What are the parameters? What will get in the way of how other people might sell or market the product? What can your stakeholders tell you about the circumstances under which your product will be used and who might use it? What information can they actually act on when you provide it?
Likewise, and almost more importantly, what do they not know about the users’ needs? What are some assumptions they’re making about what users might want? You may need to dig since people don't always know or want to admit their own assumptions. You want to test these assumptions in your research.
Before you talk to users, stakeholders can give you the initial lay of the land that will allow you to use other methods effectively. Chances are, they’ve already done significant research, and possess a knowledge base that can save time and money all around.
Earning the trust of your stakeholders is always important. When we talked to Holly Hester-Reilly, a research consultant and founder of H2R Product Science, she identified the most important people to talk to and build trust with during stakeholder interviews:
“You want to have anybody who's actually gonna be working on the product whether they're designers or engineers or product managers but people who are going to be making day to day decisions based off of this.
Then you want to have the leadership of the projects. So, the people who are gonna be influencing decisions that are made, maybe making calls on investment into it, who are going to be setting the vision and helping to synthesize the results.
And then you want to have anybody who could basically stop what's going on. So anybody who has enough accountability for what's happening here and enough influence that if they didn't believe what you were doing was worthwhile they could make it all change.
Whenever possible you want to get all three of those groups of people to come and be a part of what you're going to do, what problem you're solving, why you're doing it, what's important, what are the concerns and questions you might have right from the start.”
Collaborative work makes earning trust especially important; if something is wrong with the user experience, those problems will reflect quickly and publicly on the stakeholders. They have to trust that you will meet the project objectives properly. Future problem-solving becomes easier when there’s trust and communication built-in from the get-go. It’s less likely to end with a finger-pointing blame-game when everyone feels like they’re standing on the same side. Conducting stakeholder interviews early with key players helps everyone feel like they’ve had input on the project.
Stakeholder interviews are mutually beneficial: They’re valuable to you and also to the interviewees, as speaking with stakeholders helps people feel involved, and like part of the team. It can even help to clarify their own thinking. Stakeholder interviews establish or sustain relationships, so that later, if things don’t go as planned, the lines of communication are open.
One team forcing its will against another team’s will is a great way to end up with a product no one is happy with. We’re deep in the moment of the user. User needs dictate what and how we build and design, and it should follow that all teams and stakeholders are aligned around one reality: The users’ reality. Stakeholder interviews keep this focus in mind for an end-product that’s what everyone wants it to be.
Stakeholder interviews are an important tool in the early stages of product development when you’re trying to define your objectives and your game plan. But that’s not the only time they can be used. You can check in with your stakeholders at least once during each phase of the cycle to keep everybody on the same page, to make sure you are on the right track, and to gather any additional information or generate any new ideas the project may need.
Stakeholder interviews, by nature, will be slightly more come-as-you are and casual than interviews with external research participants. You work with these people. Chances are, you’ve seen one or two of them behave badly at a holiday party. Still, if you apply the basic guidelines of interviewing to these chats, even when you’re best-office-buds with the stakeholder in question, your research will be tighter and more useful. First plan, then interview, then document and analyze.
Identifying research goals means figuring out what information you want to get. In stakeholder interviews, this largely means getting clear on what you’re asking for, and what you hope to learn from them. You can write this as a script, a few key questions, or just topics to cover and this will serve as your abbreviated moderator guide. The essential question, which we’ve borrowed from Michael Margolis at Google Ventures, is: “What would need to be true for this to be successful?”
Some other considerations:
Stakeholders are generally people who have a high investment in the product you’re working on—financially, professionally, emotionally, and otherwise. They might be as invested in its success as you are. They would be vulnerable if the project were to bomb. Regardless of seniority anyone with special insight into what your product needs to be and do in order to succeed can be a stakeholder.
Be prepared for the possibility that you could have hidden stakeholders, people whose input and approval you need but whose relevance isn't obvious. Such people may have a modest title that belies their true importance to the process, or they may be typically silent partners who can weigh in heavily if they so choose. The more enmeshed you are in an organization, the more clear it will be who your stakeholders are. Rely on your team’s management or folks with greater institutional knowledge to help you find the right list. Pay attention in all your interactions to who seems to actually have influence and knowledge, then add them to your list. Use those ethnography skills.
Some good rules of thumb for identifying your key candidates are looking for:
It’s likely you’ll find these people on the business end of things, engineering teams, and teams where people are acquainted with your UX process. If there are so many stakeholders that you cannot talk to everybody, choose team members or leaders who will best represent a variety of points of view rooted in awareness of your customers and business goals in some way.
Once you know the scope of your interview process, you can finalize how much time you’ll spend on interviews. Do you want to spend a few days on this work? Or do you have the luxury of time? In most cases, even far flung interviewees can be contacted on phone or video. If travel is required, make sure to work into your timeline and budget.
Next, decide who will do what, and how. Depending on the scope of the project, you may need things like recording equipment, or you may need to make travel arrangements. In most cases, you’ll just want to conduct yourself professionally and show up in the interview space with all the things you’ll need.
Some considerations:
Finally, schedule the interviews themselves. If you can, condense your interview schedule over a short period of time. You’ll build momentum, avoid context switching, and free your time up to work on the other aspects of your project with as much information at hand as possible.
Send each interviewee a list of the questions you intend to ask so they can get their thoughts in order before the interview. This will save both you and them time. Also, some projects can be sensitive. If someone is already feeling defensive, getting the questions in ahead of time could help them not to feel ambushed.
Keep it natural. You should be able to respond to the questions, comments, and concerns of your interviewee freely, both so that you don't sound like a robot, and so that your colleague is free to give you information you didn't know you needed. You may want to use the template for user interviews in our launch kit to help guide your conversations and organize your thoughts.
A single question can easily trigger an entire discussion, and you don’t want the interview to last for hours. Come back to your key interview goals when things go off track.
Even if you think the interviewee already knows who you are and why you’re there. State your purpose. Most interviewees already have a sense of what’s happening, but some may not. For example, an interviewee's supervisor may have told them to talk to you, but not explained why. Or, if you’re interviewing someone your job requires you speak with on a regular basis, they may think you’re meeting for some other reason. Putting an introduction in helps to create clarity of purpose.
Some additional samples to get you started:
You will also likely have more specific questions, depending on your interviewee's role. For example, while talking to someone in marketing, you might talk about the company's branding and how the product you’re developing should support that identity. Someone in sales might be best equipped to help you begin to understand how the end user thinks, while someone from engineering would be able to tell you about the existing systems that your product must integrate with or replace.
Be polite, personable, observant. Pay attention: It's not unusual for interviewees to casually drop some interesting and important information when they are literally on their way out the door. And watch those non-verbal cues too.
Some people don’t want to talk. It’s your job as an interviewer to gently draw them out. Some people love to talk, and you’ll have to manage them by managing time and by diplomatically bringing things back to topic.
Stakeholder interviews are not a set-it-and-forget-it kind of thing. You’ll have project milestones, and each milestone should include another phase of stakeholder communication. These stages may be less intense than the initial round. You could even gather stakeholders together in one room, at one time, periodically. However you manage it, don’t make the mistake of interviewing your colleagues once and then disappearing.
This speaks to keeping communication open throughout. Is everyone still pointed in the same direction at all times? Have other factors come up for other stakeholders that have changed their goals or perceptions of the project? When these things come up, as the person in charge of research, you’ll want to know in order to make sure all stakeholders are still as aligned as possible toward the business goals for the project.
Companies reorganize, people take on new and unrelated projects, budgets are rearranged. Priorities change, especially over the course of longer projects. Constant contact with stakeholders throughout will ensure that you don’t miss important shifts that could affect your project.
If you take notes (or have someone else take notes) during your interview, be sure the notes are transcribed promptly.
Just as with user research, the records of your interviews are data, and they’re not of much use until they’ve been analyzed. You or someone on your team must examine your raw interview data—both from each interview individually and from all the interviews collectively—to figure out what you’ve learned.
Some interviewees are quite compelling, either because they have extra strong opinions or because they’re especially charming or otherwise deeply engaging. You might be tempted to make decisions on this one person’s feedback. But be sure to review all of your data before your decision-making is swayed. The loudest person isn’t always the one who best represents the needs of the whole.
Consider writing up a formal report that summarizes each interview. Your objective is for anyone on your project team, even those who never spoke to any of the interviewees, to have full access to everything the interviews have taught you efficiently. If there’s sensitive information that shouldn’t be shared with everyone, be prudent. The key thing is to identify patterns in feedback from participant to participant.
As useful as stakeholder interviews are, they come with their own challenges. Most obviously, the entire process takes time—potentially a lot of time. You can usually manage the challenge simply by structuring your project's schedule such that you only do X amount of interviews over Y amount of time. Boundaries! There may be projects where it makes sense to partially curtail the interview process in order to finish in a timely manner, or combine interviews.
Some stakeholders love to be consulted, but others prefer not to think about the thing you’ll need to ask. You will have to gauge their interest in participation so that you don't ask too much of them. A related issue is that some stakeholders might see your questions as evidence that you don't know what you're doing. Making sure that your interviews are well-organized and professionally conducted will help.
Occasionally, you may hear concerns that you cannot resolve or receive information you simply can’t put to use in the context of your project. Asking for input and then appearing to ignore it can scuttle your relationship with your clients or colleagues. The solution here is simple: more communication. If a stakeholder asks for something you can't honor, say so, and be sure to explain why. If you aren’t sure, let the user data come in, then explain why you reached the conclusions you did.
After your interviews are planned, prepared for, documented, and analyzed, you will still face the necessity of doing something useful with what you have learned. In the sometimes hectic process of trying to develop your product, the temptation is all too real to place your documentation and your reports in a file somewhere and forget about them. Include your findings in the folder, website, wiki, or whatever system you use to organize your research and document how they will drive your research as well. If you need some tips on putting together research reports that stick, check out these tips from Google’s Caitria O’Neill.
