Generative vs. Evaluative Research: Define Problems vs. Judge Solutions

Generative research defines problems by asking, "What should we build?" Evaluative research judges solutions by asking, "Did we build it right?" The footgun is using evaluative methods for discovery, which just optimizes a solution for a problem nobody has.
Why it exists
Product development requires answering two different questions: "What is the problem?" and "Is our solution working?" Generative and evaluative research provide distinct toolkits for each. Using the wrong toolkit for the job leads to building products nobody wants or failing to improve things that are broken. They formalize the process of exploring a problem versus inspecting a solution.
The mental model
Think of it as an explorer versus a building inspector. Generative research is the explorer, mapping unknown territory to find opportunities and define the problem space (e.g., "Where should we build a city and why?"). Evaluative research is the inspector, checking if a specific house is built to code and meets its residents' needs (e.g., "Is this kitchen functional?"). One finds the "what," the other validates the "how well."
How it works
Generative research, also called discovery research, uses open-ended, qualitative methods like in-depth interviews, field studies, and observations. The goal is to uncover latent needs and pain points without a preconceived solution. You are listening for problems. Evaluative research uses more constrained methods, often quantitative, like usability testing, A/B tests, or surveys. The goal is to measure a specific design against criteria like task success rate or user satisfaction. You are testing a hypothesis about a solution.
When to use it
Use generative research at the very beginning of a project, before you have a clear solution. It's for finding new opportunities, understanding a new user segment, or exploring a broad problem space. Use evaluative research once you have a prototype, feature, or live product that you want to assess. It's for validating design choices and identifying areas for improvement.
When not to use it
Do not use evaluative methods when you don't understand the problem. Asking users to rate two versions of a bad idea is a waste of time. Conversely, do not use generative methods to get a simple "yes/no" on a design decision; open-ended interviews won't give you statistically significant data to choose between two button colors.
One canonical example
A team wants to build a new app for home cooks. Generative research would involve interviewing people about how they plan meals and shop for groceries, looking for unsolved problems. They might discover a huge pain point is food waste. Based on that, they design a feature to track pantry inventory. Evaluative research would then involve giving users a prototype of that feature and observing if they can successfully add items and understand the expiration alerts.
Interview question
A product team observes a high rate of user churn and wants to understand the underlying reasons. Which research approach is most suitable for this initial phase?
- a.Conducting A/B tests on different onboarding flows to see which retains more users.
- b.Performing open-ended interviews with churned users to uncover their pain points and unmet needs.Correct
- c.Sending out a satisfaction survey to all active users to gauge overall sentiment.
- d.Analyzing user behavior data to identify common drop-off points in the product.
Why? this is the answer
Option B, performing open-ended interviews, is a generative research method designed to uncover latent needs and pain points, which is ideal for understanding the underlying reasons for churn. Options A, B, and D are evaluative methods, better suited for testing specific solutions or measuring existing states rather than defining the root problem.
Just read this? Test yourself on what you have been reading.
Read the original → usertesting.com
- #product
- #ux research
- #discovery
- #validation
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on product — each one lists the topics its interview covers.
See open roles