How many people do you need to interview?

Usually between five and twelve. The number is set by repetition rather than by budget — once three consecutive interviews stop producing anything you have not already heard, more of the same segment adds cost and not knowledge. Where there are genuinely distinct groups, say buyers and the people who use it daily, each group needs its own set, and that is what pushes a project toward the upper end of the range.

Could we not just send a survey instead?

A survey tells you how many. Interviews tell you why, and why is the part that changes what you build. A survey also inherits your assumptions, because you have to know the right questions before you can write the options. The honest sequence when both are wanted is interviews first to find out what is going on, then a survey to find out how widespread it is.

We already know our users. What would this tell us that we do not know?

Two things, usually. The first is where your team disagrees — two confident and incompatible theories about what customers want can sit in the same room indefinitely, and research is how that gets settled with evidence instead of seniority. The second is that what you know is drawn from the people who stayed. The people who tried it, got stuck and left are not in your inbox, and they are the ones the interviews are worth the most on.

Who finds the participants?

Either of us. If you have a customer list, recruiting from it is faster and cheaper and we write the screener and the outreach. If we recruit from outside, that takes longer and participant incentives are a separate cost that we agree with you before recruitment starts rather than adding at the end.

Will you tell us what to build?

We will hand you problems in priority order, the evidence behind each one, and an opportunity map of where the openings are. We will not hand you a feature list dressed up as research findings. A feature that came out of a participant's mouth is that person's guess at a solution, and treating a guess as a finding is how research gets blamed for a bad roadmap.

It can do a real part of it, and not the part that matters most. Feeding transcripts to a model to pull candidate quotes, flag friction points and suggest follow-up questions saves days of work and we use it. The interview itself it cannot do, because the skill is staying silent after somebody stops talking and asking them to say more instead of filling the gap with your own theory.

UI/UX & Design

UX research and user interviews

Five to twelve conversations with people who actually use the thing, turned into ranked problems, verbatim evidence and an opportunity map.

From: $1,000–$8,000
Typical time: 2–5 weeks
Usually bought by: Product teams

What this actually solves

Two situations bring people here, and they cost different amounts of money.

The first is that a build is about to be funded and nobody can say, out loud and with evidence, why it is the right thing to build. Somebody usually asks the question in a board meeting or an investor call — how do you know people want this — and the answer that comes back is a story about a conversation somebody had once. That is not a research problem yet. It becomes one the moment the budget is committed.

The second is quieter and more common. Inside the team, two people hold opposite views. One is certain that customers need a faster checkout; the other is certain the problem is trust and the checkout is fine. Both are senior, both are plausible, and the meeting has now happened three times. Arguments between opinions do not end. They end when somebody brings back a recording of a customer describing what actually happened the last time they tried to buy something.

That is what this service produces. Not a document with the word insights on the cover, but a small number of specific, evidenced problems, ranked, with the customer's own words attached to each one — and a clear separation between what people said and what we inferred from it.

What we do, and in what order

Agree what decision this is for. Before anything else, we establish what you would do differently depending on the answer. Research that cannot change a decision is expensive entertainment, and this conversation is where half of the eventual value is created. It also sets the screener, because the right participants depend entirely on the question. Half a day to a day.
Write the screener and recruit. A screener is the short set of questions that decides who is in and who is not — recency of the behaviour, role, and whether they have actually done the thing rather than intending to. Recruiting from your own customer list is fastest. Recruiting from outside takes longer and carries a separate incentive cost, agreed with you before we start. Three days to two weeks, mostly waiting.
Write the discussion guide. The list of questions, in an order that moves from what they did, to what happened, to what they did instead. Every question is checked for a hidden answer before it goes in. One day.
Run the interviews. Five to twelve, thirty to forty-five minutes each, recorded with permission on Zoom or Google Meet. Anyone from your side is welcome to observe silently; watching two of these does more for a product team than reading the report will. One to two weeks.
Transcribe and synthesise. Every meaningful line becomes its own note. Notes get grouped by what they have in common, and only then do the groups get named — naming first is how you find the themes you brought with you. This is done in FigJam or Miro so you can see the wall rather than take our word for the conclusion. Three to five days.
Write it up. What we learned, the problems in priority order, the opportunities, and the participants' actual words as evidence under each one. Anything that is our inference rather than something somebody said is labelled as inference on the page. Two to three days.

Tools, so you know what you are paying for — Zoom or Google Meet for recording, Otter.ai or a language model for transcripts, FigJam or Miro for the synthesis wall, and Notion or Google Docs for the report. Where testing a prototype is part of the scope, Maze as well.

What moves the price

The range is $1,000–$8,000 and three things set where in it you land.

How many interviews, and how many distinct groups. Five interviews with one type of person is a different piece of work from twenty across three groups who buy for different reasons. Each group needs its own screener, its own guide and its own synthesis.

Who recruits. Recruiting from your customer list is quick. Recruiting strangers who match a narrow profile takes weeks and carries participant incentives, which sit outside the rate and are agreed before we start rather than presented afterwards.

Whether a prototype is being tested as well. Talking to people about what they do is one job. Putting something in front of them and watching where they stop is another, and it needs the prototype to exist, tasks written for it, and a separate round of analysis.

What usually goes wrong

The question contains its own answer. Asking somebody whether they have any problems with the current system gets a yes out of politeness, and asking whether they would like a feature gets a yes every single time. Neither answer is worth anything. The question that works is about the last time they actually did the task, walked through step by step. What happened in the past is fact. An opinion about the future is a guess wearing the costume of data.

The interviewer cannot tolerate silence. Somebody finishes a sentence, there is three seconds of nothing, and the interviewer jumps in to explain the product or offer a theory. The three seconds is where the interview lives. Almost everything that ends up quoted in the report comes after a pause that the interviewer sat through, or after the phrase tell me more about that.

The report has conclusions but no quotes. A line saying that users find onboarding confusing is an opinion with a document around it, and the first senior person who disagrees will simply disagree with it. A line saying users find onboarding confusing, followed by three people describing in their own words where they got stuck, does not get argued with. This is why the recordings and the verbatim lines are in the deliverable and not just in our notes.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

How many people do you need to interview?: Usually between five and twelve. The number is set by repetition rather than by budget — once three consecutive interviews stop producing anything you have not already heard, more of the same segment adds cost and not knowledge. Where there are genuinely distinct groups, say buyers and the people who use it daily, each group needs its own set, and that is what pushes a project toward the upper end of the range.
Could we not just send a survey instead?: A survey tells you how many. Interviews tell you why, and why is the part that changes what you build. A survey also inherits your assumptions, because you have to know the right questions before you can write the options. The honest sequence when both are wanted is interviews first to find out what is going on, then a survey to find out how widespread it is.
We already know our users. What would this tell us that we do not know?: Two things, usually. The first is where your team disagrees — two confident and incompatible theories about what customers want can sit in the same room indefinitely, and research is how that gets settled with evidence instead of seniority. The second is that what you know is drawn from the people who stayed. The people who tried it, got stuck and left are not in your inbox, and they are the ones the interviews are worth the most on.
Who finds the participants?: Either of us. If you have a customer list, recruiting from it is faster and cheaper and we write the screener and the outreach. If we recruit from outside, that takes longer and participant incentives are a separate cost that we agree with you before recruitment starts rather than adding at the end.
Will you tell us what to build?: We will hand you problems in priority order, the evidence behind each one, and an opportunity map of where the openings are. We will not hand you a feature list dressed up as research findings. A feature that came out of a participant's mouth is that person's guess at a solution, and treating a guess as a finding is how research gets blamed for a bad roadmap.
Can AI do this now?: It can do a real part of it, and not the part that matters most. Feeding transcripts to a model to pull candidate quotes, flag friction points and suggest follow-up questions saves days of work and we use it. The interview itself it cannot do, because the skill is staying silent after somebody stops talking and asking them to say more instead of filling the gap with your own theory.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about UX research & user interviews All UI/UX & Design services