Stakeholder interviews are the cheapest piece of research you can run, and the one most often skipped. I put together a session for our product design team on the part of the research process that usually gets passed over – not as a general talk, but as the way I actually work.
Rather than teach the method in the abstract, I split the session in two. The first half is the method itself – what stakeholder interviews are, why they earn their hour, when to run them, and how to prepare. The second half is that exact method executed, step by step, on a product I was working on. The session ended with me showing the artefacts the stakeholder interview produced: the affinity map that turned into research topics for a user interview, and the interview script itself.
The gap. Stakeholder interviews sit awkwardly in most teams. They cost an hour, they need no tooling, and they are still the step most often skipped – usually because the project is already moving and talking to people feels slower than starting to design. The cost shows up later: business goals get assumed rather than confirmed, technical constraints surface halfway through, and the expert knowledge that senior stakeholders carry about users stays inside their heads. None of that is a skills problem. It's a habit problem, and habits are exactly what a team-wide session can shift.
Why teach it rather than just do it. I could have run the interviews quietly and presented the findings. But a method that lives with one designer is a bottleneck, not an asset. The point is to move a practice from one person into a team – so the goal was never to show what I'd found out about onramp users, it was to give the team a repeatable, low-ceremony method they would actually use.
Teaching a method purely in the abstract doesn't transfer: people agree with it in the room and don't reach for it under deadline pressure. Walking through a single case study doesn't transfer either – it reads as a story about one project rather than something reusable. So I built the session to alternate between the two, and made that structure visible.
The theory half establishes a four-step preparation framework; the applied half then spends that framework, step by step, on the onramp product. Nothing in the second half is introduced that wasn't set up in the first.
A tool to kickstart the design and research process. They set the foundations for a project by giving you three things you would otherwise have to guess at: the business goals, the technical and operational constraints, and what stakeholders already know about users – their needs, pain points and behaviour.
Four reasons, and only the first is about information. They give you the context to set clear goals, plan milestones and prioritise. They make working with stakeholders easier, and build rapport. They get everyone to the same understanding of where the product is going. And they earn trust and buy-in – when stakeholders can see their input was heard, they stop reopening the same decisions three months later.
The earlier you learn what the relevant stakeholders want and care about, the earlier you can point design work at it. So: as early as possible – and again whenever there's a gap in your understanding. That second condition matters more than it sounds. It tells designers it's fine to go back and ask, instead of treating the kickoff as the only moment they're allowed to be unsure.
This is the spine of the whole session – four steps, and everything in the second half is this list, executed on a real product.
The crypto onramp product lets web3 wallet users purchase crypto without leaving the ecosystem, with the crypto delivered straight to their wallet. We already had a working picture of the broad user needs from usability, perception and desirability testing: a lower price when purchasing crypto; speed, ease and the comfort of staying inside an ecosystem they already trust; and control and safety, for users who don't want to depend on exchanges.
What that testing couldn't tell us was the strategic layer. Beyond the problems every onramp solves, what is our unique selling proposition in key markets? Which specific problems are we solving for users in those markets? Are we better suited to particular niches? And who, concretely, are the early adopters? Those are the questions that justify user interviews – and the reason to talk to stakeholders before designing the study, because the answers might live across product, engineering and commercial teams as much as with users.
Three goals. The first one was political rather than informational: get buy-in on running user interviews at all. The second was preparation, in two parts – "ask the experts" and review together what we already know about onramp users, gathering extra context and marking user scenarios alongside the quantitative data we'd collected; then gather the stakeholders' own research questions, the things they wanted to find out. The third was to make the value explicit: mark what we'd like to achieve, so that when answers came back from the interviews, everyone could already see how those answers would move the work forward.
An interview that only collects information uses half the room. One that also wins support pays off twice – you learn something, and nobody has to be talked into the research later.
Mapping the actual topics and questions that designers would pass down to their stakeholder to be able to get the most out of the meeting.
Start with affinity mapping: cluster the similar questions into topics, so a loose pile of stakeholder curiosity becomes a structured set of themes. Then split those into two groups – what belongs to the current research, and what belongs to a future one. Doing it in that order keeps the session from sprawling, while still holding on to the good ideas that arrive at the wrong moment.
The clustered research questions became the structural backbone of the interview guide itself. Add in the research documentation, and an explicit note on how the business would benefit from the study. The topic blocks in the finished guide map directly onto the clusters from the board – onramp motivations and how users choose one; purchasing behaviour, habits, pain points and needs; paying with different methods.
What I'd iterate upon. The session could have a follow-up – a more practical piece where participants listen to a recording of a stakeholder, write down research topics, cluster them, and decide which topics go into one research format and which into another.
The step that needed more time. "Find stakeholders" got the least airtime of the four, and it's the one designers earlier in their career struggle with most – knowing who actually holds a decision, and who merely has an opinion about it, isn't obvious from an org chart.
The most useful part of this method turned out to be the least glamorous one: deciding which questions actually belong in a moderated interview, and which are really asking for analytics, a survey, or a usability test. That judgement is what separates a research plan that answers something from a list of questions that sounds thorough.
So I turned it into a tool. I built a Claude Skill – a senior UX research advisor for reviewing, creating, reframing and methodologically classifying research questions for moderated user interviews, stakeholder and PM input included.
Two case studies sit close to this one – the product work this method fed into, and the same instinct for getting a room aligned before anyone starts designing.