When to use it
At the start of a project, before deciding what to research with users. These conversations do not replace research: they frame it. They tell you what decision is at stake, who makes it, and what each person around it currently believes.
It is not the user interview guide. The interview guide talks to someone who uses the product; this one talks to someone who funds it, decides it or builds it. The questions change, who holds power in the room changes, and what you can promise about confidentiality changes.
It is not the plan either. What comes out of here feeds the research plan: the questions, the scope and, above all, the decision the study will hang on.
Sometimes the kickoff is enough. Not every study needs this round. The rule I use: the more impact the research has, the more necessary these prior conversations become. For a narrow test on one screen, the kickoff will do. For something that will move a budget, close a channel or change the work of a whole team, it will not.
Before you use it
Map before you book. A quick map — you in the middle, the names around you, who relates to whom and who is for or against — changes the whole strategy. It is how you find out that you have no direct line to the person who decides, but you do have one to someone they trust.
Names, not job titles. "The product manager" tells you nothing about how to talk to that person. The name carries the history, and the history is what guides you.
Always one to one. Put a manager and their report in the same room and one of them will not tell the truth while the other will not stop talking. Confidentiality is not a formality here: it is the condition for anything that matters to surface.
Write down how each person understands. Some need words, some need numbers, some need images, and some need to experience it. That is not for the interview: it is for the day you present findings to them, and it decides whether they will listen.
Listen for what they do not say. Which topics they avoid, where they light up and where they get defensive, and which words they use — "users" or "customers", "problems" or "opportunities". Each person's vocabulary is a fact about the project.
Question your first impression. The stakeholder who seems difficult usually has context you do not. And your expertise does not make you superior to someone who talks about conversion instead of experience: they speak another language, they are not wrong.
Everything in brackets gets replaced.
The document
Three parts used at different moments: the map is done once, the guide repeats per person, and the synthesis gets filled in when all of them are done.
Project: [name] · Lead: [name · role] Date: [DD/MM/YYYY] · Next review: [DD/MM/YYYY]
1. The map, before booking anything
Draw yourself in the middle and put the names around you. Then fill in this table, which is the map written down.
| Name | Real role in the decision | Relationship to you | Stance | Who influences this person |
|---|---|---|---|---|
| [name] | [decides · influences · is affected · executes] | [direct · through (who)] | [in favour · neutral · against · unknown] | [name] |
| [ ] | ||||
| [ ] |
Who is left out and why: [sometimes the decision is not to interview someone; write it down]
The order I will talk to them in: [start with whoever gives you context, not with whoever decides: you arrive better prepared at the conversation that carries the most weight]
2. One sheet per person
Repeated once per interview.
Person: [name · title] · Date: [DD/MM/YYYY] · Length: [45] min
What I need from this person in particular: [one sentence; it is not the same for everyone]
What I already know about them before going in: [their role in the project, what they care about, what they are measured on]
Opening
Thank you for your time. I want to understand your perspective on [topic] better, to make sure the research actually contributes to the project.
Then: what you will do with what they say, whether you will record, and that nothing will be attributed by name. Ask whether they are okay with recording, and wait for the answer.
Block 1 · Their role and their history with this
- Tell me what you do and how [the project] fits into your work.
- How long have you been on this? What happened before you arrived?
- What has already been tried to solve this? What worked and what didn't?
Block 2 · What success means to this person
- If this goes well, what will have changed in six months?
- How will it be measured? What number does your team watch?
- And you — what are you measured on?
Question 6 is slightly uncomfortable and it is the one that explains the most. Someone measured on delivery speed and someone measured on retention do not want the same thing from the project, even when they say the same thing in the meeting.
Block 3 · What worries them
- What worries you most about this?
- What would have to happen for you to consider this a bad decision?
- Is there anything the team is taking for granted that you are not convinced by?
Block 4 · Who they think the user is
- Who is this for, in your words?
- What are you basing that on? [data, a conversation, intuition: all three are valid answers and they have to be told apart]
- What do you think that person is trying to do when they get here?
- What would surprise you to find out?
Block 5 · How they want to work
- How would you like to hear what we're finding, and how often?
- What format actually works for you? [a report, a conversation, a workshop, a number on a dashboard]
- Who else should I be listening to who isn't on my list?
Number 16 always goes in, and it goes last. It is the one that corrects the map from point 1.
Conversation log
| How they take things in | [words · numbers · images · doing] |
| Vocabulary they use | ["users" or "customers", "problems" or "opportunities"…] |
| Where they got excited | [ ] |
| Where they got defensive | [ ] |
| What they avoided | [ ] |
| Verbatim quote that sums up their stance | "[ ]" |
| What I still need to ask them | [ ] |
3. Synthesis, once they are all done
What everyone agrees on
[What nobody disputes. It is usually the starting point, and sometimes it is a shared assumption nobody has checked.]
Where they contradict each other
This table is the most valuable part of the exercise. A disagreement between stakeholders about a fact — not about a preference — is, almost always, the research question.
| Topic | Who says what | It is a disagreement about… | Can research settle it? |
|---|---|---|---|
| [topic] | [A says X · B says Y] | [fact · priority · values] | [yes, with what method · no, it is a decision] |
| [ ] |
A disagreement about priorities or values is not settled by research: it is settled by deciding, and whoever decides has a name. Confusing the two makes a study carry an argument that is not its own.
What was taken for granted and nobody verified
[The list of assumptions that came out of these conversations. It is the input for the hypothesis canvas.]
What changes in the research plan
[Questions that come in, scope that gets cut, the decision that was made explicit, and who makes it.]
Method note and limitations
This captures what the organization believes, not what users do. It is context and framing, not evidence about the product.
What someone with power says in an interview is filtered by what suits them to say, and by what they think you want to hear. Contrasting several people is what corrects that; a single interview does not.
Nothing recorded here is shared with a name attached without permission. If the map of stances circulates, there are no honest answers next time.
It expires, and fast. Organizations change people: review on [date].
The worked version
The same document with a case written end to end: an invented one, a healthcare provider moving medical appointment booking from its call centre to its app. I chose it because it meets the condition that makes this round necessary — it moves a budget, it changes the work of a whole team, and it may end up closing a channel — and because all three kinds of disagreement show up cleanly. It downloads separately.
Project: Booking medical appointments in the app · Lead: [name · role] Date: [DD/MM/YYYY] · Next review: [DD/MM/YYYY]
1. The map, before booking anything
| Name | Real role in the decision | Relationship to you | Stance | Who influences this person |
|---|---|---|---|---|
| Valentina | Decides: owns the budget and asked for help | Direct | In favour | The commercial director |
| Rodrigo | Is affected: the call centre is his area | Through Valentina | Against | His own team of supervisors |
| Marcela | Decides without anyone noticing: controls the appointment slots | Through Fernanda | Unknown | The heads of each specialty |
| Fernanda | Influences: sees every complaint | Direct | In favour | Rodrigo, who she argues with often |
| Héctor | Executes: engineering | Direct | Neutral, with technical reservations | Valentina |
Who is left out and why: the commercial director. Valentina would rather bring him a proposal she has already discussed, and introducing me earlier would force her to explain a project that has no shape yet. Noted as a risk: if his position is different, I will find out late.
The order I will talk to them in: Valentina first, because she asked for the help and left the door open. I asked her who it was important that I talk to and she named Rodrigo before anyone else — "if Rodrigo doesn't come along, this doesn't happen" — so Rodrigo goes second even though it is the hardest conversation. Fernanda third, because she has the complaints and leaves me better prepared. Marcela only came up in the conversation with Fernanda and was not on my original list.
2. One sheet per person
Person: Rodrigo · head of operations · Date: [DD/MM/YYYY] · Length: 45 min
What I need from this person in particular: whether his resistance is about the project or about what the project does to his area, because those are two different conversations.
What I already know about him before going in: eleven years at the company, the call centre has 40 people and he answers for the service level. Valentina described him as "the one you have to convince".
Opening
Thanks for the time, Rodrigo. I want to understand your perspective on appointment booking better, to make sure the research actually contributes to the project.
I explained that I would record only so as not to lose detail, that the audio does not leave the research team, and that nothing is attributed by name. He said yes, and that he would rather "talk straight" anyway.
Block 1 · His role and his history with this
1. He answers for the call centre: 40 people, shifts, and the service level reported to the board every month.
2. Eleven years. There was already an attempt to move booking to the web in 2021 "and it fell over in three months, when people started calling anyway but angry, because the appointment they had booked didn't exist".
3. What was tried: the web. What did not work: syncing with the appointment calendar. What did work and nobody looks at: waiting times went down when they hired four more people.
Block 2 · What success means to this person
4. "That the people who call are the ones who need to call, and not the ones who couldn't do it on their own."
5. His team watches the service level: percentage of calls answered within 40 seconds.
6. He is measured on that and on cost per call. And here is the knot: if the app takes the simple bookings and leaves the call centre only the complicated cases, his average handling time goes up and his metric gets worse even if the project went well.
Block 3 · What worries him
7. That 2021 repeats itself: promising a channel that does not work and taking the blowback.
8. It would be a bad decision "if in six months I have the same number of calls and a new complaint about the app on top".
9. What he is not convinced by: "Nobody has asked whether the problem is the phone. I think the problem is that there are no appointments."
Block 4 · Who he thinks the user is
10. "Women over 60 calling about their check-up, and young mothers calling about their kids."
11. What he bases that on: what the supervisors tell him and having listened to calls. There is no data on the age of who calls, "but you can tell from the voice".
12. He thinks they arrive trying to get an appointment soon, not a convenient one.
13. He would be surprised "if the older women used the app. Genuinely surprised".
Block 5 · How he wants to work
14. He would rather hear things early than late, and in person: "don't send me a 40-page report on the last day".
15. A half-hour conversation with the results, and bring him the recorded calls if something contradicts him.
16. He named Marcela: "talk to the one who builds the calendar, otherwise this makes no sense".
Conversation log
| How he takes things in | Numbers first, and by doing: he wants to listen to the calls, not read about them |
| Vocabulary he uses | "People", never "users". "Complaints", never "pain points" |
| Where he got excited | When he told the story about the four new hires and the drop in waiting time. Nobody had asked him about it |
| Where he got defensive | At the word "digitize". His tone changed mid-sentence |
| What he avoided | He never once said what would happen to his team if calls go down. I asked twice, in two ways, and both times he answered about the metric |
| Verbatim quote that sums up his stance | "Nobody has asked whether the problem is the phone. I think the problem is that there are no appointments." |
| What I still need to ask him | What happens to the 40 people. I will ask him directly in the second conversation, once there is more trust |
3. Synthesis, once they are all done
What everyone agrees on
That booking an appointment today is hard, and that the first call almost never resolves it. Nobody disputes that. What is a shared assumption nobody verified: that the difficulty is in the channel.
Where they contradict each other
| Topic | Who says what | It is a disagreement about… | Can research settle it? |
|---|---|---|---|
| Can people over 65 book through an app? | Rodrigo says no, and that it will show up in complaints. Fernanda says yes, that they already do it with help from a son or a granddaughter | Fact | Yes. It is the study's main question: interviews with a guided walkthrough, and whoever accompanies them has to be included, not only whoever books |
| Is the problem the channel or appointment availability? | Rodrigo says there are not enough appointments. Valentina and Fernanda assume it is the channel | Fact | Yes, and it is cheaper than the above: it is answered with the calendar data Marcela already has. It goes first, because if Rodrigo is right the whole project changes subject |
| The app first, or fixing the call centre first? | Valentina wants the app this year. Rodrigo wants headcount before a new channel | Priority | No. It is a budget decision and Valentina makes it. Research can inform it, not replace it |
| Does the phone channel close once the app works? | Nobody says it out loud. Valentina hints at it, Rodrigo fears it, Fernanda believes it should never close | Values | No. It is a leadership decision about who gets left out, and it has to be put on the table before researching, not after |
What was taken for granted and nobody verified
- That the problem is the channel. Three of five people said so with no data; the only one who could disprove it — Marcela — was not on the original list.
- That whoever books is whoever gets seen. Fernanda mentioned in passing that many appointments are booked by daughters for their mothers, and that changes who has to be interviewed.
- That the app would be for everyone. Nobody has said who it is not for.
What changes in the research plan
- A prior, cheap question comes in: are there appointments available in the time slots people ask for? It is answered with the calendar data, before talking to anyone. If the answer is that there are not, the channel study is postponed and this plan gets rewritten.
- The main question is reframed: it stops being "can they book through an app?" and becomes "who actually books, and with whom?". The unit is not the person being seen, it is the pair.
- Marcela joins the map as a stakeholder who decides, not as internal context. She controls the appointment slots, so she decides in practice even though nobody named her on the original list. That she only surfaced in the third conversation is the argument for always asking who else you should be listening to.
- Scope gets cut: closing the phone channel is explicitly out. It is not a research question and dragging it along contaminates the others.
- The decision that depends on this is written down with a name: Valentina decides, in March, whether the budget goes to the app or to headcount.
Check before you use it
- Did you make the map before booking, or did you book first?
- Are the names there, or did job titles survive?
- Is every interview one to one?
- Did you ask "and what are you measured on?" It is the most revealing question and the one most often skipped.
- Did you close each conversation by asking who else you should hear from?
- Does the disagreement matrix separate facts from priorities?
- Is any quote attributed by name in something that will circulate?
Grounding
The map and the way these conversations are run come from Pride, prejudice and stakeholders, where I tell the mistake I made and the simplified force-field analysis I use.
The question blocks cross three sources. From the Nielsen Norman Group's Stakeholder Interviews come the axes of success metrics, priorities, prior history and communication preferences, along with the habit of closing by asking who else to interview. From the Internal Stakeholder Interviews chapter of the User Interviews field guide come the per-person preparation and the synthesis by patterns. The rest — the disagreement matrix, asking what each person is measured on, and recording how each one understands — comes from the article and from my own practice.
To formulate the questions: The heart of your UX research.
What comes out of here feeds the research plan, and the assumptions that surface get sorted in the hypothesis canvas.