Internal Stakeholder Interviews

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, still the the heart of the matter is just several good conversations.

Benefits of stakeholder interviews in UX design

A successful UX design is especially dependent upon stakeholder involvement. They’ll 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.

Defining goals

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 also update project goals, once you’ve gotten into the work to some degree.

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.

Understanding parameters, user insights, and assumptions

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 stakeholder 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. 

• What are the users' pain points? 
• What factors dictate how they will use the product, and what kinds of interfaces will likely work best? 
• What’s worked well  in the past? What has not?

Earning trust and buy-in

Earning the trust of your stakeholders is always important.

You all have a common objective. So, be willing to work as a team!

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.

Communication isn’t a code word for compromise.

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. They can get on board throughout. 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.

When to use stakeholder interviews in the product development cycle 

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.

Conducting stakeholder interviews

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.

1. Planning

Identify your own research goals

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:

• Are your different interviewees on the same page, or do they have conflicting goals and ideas?
• Does everyone agree about what the project is actually about?
• How do they perceive their own role in the success of the project?
• What work is already done, and what needs to be started from scratch?
• Do you have all the information you need about the project?
• Can you clarify who each stakeholder believes is the end user?
• What does long term success look like to each stakeholder, in the context of this project?
• Why are we building this product?
• What user need led to this?
• What do we know about our user's preferences around this product, and likewise, what are we not yet sure about?
• Are there competitive examples of what we're building that we should take a look at?

Identify stakeholders

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:

• Colleagues who make decisions about time, money, resources
• Those who have information you need, in whatever form
• Those folks you might have to include for peace-keeping
• People with organizational influence relevant to your project

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.

Define your timeline (and budget, if necessary)

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 timeline and budget.

Assign tasks

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:

• If you have multiple interview teams, who will be assigned to which interviewees?
• Who will be responsible for which part of which interview?
• Will one personality pair well to interview another personality?
• If there are difficult personalities, how will you handle challenges that might come up?
• Do you have a comfortable and appropriate space for the interview?
• How will you capture info?

Schedule interviews

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.

Prep participants

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.

2. Prep, Interview, Rinse, Repeat

Prepare a loose moderator guide.

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 this template for user interviews to help guide your conversations.

Manage your time well

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.

Introduce yourself

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.

Prepare your questions 

Some additional samples to get you started:

• What is this project's objective, in your view?
• Why is this project important?
• What does success look like for this project?
• What concerns do you have about this project?
• What challenges do you see this project possibly running into?
• What is your role in this project?
• How will this project impact your day-to-day and your overall job?
• What questions do you have for us?
• How will you use our insights to guide the product development?

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 tell you about the existing systems that your product must integrate with or replace.

In the interview, act like a pro 

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.

Be flexible and responsive

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.

Keep communication going throughout the build process

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.

Maintain alignment

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.

Understand who your stakeholders are, and stay on top of it if stakeholders change. 

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.

3. Document & analyze

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.

Potential pitfalls of stakeholder interviews

It takes a lot of time

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 just don’t want to participate

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. 

Stakeholder input you can’t use

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.

On using stakeholder interview data

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.