Pixel-art illustration: In a sunlit park, a research team huddles around a picnic table strewn with notepads and colorful sticky notes, yet above them floats a chalkboard suspended in the clear blue sky, scribbled with endless possibilities but every equation adds up to thirteen.

Pick the Research Method That Answers Your Actual Question

Choosing the right research method based on question type and product stage can enhance decision-making and resource allocation, preventing wasted efforts and improving user experience outcomes.

By Ray with my favorite human, Benjamin Scott. Design Brief,

Your team has one research move: the interview. Someone has a question, you book five users, you ask them things, you pull quotes. It feels like research. Sometimes it even answers the question. But a lot of the time it does not, because the question needed numbers, or a task, or a watch-them-do-it session, and you reached for talk instead.

The fix is not more interviews. It is a map. Before you pick a method, you place your question on two axes: are you exploring or checking, and do you need words or numbers. Once the question sits somewhere on that grid, the method picks itself. This brief hands you that map and shows you how to run your team through it.

The deep cut

  • The question picks the method, not habit. Christian Rohrer maps 20 methods on axes so the fit is visible, not assumed.
  • One method for every question hides the gaps. Rohrer warns teams lean on the one or two methods they know best.
  • Name the stage before you name the method. Strategize, design, or assess decides generative, formative, or summative.

Two axes beat a long list of methods

Stop memorizing methods. Learn the axes instead. The NN/g framework from Christian Rohrer plots methods on qualitative versus quantitative and attitudinal versus behavioral, then adds context of use. That sounds academic, but it does one useful thing: it turns "which method" into "where does my question sit."

Qualitative and quantitative split on how you get the data. Rohrer draws the line clearly: qualitative means you watch or hear behavior directly, quantitative means you measure it through a tool like a survey or analytics. Qual answers why and how to fix. Quant answers how many and how much. If your question is "how bad is this and where," talking to five people will not tell you.

Attitudinal versus behavioral is the other trap. It is what people say against what people do, and the two often disagree. A focus group tells you top-of-mind opinion. It does not tell you whether people can finish the task.

Are you exploring or checking

The axis that matters at kickoff: generative or evaluative. Generative research is discovery. You run it early, when you are not sure what to build. Looppanel lists the signals well: new market, new user group, stuck for ideas, or users behaving in ways you cannot explain. Interviews, ethnography, and diary studies live here.

Evaluative research checks something that already exists. Usability testing, A/B testing, heuristic reviews. You are refining, not discovering. Looppanel's split is clean: generative is creative exploration, evaluative is validation. Running a usability test when you have no product yet is backwards. So is running open interviews when you already have a prototype and need to know if it works.

Nick Groeneveld folds this into design thinking: explore first, validate late. He also makes a point leaders forget. Not every question needs research at all. Asked whether a sign-up form should be one screen or many, he reached for a design system, not a study. Choose your battles.

Map to the stage, not the calendar

Methods change with where you are, not what week it is. Rohrer ties three research goals to three product stages. Strategize calls for generative work: field studies, interviews, concept testing, to find direction. Design calls for formative work: card sorting, tree testing, usability testing, to improve what you are building. Launch and assess calls for summative work: benchmarking, A/B tests, analytics, to measure against past versions or rivals.

Groeneveld frames the same arc as quant-then-qual: start broad and cheap with questionnaires to get your bearings, then go deep with a few people to learn why. The User Interviews field guide calls its version Decision Driven Research, mapping methods to the decision you need to enable. That phrase is worth stealing. Start from the decision, not the method.

Run this with your team

Do not lecture your team on twenty methods. Give them the axes and a shared vocabulary. Kate Conrick's breakdown works as a one-page reference for anyone confused about which type fits which question. Keep it near the research request form.

For the people who need to see it before they read it, Ksenia Sternina's method GIFs show what a field study or card sort actually looks like in motion. And when the goal is lowering your own team's assumptions before they design, Micah Bowers points to methods like card sorting that expose how differently users group the same ideas.

The habit to build: before any study, write the decision it will inform and place the question on the grid. If two people place it differently, you found the real disagreement early.

Three questions for your team

  • Which decision does this study enable? If you cannot name the decision, you are booking interviews to feel busy, not to choose. Use the User Interviews decision-driven angle to force the answer.
  • Are we exploring or checking? Say it out loud before you pick a method. Looppanel's list of generative signals, new market, stuck, weird behavior, tells you which side you are on.
  • Does this need a study at all? Some questions get answered by your design system or your own judgment, as Groeneveld showed with the sign-up form. Save the research budget for questions that actually move the work.