Stakeholder Interviews

Leadership may describe where the business needs to go. Sales hears how people make a decision. Support encounters what happens when the experience does not go as expected. Operations knows what must happen behind the scenes. A developer may recognize a dependency that changes what is practical.

None of those perspectives is the complete picture. Each can change it.

Stakeholder Interviews are one of our primary ways of beginning a project. They help us understand the situation in the language of the people living with it, before turning it into a design brief, a set of requirements, or a proposed first version.

The conversation is not reserved for executives or whoever approves the budget. We consider who knows the experience, who will be affected by the decisions, and whose contribution might otherwise be missing. Relevant external collaborators, service providers, or partners may have knowledge worth including too.

The scope remains proportionate. We are not trying to interview an entire organization simply to demonstrate thoroughness. We want the perspectives needed to make the next decisions responsibly.

People often arrive with solutions in mind. A dashboard. A shorter form. A new identity. A different checkout. Those ideas are useful starting points, and we want to understand the experience behind them.

What made this feel necessary? When did the difficulty last occur? What did someone do to get around it? What would become possible if it were resolved?

Asking these questions does not dismiss the proposed solution. It gives us a better chance of making it useful—or discovering an approach that serves the underlying need more effectively.

We also ask what people do not want to lose. Familiarity, personal attention, flexibility, and the judgment of an experienced team member can be valuable parts of an existing service. A new system should not remove them accidentally in the pursuit of consistency or speed.

Empathy applies inside the business as well as outside it.

Listening well can change what the brief needs to ask. A person who explains a difficult workaround is sharing knowledge about the conditions of their work, not simply presenting an inefficiency for us to eliminate.

Before the conversations, we identify what the project needs to learn and which perspectives could help. Existing briefs, earlier decisions, service materials, organizational roles, and relevant records can provide context.

A discussion guide keeps important topics in view without turning the interview into a questionnaire that must be completed in order. Different roles may need different questions. We want enough common ground to compare accounts, with enough flexibility to follow something important we did not anticipate.

We also explain the purpose of the conversation, how notes or recordings will be handled, and how the findings will be shared. Some topics are easier to discuss individually than in front of colleagues. We consider those conditions rather than assume the same arrangement works for everyone.

A one-to-one interview and a Stakeholder Workshop have different strengths. Interviews give a particular perspective room to develop. Workshops can bring perspectives together to examine a problem, make relationships visible, or explore a response. One can inform the other; neither should be mistaken for automatic agreement.

Useful questions invite people to describe something they know, then help us understand its significance. Depending on the person and the project, we might ask:

• Which part of this experience do you spend the most time explaining?
• Walk us through the last time a request did not follow the usual path. What happened next?
• What do customers expect before they reach your team?
• What information do you need that you rarely receive at the right moment?
• What do you do manually because the current process does not account for it?
• Which decisions can you make yourself, and where do you need someone else's involvement?
• What is working well that a redesign needs to respect?
• If this project succeeds, what would be different in an ordinary working day?

These are prompts, not a script for every engagement. The most useful follow-up may come from an unexpected detail in an answer.

When appropriate, looking at a form, message, screen, or example of the work can make an account more concrete. We ask before accessing or retaining material and avoid bringing unnecessary customer or employee information into the discussion.

Listening includes checking that we understood. A familiar word can mean different things to different teams. “Confirmed,” “complete,” or “approved” may describe very different states depending on who is speaking.

When we help a showroom shape its appointment experience, we make room for the people who understand different parts of it. Leadership can explain the intended value of the consultation; scheduling and sales can explain how a visit is arranged; floor staff can describe the arrival and the work needed to prepare.

We ask about specific encounters, what the website promises, how a confirmation is understood internally and which information reaches the person responsible for the visit. We also ask what should be preserved, including the personal attention that may make the consultation worth booking.

The accounts do not need to agree immediately. We bring them together, identify the relationships and compare what they suggest with relevant records. Where an account makes a claim about the customer, we consider what direct research would be needed to examine it.

That synthesis can inform content, scheduling, information requirements or responsibilities. We review the reasoning with the client so people can recognize how their contribution affected the direction—even when the response is different from the feature they first requested.

We take what people tell us seriously without treating every statement as established fact.

An interview may contain firsthand experience, a secondhand account, an opinion, a proposed solution, a constraint, or a belief about customers. Keeping those distinctions visible helps us use the material appropriately.

Someone responsible for answering customer calls can offer valuable knowledge. Their account does not represent every customer, including those who never called or quietly chose not to continue. Stakeholder Interviews complement User Research; they do not replace direct learning from the people using the product or service.

Sometimes the same person contributes in more than one capacity. An employee might be both a decision-maker and a user of an internal application. We clarify which experience we are discussing rather than assume the role label explains everything.

We also preserve meaningful disagreement. If two teams describe the same process differently, averaging their answers may erase the most useful finding. The difference could reflect separate responsibilities, an unclear handoff, an exception, or a change that has not been communicated.

An interview is not a vote. Seniority, confidence, or how often an idea is repeated should not determine the design by themselves.

A different account may reveal a relationship we have not understood yet.

Notes are the beginning of synthesis, not the end of it. We bring relevant accounts together, compare them with other available evidence, and identify what they imply for the project.

The findings may contribute to a Discovery Findings Report or a focused interview-and-synthesis deliverable. Depending on the engagement, that can include:

• The perspectives represented and those still missing.
• Shared goals, different priorities, and important constraints.
• Recurring difficulties, exceptions, dependencies, and useful existing practices.
• Candidate needs or requirements, with their source and rationale.
• Questions requiring customer research, technical investigation, or another form of evidence.
• Implications for scope, sequencing, and a first useful version.

We can review the synthesis with the client to correct misunderstandings and discuss what follows. Agreement that a summary accurately reflects an internal account does not, by itself, confirm a claim about customers or validate a proposed design.

Where the work helps establish a minimum viable product, we use the findings to discuss what is necessary, what can wait, and which unresolved assumptions matter. Interview requests do not automatically become committed features.

Co-creation asks more of us than collecting contributions. People should be able to understand how what they shared informed the work, even when the final decision differs from their original suggestion.

That can mean explaining a tradeoff, showing how a concern changed the content or interaction, or acknowledging a need that cannot yet be addressed. We can be honest about constraints without making participation feel pointless.

The client gains more than a record of conversations. Shared findings can help teams recognize dependencies, ask more useful questions, and approach future decisions with a clearer understanding of one another.

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

Interviews can happen before, during, and after a project. As a design enters use, the people delivering and supporting it encounter new information. Their experience belongs in Learn and Advance, then in the next round of Discover—not only in the original kickoff.

Stakeholder Interviews can be a focused engagement with findings and recommendations, or part of broader Design Research, strategy, and design work.

Bring the people who know the business, including the ones whose knowledge rarely makes it into the brief. We can help turn those different perspectives into a clearer understanding of what the work needs to do.

Contact Us