Stakeholder Interviews: Aligning Goals Before You Research

How to run stakeholder interviews with internal teams: what to ask, when to run them, how to analyze answers, and which mistakes to avoid in decision meetings.

info Quick Definition
A stakeholder interview is a semi-structured, one-on-one conversation with people inside the organization who influence a project or are affected by it. It aligns goals, success criteria, and assumptions before you research users.

What is a stakeholder interview, and how is it different from a user interview?

Stakeholders are the people who make decisions, fund the project, or stand to lose if it goes wrong: product, commercial leadership, support, legal, operations. They are not users of the product, even when they use it. That is why the goal of the conversation is different.

In a user interview you seek neutrality to understand real behavior. In a stakeholder interview you seek to understand priorities, constraints, product history, and what each area expects from the project. The facilitator therefore needs prior context about each person’s role: you cannot ask finance the same questions you ask support. User Interviews advises documenting what each stakeholder understands rather than what you assume, asking clarifying questions even when you think you know the answer, and, at the end, comparing what you heard with your initial assumptions.

Why does this matter for a junior designer?

Because many design projects fail before the first screen, over disagreements about what success means. If sales wants more leads and product wants less drop-off at sign-up, any user research will be read through the interest of whoever commissioned it.

A stakeholder interview brings those disagreements to the surface at the start, when they are still cheap to resolve. Supercharge gives three example goals for these interviews: filling the gaps between stakeholders’ objectives, learning about pain points in the digital product, and learning about long-term success indicators.

How do you prepare and run the interview?

  1. Set the goal. Write in one sentence the decision the conversation should inform. If there is no decision, you probably do not need the interview. If your organization has no research practice yet, the team’s UX maturity shows where to start.
  2. Choose who to interview. Nielsen Norman Group defines a stakeholder as anyone with an interest in the project or someone you will need to work with, inside or outside the organization. User Interviews warns about hidden stakeholders, such as support staff who absorb the cost of poor design. If there are too many, pick representatives whose views rest on knowledge of customers, business goals, or operations.
  3. Prepare a guide, not a script. Nielsen Norman Group describes the interview as semi-structured: a list of topics and a few fixed questions. NN/g suggests four topics: success metrics, priorities, history and expertise, and process or workflow.
  4. Combine shared and role-specific questions. User Interviews and think.design agree that everyone should answer a common set, so you can compare, and that each role should get its own questions: marketing may talk about branding, engineering about the systems the product must integrate with.
  5. Run and close. Start with a short introduction, restate the purpose and the duration, and run the interview one-on-one, the format NN/g recommends. Record only with permission. At the end, ask who else should take part; that is how hidden stakeholders surface.
  6. Follow up. think.design suggests closing by summarizing the key messages and asking the person to validate them. And Supercharge warns that stretching the time between interviews risks losing context, so cluster them within a few days.

If the conversation turns into a list of questions read aloud, you lose the most valuable part: what people do not say. Practice the guide until you can talk without looking at it.

How do you analyze the answers?

Nielsen Norman Group proposes a method based on the number of interviews:

  • Five stakeholders or fewer: an informal summary of themes, with the main agreements and disagreements.
  • Five or more: a thematic analysis, which means tagging observations and quotes with codes to find the most significant themes.

In both cases, separate what the person said from what you interpret. Write down the explicit assumptions (what the team believes about users) and the unspoken requirements (what no one asked for in writing but someone expects). Unspoken requirements cost more the later they appear.

When should you NOT run stakeholder interviews?

  • When the decision is already made. If the outcome cannot change the project, the conversation creates expectations you will not meet.
  • When the stakeholder does not want to take part. User Interviews recommends gauging their interest before asking for their time, so you do not ask for more than they are willing to give.
  • When a meeting is not possible. NN/g suggests emailing the top four or five questions. For a large group, a survey streamlines collection, but people are less likely to answer it than an individual email.
  • As a substitute for research with users. What a stakeholder says about users is a hypothesis. Test it with user interviews.

Example

Illustrative example: a team wants to redesign the sign-up flow of a booking app. Before starting, it runs four interviews: product, sales, support, and finance.

  • Product talks about conversion in the first week.
  • Sales wants sign-up to capture contact data for the commercial team.
  • Support reports that half of the calls are about forgotten passwords.
  • Finance asks that the cost per new customer does not rise.

Taken together, the four answers show that the project has four success criteria that compete with each other. The team takes them to a decision session before designing anything. That is the result you want: a shared success criterion, not a nice report.

To synthesize these interviews, an AI article such as AI interview synthesis may help, but always check the original notes before trusting an automatic summary. If the agreements from the interview must hold up across the project, ResearchOps describes how to store and reuse that information.

Common mistakes

  • Letting the loudest voice stand for the whole team. User Interviews notes it is not always the one that best represents the needs of the whole.
  • Reading the question list out loud instead of having a conversation.
  • Dismissing a stakeholder’s skepticism about research. There is often a concrete reason behind it.
  • Creating expectations about results or data access without planning how you will communicate.
  • Mixing goal discussion with design solutions in the same conversation.
  • Forgetting the closing question about who else should talk to the team.

Sources

Frequently asked questions

What is a stakeholder interview in UX?
It is a semi-structured, one-on-one conversation with internal people who have an interest in the project, such as product, sales, or support. It aligns goals, success criteria, and assumptions about users.
How long should a stakeholder interview last?
User Interviews recommends planning at least 45 minutes per interview; think.design cites 30 to 45 minutes as typical. If there are too many stakeholders, choose representatives from each area.
When should you run stakeholder interviews?
At the start of a project, when a new stakeholder joins, or when something goes awry and expectations need a reset. Nielsen Norman Group names those moments, while noting it is never too late to run them.
How is a stakeholder interview different from a user interview?
A user interview seeks neutrality to learn about behavior. In a stakeholder interview the facilitator needs prior context about each person’s role, because the goal is to understand priorities and constraints.
How do you analyze stakeholder interviews?
Nielsen Norman Group suggests an informal summary of themes for five stakeholders or fewer, and a thematic analysis for five or more.