The Insight RoomThe Insight RoomRooms →

Free · Learning resource

Learn to plan research like a senior.

Ask The Room started as a planning tool — but it doubles as a teaching one. This page is the field guide behind it: how to choose a method, what each one actually answers, and the question every junior asks first — how many people do I need?

Try Ask The Room

Seven questions. A plan you can defend to your team.

Before any method

The five steps, in order.

Most research that fails was doomed at the planning stage. Run through these before you open a recruitment spreadsheet.
  1. a

    Write the decision first

    Before choosing a method, write one sentence: "We need to decide whether to ___ by ___." If the team can't agree on that sentence, the problem is alignment, not evidence — and no method will fix it.

  2. b

    Turn the decision into a researchable question

    A good research question is about user behaviour or needs, not about your solution. "Do people understand this?" is researchable. "Do people like our idea?" is a hug request.

  3. c

    Choose the lightest method that answers it

    Match the method to the stage: nothing built → discovery; something to react to → concept test; something to use → usability test. Never run a bigger study than the decision deserves.

  4. d

    Size it honestly

    Use the participant guidance below. Small and well-recruited beats large and convenient. Five of the right people outperform twenty of whoever was available.

  5. e

    Know when not to research

    If your own analytics, support tickets or session recordings already hold the answer, read them first. Research earns its budget on questions your data can't answer.

Choosing a method

What each method answers — and where it lets you down.

There's no best method, only the best fit for your stage and question. Every card includes the honest cons, because part of the job is knowing what a method can't tell you.
016–10, or until you stop hearing new things

Discovery interviews

Best when — Nothing is built yet and you need to know which problems are worth solving.

Questions it answers

  • What are people trying to get done today, and how?
  • Where does the current workaround hurt most?
  • Which problem is expensive enough that they'd pay to fix it?

Pros

  • + Cheapest way to avoid building the wrong thing
  • + Surfaces needs nobody has articulated yet

Cons

  • – People are bad at predicting their own behaviour
  • – Tells you nothing about whether your design works
028–12, split across your key customer types

Customer interviews

Best when — You have customers and need to understand how they choose, buy and stay.

Questions it answers

  • Why did they choose you over the alternative?
  • What nearly stopped them?
  • What would make them leave?

Pros

  • + Decision-ready stories the whole team can use
  • + Great for messaging and positioning

Cons

  • – Only hears from people who already said yes
  • – Memory is flattering — verify with behaviour where you can
035–8 per distinct user group

Moderated usability testing

Best when — Something exists — prototype or product — and you need to know if people can use it.

Questions it answers

  • Can people complete the core journey unaided?
  • Where do they hesitate, and why?
  • What would stop them continuing?

Pros

  • + Watching beats asking — you see real behaviour
  • + Finds the big problems fast

Cons

  • – Artificial setting; people try harder with a moderator watching
  • – Tells you what's broken, not what to build instead
046–10 per concept round

Concept testing

Best when — You're choosing between directions and need reactions to something concrete.

Questions it answers

  • Do people understand the proposition in ten seconds?
  • Which parts do they actually care about?
  • Which version lands hardest, and why?

Pros

  • + Breaks ties with evidence instead of the loudest voice
  • + Kills weak concepts before they cost real money

Cons

  • – Reactions to a concept aren't commitment — intent ≠ behaviour
  • – Easy to bias with how you present the options

The recurring question

How many participants do you actually need?

The honest answer is 'fewer than you think for qualitative, far more than you think for quantitative.' Here's the working guidance behind every Ask The Room recommendation.

Qualitative studies

5–8

Nielsen's research on usability testing shows around five users reveal roughly 85% of the core usability problems in a single journey. After that, returns diminish fast. Test with five, fix, then test again — two small rounds beat one big one.

Interview studies

6–12

You're looking for saturation — the point where new sessions stop producing new themes. In a reasonably homogeneous audience that usually arrives between six and twelve conversations. If session nine still surprises you, keep going. If you're segmenting, treat each segment as its own study.

Multiple audiences

× per group

Sample sizes multiply by audience, not by total. Five enterprise admins and five occasional users is two studies, not one study of ten. Juniors often pool everyone into one group and end up able to say nothing about anyone.

Surveys & statistical significance

100+

Quantitative claims need volume. To detect a meaningful difference between two groups at conventional confidence (95%, ±10% margin) you generally need around 100 responses per group — often more. Five survey responses is an anecdote with a chart. If you can't reach the numbers, run interviews instead and be honest that your findings are directional.

Rule of thumb: if you're making a claim with numbers, you need the numbers to back it. If you can't recruit enough people for statistical confidence, change the method — not the claim.

Put it into practice

Run your next project through Ask The Room.

Answer seven questions about your project and get a plan — method, participants, timeline and a ballpark cost — that you can take to your team or your mentor. Sometimes it'll tell you not to do research at all, which is a lesson in itself.

Ask The Room — it's freeMentoring a team? Talk to Dale