01 / UNDERSTAND
What are stakeholder interviews?
Stakeholder interviews explore the perspectives of people who influence, deliver or are affected by a project. They help uncover goals, responsibilities, constraints and differing accounts of how an organisation works. Interest and authority are different: someone may bear a consequence without controlling the decision.
In this guide, the focus is organisational and delivery perspectives. Interviews with service users remain necessary for understanding their own experience. A manager’s description of customer needs is an organisational account, not a substitute for user evidence.
Why use Stakeholder Interviews?
A design brief can hide conflicting definitions of success. Separate conversations let stakeholders explain their reasoning without defending it in a group. This evidence helps clarify what is fixed, what is negotiable and whose agreement a change requires.
When to use it
USE IT WHEN
A broad brief needs clearer priorities and decision boundaries.
Departments describe the same service problem differently.
A change may shift work or responsibility to people outside the project team.
When to choose another method
Use Stakeholder Map to identify relevant roles and missing perspectives before interviewing.
Use Expert Interviews when you primarily need specialist knowledge about a domain.
Use User Interviews to hear directly how people experience the service.
What you’ll need
Define the decision and include sponsorship, delivery and affected roles, including people with limited authority. Explain how notes will be used and the realistic limits of confidentiality. Prepare common topics with role specific probes. Attendance does not establish consent to a proposed solution.
What the interviews need
Keep the elements that help answer your question and support a decision.
What the person actually does and is accountable for.
The outcome they want and why it matters to them.
The evidence or metric they use to judge improvement.
A stated limit with its source and scope.
Who can decide, approve, block or change the arrangement.
What they need from another role to deliver the outcome.
02 / PUT IT INTO PRACTICE
How to conduct stakeholder interviews
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Define the decision
State what the project needs to clarify, rather than collecting general opinions.
Ask what must change before a university redesigns room booking.
02
Choose the perspectives
Use the stakeholder map to include delivery staff and affected roles alongside sponsors.
Interview a porter as well as facilities, digital services and student support.
03
Prepare shared topics
Ask about responsibilities, recent examples, success measures and dependencies. Adapt probes to the role.
Explore what each role considers a successfully resolved booking request.
04
Establish the conversation
Explain the research purpose and how information may be shared. Avoid promises you cannot keep.
Discuss how an account might identify a small team even without names.
05
Explore actual practice
Ask for a recent case and the decisions involved. Distinguish events from preferences.
Trace a room request that required an exception to the usual process.
06
Clarify limits and power
Probe the source of each constraint and who could change it.
Check whether a rule comes from policy or a local staffing arrangement.
07
Compare and act
Review differences without erasing their source. Assign unresolved questions and decision owners.
Agree who will decide how exceptional bookings are handled before automating them.
Example: a university room booking service
Fictional scenario: a university plans a simpler room booking form. Facilities values predictable use, digital services wants fewer support requests, and student support needs flexibility for accessible rooms. A porter explains that late changes create work which the ticket system does not record.
The accounts reveal different definitions of a resolved request. Closing a ticket can improve one team’s measure while leaving the porter to arrange access. The team records this disagreement and checks the current exception policy.
It would establish an owner for exceptional bookings before defining the form’s requirements, then research students’ actual experience. These roles, accounts and decisions are invented.
03 / BELOW THE SURFACE
Below the surface: apparent alignment can hide a transfer of work
Everyone can agree on simplicity while disagreeing about who must absorb the exceptions.
SUCCESS
What does resolved mean for this role?
Compare the actual measures.
EXCEPTION
Who handles what the standard process misses?
Trace the extra work.
AUTHORITY
Who can change this constraint?
Locate the decision owner.
A stakeholder may support automation because their team will handle fewer requests. Another may agree because they expect automation to resolve those requests completely. The same positive answer therefore conceals different assumptions. Ask where the work goes, including when the proposed process fails.
For the booking example, compare the ordinary request with a late accessible room change. Record who notices, coordinates and authorises the exception. This question is an editorial extension that helps test the consequences of apparent alignment.
Interviews surface these differences; they do not produce an agreement by themselves. Treat consensus as a decision to make, with authority, evidence and consequences visible. A tidy summary that omits the porter’s account can make a project easier to approve while making delivery harder.
Stakeholder Interviews companion worksheet
These two original Design Iceberg companion sheets provide an interview planner and a stakeholder decision review. Page one records roles, responsibilities, priorities and prompts. Page two compares success measures, constraints, dependencies and transferred work. They are practical discussion aids, not official or validated stakeholder interview instruments.
Practical tips
Ask for recent cases before accepting general descriptions.
Separate a stated constraint from its verified source.
Include delivery voices whose work rarely appears in project reports.
Common mistakes
Treating stakeholder preferences as direct evidence of user needs.
Interviewing only sponsors and people they nominate.
Presenting a combined summary that hides meaningful disagreements.
What you’ll get
A grounded account of organisational priorities and dependencies. Turn unresolved differences into explicit decisions, identify who can make them, and carry claims about users into research with those users.