Stakeholder interviews: what to ask before a project starts

A stakeholder interview is a conversation with someone who has an interest in or power over the project, held before any design work begins. It surfaces the history, the business goal, the constraints and what has already been tried. Cover four topics: how success will be measured, what the priorities are, what the person knows from their role and how they want to follow the work. Whatever comes out of it is a hypothesis about users, and it still has to be checked with the people who use the product.

What the conversation brings to the project

Nielsen Norman Group’s guide to stakeholder interviews defines a stakeholder as anyone with an interest in the project or anyone you need to work with to finish it. Interviewing that person looks a lot like a user interview, but the subject changes. You aren’t asking how they use the system. You ask what the project has to achieve and what could get in its way.

The article lists four benefits:

Context and history. Every project arrives with an origin, known limits and solutions that already failed. In a large company, it almost always arrives with politics too.
Business goals. Designers look at users, and decision makers look at the business. The conversation shows which number will prove the project worked.
A shared vision. You find out where their view differs from yours before the gap turns into rework.
Support. People who were heard at the start tend to defend the result at the end.

The best time is the beginning. NN/g says it is never too late, but the interview pays off most when it opens a project, when someone new joins or when something went wrong and the team needs a reset.

Before you book anything: who carries weight

The list of people to talk to often gets long. NN/g’s article on stakeholder analysis suggests sorting it on a power and interest matrix. Each person lands in one of four quadrants, and each quadrant calls for a different approach:

High power, high interest: manage closely, because this person can stop the project or become its strongest advocate.
High power, low interest: keep satisfied, because they may step in once they notice the project affects their own work.
Low power, high interest: keep informed, with invitations to research sessions and design critiques.
Low power, low interest: check in now and then, because positions shift.

The same article adds a third column the matrix lacks: the person’s attitude toward the project. Someone with a lot of power and a negative attitude is where your energy is best spent. The matrix also goes stale. A change in leadership moves people between quadrants, so the map needs another look as the project moves along.

The guide: four topics and open questions

These interviews are usually semistructured. Instead of a fixed script, you bring a discussion guide that gives direction and can be set aside when the conversation gets going. NN/g suggests grouping questions under four topics:

Success metrics. What they want to achieve, why it matters to the company and which number they track.
Priorities. Which problem sits at the top of their list and their team’s list right now.
History and expertise. Which constraints you need to know about and which solutions were tried before, with why they worked or didn’t.
Process. How involved they want to be and which channel they prefer for updates.

During the conversation, stay neutral and listen more than you talk. Ask for a concrete example, ask about the last time something happened and ask why it matters. At the end, ask who else you should talk to. The answer shows who they consider important and sometimes gets you an introduction to another key person.

If someone has no time to meet, email only the four or five most useful questions rather than the whole guide. The goal that comes out of the first topic is the starting point for any impact report, and measuring a baseline before the project depends on it.

Internal answers become hypotheses, not findings

NN/g’s five-step journey mapping process shows where these interviews fit in a larger piece of research. First the team gathers what the company already knows: market research, support logs, customer feedback. Then it interviews decision makers, using that material to shape the questions. From there, the team drafts a hypothesis map of the journey.

The next step is what separates stakeholder interviews from user research. The hypothesis map has to be validated, or proven wrong, with people outside the company, through interviews, direct observation or diary studies. The article says six to eight participants are enough to get started when time is short.

NN/g’s introduction to journey mapping gives the underlying reason. The actor’s actions on a map should be rooted in data, and the thoughts at each stage ideally come from things customers actually said in research. Internal opinion about users doesn’t fill that slot.

How this worked on the C6 Bank redesign

On the C6 Bank desktop app redesign, I followed that order. The desktop app is where the bank’s most complex operations happen, and its built-up complexity only showed when you watched someone actually use it. The project started with journey mapping and interviews with the bank’s internal stakeholders.

The map and the interviews helped pin down the pain points, but they weren’t enough to make decisions. Design decisions went through iterative prototypes and usability tests with real users before any implementation. The redesign reached development already tested. For how large a test like that needs to be, see the piece on usability testing with five participants.

Where the sources disagree

One-on-one or in a group. The interview guide asks for one-on-one conversations. The journey mapping process accepts focus groups of three or four people in similar roles when time is tight.
Where to start. The interview guide starts from a clear goal for the conversation. The journey mapping process starts from internal data that already exists and only then brings people in.
How much analysis. The interview guide accepts a simple document with the main themes when there are only a few interviews, around five. Beyond that, it recommends thematic analysis, with a code on every observation. The stakeholder analysis article treats the interview as a way to learn someone’s attitude, not as data to code.

The common mistake

The mistake is treating internal interviews as user research. Someone in sales describes what customers complain about, someone in support describes what shows up in tickets, and both accounts sound like findings. They are leads. Write each one down as a hypothesis, name the research that will check it and share the result with the people you interviewed. That way nobody is caught off guard when the map changes.