Stakeholder interview guide for assumptions and decisions

A stakeholder interview guide is a set of topics and questions for learning how people inside an organization view a project. It helps you hear goals, limits, and open choices before planning a UX study. The guide leaves room to ask where a claim came from and what still needs to be checked.

For a fictional account-recovery project, a product lead may want fewer support calls while a security lead wants proof of identity. Both views matter. You need to learn which points are rules, which are goals, and which are beliefs about users.

If you already have project notes, compare them with the study questions before drafting the guide. Keep the source of each claim visible so a colleague can check it later.

What stakeholder interviews can tell you

These interviews reveal how a project works inside the organization. Ask about success, past choices, known risks, and who owns each decision. NN/g's stakeholder interview guide groups common topics around goals, priorities, history, and process.

A stakeholder may bring direct knowledge of a system or policy. They may also repeat a belief about what users need. Record the basis for both. A report, a recent case, and a personal guess deserve different treatment when you plan a study.

Internal views can point you toward useful user questions, but they do not establish how common a user problem is. Digital.gov's research guidance asks teams to make assumptions visible and explore disagreement. Check claims about users through research suited to that question.

Keep the purpose distinct from the study itself. A semi-structured interview gives you a flexible way to ask follow-up questions. Who you speak with and what they can know still define the reach of the evidence.

Set the goal and interview boundaries

Write the decision the study will inform. In the fictional recovery project, the team needs to learn where people get stuck while trying to regain access. It has not yet decided to add help text, change identity checks, or revise support steps.

Choose people whose roles cover the goal and its limits. Include those who set priorities, see support cases, build the system, and own relevant rules. IxDF's stakeholder guidance uses roles and interests to shape who should be involved. A senior title alone does not cover every kind of knowledge.

Use a common core of questions about the outcome, known facts, assumptions, and open choices. Add probes for each role. This makes the accounts easier to compare while leaving space for each person's expertise.

Agree on note access, attribution, and recording before the conversation. Explain the actual process you can offer. An internal role may be easy to identify even when a name is removed. Avoid promising anonymity unless the agreed process can support it.

Pilot the guide with a colleague. Check whether each question elicits a useful example, whether terms are clear, and whether there is time to explore a claim. This is a practical test of the guide's evidence criteria. GOV.UK's in-depth interview guidance recommends trying the guide before the sessions.

There is no fixed count of questions that fits every project. Keep the core short enough for the goal and available time, then mark optional probes. FHWA's original moderator guide shows main questions with prompts that the interviewer can use when needed.

Questions by stakeholder role

The following guide is a worked example for the fictional recovery project. All roles, questions, and later accounts are made up. Start each interview with the shared core, then select probes that fit the person's work.

Table 1: These questions expose the kind of support each claim needs. A security rule needs a current policy source. A support example needs a case record that you have permission to use.

A business goal needs an owner and a clear meaning. Record how that person will judge success.

Ask about open choices too. A probe such as "What might we learn that would change your view?" can reveal room for a study to influence the decision.

NN/g's examples show probes tied to what the person has just said.

Avoid questions that already contain the preferred fix, such as "Would clearer instructions reduce calls?" Ask about a recent event and the steps taken. GOV.UK's methods guidance supports neutral questions and examples from experience.

Run a flexible, neutral conversation

Use the guide to support listening. Follow a useful example when it arises, then return to any core topic still missing. The FHWA guide is a source example of planned questions with room for probes.

1. Open with purpose and permission. Explain what the interview will inform, who can see the notes, and the agreed recording process. Give the person space to ask questions.
2. Ask for a recent event. Invite them to describe a case or decision from their own work. Ask what happened next and what they saw directly.
3. Clarify the basis. When you hear "we have to," ask whether it refers to a policy, a system limit, or a preferred way of working. Request the source you can review.
4. Explore a different view. Ask what another team might see differently and what evidence would help resolve the point. Keep the question neutral rather than seeking an ally for a preferred answer.
5. Close with gaps and next steps. Ask what you missed, which source should be checked, and who owns the remaining choice. Review your main understanding before ending.

The original source page below shows an opening from a public-design expert study. It states the study's purpose, includes a consent prompt, and then asks about lived experience. It also marks a reserve question for use when useful.

DWP's public-design study, Appendix B, page 92, is shown unchanged via the Public Design Evidence Review. Contains public sector information licensed under the Open Government Licence v3.0. Its expert-study wording and timings belong to that project.

For the recovery project, adapt the purpose and permission steps to your own process. Keep questions about past work open.

A warm opening should leave space for criticism. Avoid praise that implies you expect the person to agree with the team's plan.

Keep assumptions and decisions separate

An assumption log preserves a claim while its support is still being checked. A decision log records a choice, who owns it, and why it was made. Connecting the two helps the team see when a belief has become a plan without enough support.

Here are three fictional accounts from the recovery project. They disagree, and no interview finding has resolved that disagreement:

• Product lead: "Users need more help." Basis: the lead's view, with no reviewed user evidence yet. Open check: which step causes trouble, and for whom? Owner: the researcher plans the check, while the product lead owns the choice about project scope.
• Support lead: Some recent cases involved missing access to an old phone. Basis: the lead's account of cases that still need permitted source review. Open check: what happened in those cases, and what can they tell us about the flow? Owner: support provides records, and the researcher assesses their relevance.
• Security lead: An identity check is required before access is restored. Basis: a policy claim whose current wording has not been reviewed. Open check: what does the rule require, and are there permitted alternatives? Owner: the policy owner confirms the rule and its reach.

Keep the date, role, and source locator with each entry. Mark support as pending until you have read it.

Check each account within its limits. A support case cannot show how often the issue occurs across all users. A policy claim needs the actual rule before it can constrain the study.

Record unresolved priorities as open decisions. Digital.gov's consensus-building guidance treats differing views as something to examine. A useful summary can preserve the conflict so the right owner can act on it.

Review notes soon after the interview while the details are fresh. If you have a permitted transcript, the interview transcript guide explains how to check source wording before using a summary.

Treat an accurate note and a verified claim as separate checks. You can confirm what a person said while still needing to inspect the support for it.

Compare preparation notes in Atlas

Atlas can compare supplied notes to help you prepare questions. The interviewer runs the conversation, while decision owners resolve priorities.

1. Add permitted materials. Bring in the prior stakeholder notes, current study questions, and any policy or case records you are allowed to use. Keep sensitive material within your organization's agreed process.
2. Select the relevant sources. In chat, use @ to name the notes and study questions. Use Project only when you want new retrieval kept to project sources. Earlier chat context may still remain relevant.
3. Ask for a bounded comparison. Try: "Compare these notes with the study questions. For each assumption or constraint, cite the source and suggest a neutral interview probe. Mark missing support and keep conflicting accounts separate."
4. Check the cited passages. Open each citation and read its context. A precise location depends on the source. Confirm the speaker, wording, date, and whether the note describes a rule or a belief.
5. Save your reviewed guide. Correct the proposed questions, remove unsupported claims, and assign open checks. Choose New, then Note, and wait for Saved after recording the guide and its source locators.

Suppose the comparison turns the product lead's view into "Users struggle because instructions are unclear." The note gives no support for that cause. An open question about where users get stuck keeps the cause unknown until the study can assess it.

The saved note should retain the three conflicting accounts. Merging them into one agreed problem would hide the missing policy check and the limits of the support cases. Keeping those gaps visible helps you choose what to ask next.

Turn the guide into research questions

Use the interview notes to refine the study's questions. The broad fictional claim "users need more help" becomes a question about a specific situation: "Where do people who have lost access to their old phone get stuck in the current recovery flow?" It leaves the cause and possible fix open for the study to explore.

Check the question against your research objectives. Decide who needs to take part and what method can answer it. Internal interviews help you plan that work, while direct user evidence addresses the user experience.

If the study will observe people attempting recovery, use a usability test plan to connect the question to tasks, participants, and evidence to collect. Use stakeholder accounts to frame the plan, then observe people using the flow to collect direct evidence.

Leave policy scope with the policy owner and project priorities with the decision owner. Give them the checked sources, open questions, and conflicts. Your finished guide should make the next conversation easier to run and the remaining uncertainty easier to see.