Research conducted specifically to define and validate the problem space, rather than to evaluate an existing solution. Discovery research asks open questions about behavior, context, and unmet needs — generating the insights that should precede, and anchor, any design work. Skipping it typically results in well-executed solutions to the wrong problems.
Common contexts
- Conducting open-ended interviews to understand why users abandon a workflow before proposing any redesign
- Mapping unmet needs across a user segment to identify which problem is worth building toward
- Challenging a product assumption by exploring how users actually describe their problem in their own words
Use when
Before committing to any solution direction, especially when a team's understanding of the problem comes primarily from internal assumptions, analytics data alone, or stakeholder opinion rather than direct user input.
Avoid when
Don't run discovery research when the question is already well-defined and validated — applying broad open research to a known problem wastes participant time and delays the evaluative testing that would actually move the project forward.
Discovery research doesn't tell you what to build — it tells you whether what you're planning to build is solving a problem users actually have, not the problem your team found most interesting to solve.
Real-world examples
- Airbnb conducted extensive discovery research before launching Experiences, interviewing potential hosts and travelers to understand unmet needs around authentic local activities.
- Duolingo used discovery research to understand why language learners quit apps, revealing that habit formation—not content quality—was the primary barrier, which shaped their gamification strategy.
- Slack's early team conducted discovery research with beta users at companies like Rdio and Flickr to understand real-time communication pain points before the public product launch.