In short
Stakeholder interviews surface the goals, constraints and disagreements that would otherwise emerge halfway through a project. Interview people individually rather than in a group, ask about outcomes and failure rather than about features, and treat conflicting answers as a finding to resolve before design begins rather than a problem to average out.
What they are for
Two things, and the second matters more.
Understanding the business context — what this is meant to achieve, what constrains it, what has been tried.
Finding the disagreements. In most organisations, several people hold different views about what the project is for, and nobody has discovered this because it has never been asked directly in the same terms.
Surfacing that in week one is cheap. Surfacing it in week nine, when the design is presented and two people object for opposite reasons, is expensive — and it is the single most common cause of projects going badly.
Who to interview
Whoever is paying, because their definition of success is the one that gets applied at the end.
Whoever will use it internally. The people who will maintain the site, answer its enquiries, or fulfil its orders know things nobody else does, and they are routinely not asked.
Whoever can block it. Legal, compliance, IT, brand. Finding a constraint late is worse than finding it early, and these people rarely volunteer information unprompted.
Whoever talks to customers. Sales and support hear the actual objections and questions, which is the most useful raw material available for both design and content.
Five to eight people is usually enough. Beyond that you start hearing the same things.
Interview individually
Group sessions produce consensus that is not real. The most senior person speaks, others adjust, and you leave with one view held by one person and nodded at by everyone else.
Individually, people say what they think. You will get contradictions, which is precisely what you want — the contradictions are the finding.
Thirty to forty-five minutes each is plenty.
Questions that work
Ask about outcomes and history, not features.
"What does this need to achieve for it to have been worth doing?" The success definition, in their words.
"How will you know whether it worked?" If nobody can answer, that is worth knowing before you start.
"What is the current situation costing you?" Grounds the project in something concrete.
"What has been tried before, and what happened?" Prevents you proposing something already rejected for reasons nobody remembers to mention.
"What must not change?" Surfaces constraints — brand rules, systems, processes, sacred pages.
"What would make this a failure?" Often more revealing than asking about success, because people describe failure specifically and success in generalities.
"Who else should I speak to?" Reliably finds the person nobody listed.
And for internal users: "Walk me through what you do now." Watching or hearing the actual process finds workarounds people have stopped noticing.
Avoid asking for solutions
"What features do you want?" produces a list, and the list is usually a description of the problem in the wrong vocabulary.
When someone asks for a feature, ask what it would let them do. "We need a dashboard" often means "I cannot tell whether things are going well" — which has several possible solutions, most cheaper than a dashboard.
This is not being difficult. It is the difference between building what was asked for and building what was needed.
Handling conflicting answers
You will get them. Two people will describe different primary audiences, or different definitions of success.
Do not average them. A design serving two conflicting goals half-heartedly serves neither.
Do not pick silently. Choosing one without saying so means the other person discovers it at presentation, which is the scenario the interviews existed to prevent.
Present the conflict back, neutrally, and ask for a decision. "Three people described the primary audience as existing customers; two described it as new prospects. These lead to different designs — which is it?"
That conversation is uncomfortable for about four minutes and saves weeks. It is also, often, the most valuable thing the process produces.
What to do with the output
Write a short summary: what people agreed on, where they differed, the constraints discovered, and the decisions needed before design begins.
Send it back. Two things happen — people correct misunderstandings while correction is cheap, and the disagreements become visible to the group rather than only to you.
Then get the open decisions resolved explicitly, in writing, before starting. Every one left open becomes an argument later, at a point when changing direction costs real money.
If you are starting something significant and want the discovery run properly, book a call.
Common questions
Who should you interview at the start of a project?
Whoever is paying, whoever will use or maintain it internally, whoever can block it — legal, IT, brand — and whoever talks to customers. Five to eight people is usually enough before you start hearing the same things repeated.
Should stakeholder interviews be done individually or in a group?
Individually. Group sessions produce false consensus: the most senior person speaks, others adjust, and you leave with one view nodded at by everyone. Individually people say what they actually think, and the contradictions that emerge are the most useful output.
What questions should you ask in a stakeholder interview?
Questions about outcomes and history rather than features — what this must achieve to have been worth doing, how they will know it worked, what the current situation costs, what has been tried before, what must not change, and what would make it a failure.
What do you do when stakeholders disagree?
Present the conflict back neutrally and ask for a decision, rather than averaging the views or quietly choosing one. Averaging produces a design that serves neither goal; choosing silently means the other party discovers it at presentation, which is exactly what the interviews were meant to prevent.
Why not just ask stakeholders what features they want?
Because a feature list is usually a description of the problem in the wrong vocabulary. When someone asks for a dashboard, it often means they cannot tell whether things are going well — which has several possible solutions, most of them cheaper than a dashboard.
