Useful Questions For Stakeholder Interviews

Stakeholder interviews aren't just about gathering requirements or aligning expectations. They are rare opportunities to minimize the risk of things going sideways. Surely it's about understanding needs, key goals, perspectives — and everything that is needed to keep them on our side.

But what matters in a conversation isn't only what is said, but also what is skipped and avoided, where their voice changes, where their attention fades away. To uncover them, we need to find the right questions to ask. So let's see how to do just that.

Design For Listening, Not A Conversation #

The strategy that has worked for me over the years is to design the entire conversation around listening to stakeholders, not speaking about them or even with them. And typically it all starts with only one single question: "Please guide me through the product and explain its key features."

There is no small talk, no introductory questions, no dancing around the topic, no deep dive into my workflow. I merely explain that in the next 45 minutes I'm trying to find problems that are worth solving, and understand the context around these problems and the project goals.

This opens the conversation immediately — and then I pay attention to details highlighted, features skipped, and ask plenty of follow-up questions to understand the motivations and the goals that a stakeholder has. The focus is not on talking, but on listening very carefully.

Depending on the situation, I also ask for permission to record the conversation to study it later. However, often it might be a good idea not to do so — especially when a project is in poor shape, or there is a sense of urgency. On record, people tend to open up much less than if they speak privately.

My Stakeholder Interview Templates #

Every conversation requires separate preparation. But I try to be quite cautious and strategic about the very first one. Below are a few questions I have ready and prepared, though they will vary significantly depending on how a stakeholder is actually involved — e.g. as a power user or as a decision maker.

Questions For Power Users #

When working with power users, my main task is to ensure that my work will not severely disrupt existing operations and existing ways of working — at least not without a proper heads-up and preparation. The questions reflect just that:

Dear Ms. Krajewski,

As a design lead on the project, my team and I are currently in the process of interviewing our active customers. As we start our work, we'd like to better understand your pain points, most used product features, workflows and priorities.

1. What's your work environment like (e.g. noise, displays)? [Work setup]
2. What are the most frequent tasks that you perform? [Core workflows]
3. Could you explain how the product helps you with that? [Product fit]
4. What other products do you use with this product, and how? [The stack]
5. Please walk me through your process, from start to finish. [Guided tour]
6. What do you find most useful and helpful for these tasks? [High points]
7. What do you find most confusing and broken here? [Low points]
8. What does success look like for you and your team? [Ideal outcome]
9. What challenges are top priorities for you or your team? [Important risks]
10. What's the most important thing for us to get right? [Must-haves]
11. What constraints or frequent issues should we know about? [Limitations]
12. Anything else that's really important for me to know? [Hidden troubles]

Questions For Decision Makers #

For decision makers, I need to understand what goals they have with the project, and how willing they are to participate in it. Here's the full text for stakeholders as decision makers:

Dear Ms. Krajewski,

As a UX lead on the project, my team and I are currently in the process of discovery. As we start our work, we'd like to better understand your pain points, expectations and success criteria.

1. What's the purpose of this project for you? [Interest, engagement]
2. Where does this project fit in your daily work? [Their perspective]
3. What's the most important thing to get right? [Priorities]
4. How would you describe the target audience? [Their view]
5. If you could understand one thing about users, what would it be?
6. What important insights did you learn about users recently?
7. What does success look like for you and your team? [Metrics]
8. What challenges are top priorities for your team? [Pain points]
9. What's the success criteria for the project? [Ideal outcome]
10. What constraints or frequent issues should we know about? [Risks]
11. What is your ideal level of engagement for the project? [Expectations]
12. Anything else you think nobody said to me yet? [Hidden troubles]
13. Is there anybody else who you think I should speak to? [Leads]

Real Insights Aren't In The Answers To These Questions #

Now, this might sound counter-intuitive. But I absolutely love Anton Sten's point that the actual meaningful insights usually won't be on the surface — in answers to all these questions. They typically live in the follow-up questions and answers — and often in the way a stakeholder responds, what they leave out, and what they overstate or repeat a number of times.

It's almost an art in itself to spot when there is an opening to ask for more specifics — and often (ironically) it's the points that a stakeholder makes last, but emphasizes rigorously. And sometimes it helps to rephrase the question to hear them out one more time.

However, follow-up questions are effective only when we ask about blockers or troubles that are aligned with a stakeholder's incentives — and that stakeholders want to iron out. This brings us to incentive architecture.

Incentive Architecture #

You can't really convince anyone to change what they're doing unless you change their incentive. As Abby Covert explains, people can see a problem, admit it's a problem, complain about the problem regularly — and still do absolutely nothing about it.

The problem is that different stakeholders often have very different incentives and priorities:

• Product teams care about short/mid-term metrics, e.g. conversion, revenue, daily active users.
• Designers care about UX and quality of service.
• Engineers care about scalability and flexibility.
• Marketing cares about brand perception and reach.
• Management cares about finances and team performance.

The idea is to learn the incentive of your key stakeholder and reframe your conversation in terms of what they actually care about.

Abby suggests having an honest conversation about incentives — how they make decisions, and how your goal is aligned with theirs. The core question to ask yourself upfront: "What incentives would the change I want actually take?" That single question reframes every difficult stakeholder conversation.

Reasons Why Stakeholders Disagree With You #

And sometimes everything works as expected — until it doesn't. Your stakeholders might eventually start blocking your efforts, despite you doing everything right — engaging them properly from the very beginning.

Well, stakeholders don't really try to make your life more challenging. Their incentive might have shifted, of course, but they still might share your goals — they just don't agree with your direction.

As Julie Zhuo wrote, when stakeholders reject a design, there are typically only three reasons. We need to address the cause of the disagreement:

1. They disagree with the problem you're trying to solve.
2. They disagree with the assumptions you're making.
3. They disagree with your execution to solve that problem.

And often they can't articulate the reason why they disagree, because they don't know your thinking and the work you've done. One simple way to address that is to reflect (preferably with video clips from user interviews) on exactly what the user's problem is, and what assumptions you are making.

Wrapping Up #

As designers, too often we see our stakeholders as adversaries. Yet we rarely know how our stakeholders work, so we shouldn't expect them to understand what we need either. Stakeholders aren't adversaries. Typically they don't want to make your life difficult, and they care about the quality of your work just as much as you do.

But often they aren't your supporters either. To get there, your work must be aligned with their incentives — they must have a real reason to invest time and effort to contribute to the project.

So take some time to explain how your work ties in with their goals. Once you truly understand and support your stakeholders, you might be surprised how quickly you get the support that you need.

Useful Resources #

• The Delicate Art Of Interviewing Stakeholders, by Dan Brown.
• The Stakeholder Interview, by Anton Sten.
• 100 Questions (For Stakeholders), by Dan Brown.
• Incentive Architecture, by Abby Covert.
• Stakeholder Interview 101 (+ Template), by Sarah Gibbons, NN/g.
• User-Centered Stakeholder Interview Canvas (PDF), by Alina Prelicz.
• Stakeholder Engagement Canvas (PDF/PPT), by Mitre.
• 100 Questions UX Designers Might Want To Ask In Interviews.