Conducting Discovery Research in the Double Diamond Design Process

This skill teaches you how to use divergent research methods—user interviews, desk research, and observation—to broadly explore the problem space in the first diamond of the double diamond design process.

To conduct discovery research in the double diamond design process, use divergent thinking techniques to broadly explore the problem space. Start by framing your research brief around a design challenge, then combine user interviews, desk research, contextual observation, and stakeholder conversations. Capture all findings without filtering. The goal is breadth—not answers—so you can later converge on the right problem to solve in the Define phase.

Outcome: You'll be able to systematically explore a problem space using multiple research methods, generating a rich body of raw insights that feeds directly into the Define phase.

Synthesized from public framework references and reviewed for accuracy.

ProductIntermediate1-4 weeks per project

Prerequisites

  • Basic understanding of the double diamond framework and its four phases
  • Familiarity with the concept of divergent vs. convergent thinking
  • Introductory knowledge of qualitative research methods

Overview

The Discover phase is the opening movement of the double diamond design process, and it's where most teams either set themselves up for breakthrough insights or doom themselves to solving the wrong problem. Discovery research is the practice of deliberately broadening your understanding of users, context, and the wider landscape before narrowing down. It's uncomfortable by design—you're actively resisting the urge to jump to solutions.

This skill covers the core divergent research techniques used in the Discover phase: user interviews, desk research (secondary research), contextual observation, and stakeholder engagement. You'll learn when to deploy each method, how to plan a research sprint that balances depth with breadth, and how to capture findings in a way that makes the subsequent Define phase dramatically more effective.

Discovery research matters because the quality of your problem definition—and ultimately your solution—is bounded by the quality of your exploration. Teams that skip or rush this phase consistently report higher rates of rework, misaligned stakeholder expectations, and products that technically work but don't resonate with real users.

How It Works

The Discover phase operates on the principle of divergent thinking: you intentionally cast a wide net before filtering. Think of it as building a rich, messy map of the territory before choosing which route to take.

Conceptually, discovery research works by triangulating multiple sources of evidence. No single method gives you the full picture. User interviews reveal motivations and pain points, but people are unreliable narrators of their own behavior. Observation shows you what people actually do, but not why. Desk research gives you scale and context, but lacks the nuance of firsthand contact. By combining these methods, you cross-check assumptions and surface patterns that no single lens would reveal.

The key mental model is the research funnel within the diamond. Even within the divergent Discover phase, you move from broad scanning (what's happening in this space?) to increasingly targeted inquiry (what's really going on for these specific users in this specific context?). But you're still expanding your understanding—not yet narrowing to a single problem statement. That convergence happens in the Define phase, which is the second half of the first diamond in the Double Diamond framework.

Discovery research also serves a critical organizational function: it builds shared empathy across the team. When designers, product managers, and engineers all hear the same user stories and see the same field observations, alignment happens naturally rather than through persuasion.

Step-by-Step

  1. Step 1: Frame the Research Brief

    Before you start any research, write a one-page research brief that articulates the design challenge, what you already know (and assume), what you need to learn, and who the key stakeholders are. This isn't a hypothesis to prove—it's a compass bearing.

    The brief should include: the business context triggering the project, 3-5 open research questions (e.g., 'How do parents currently manage their children's screen time?' rather than 'Do parents want a screen time app?'), known constraints (timeline, budget, access), and success criteria for the Discover phase itself.

    Share this brief with your team and stakeholders before research begins. It prevents scope creep and gives everyone a shared reference point.

    Tip: Write your research questions as 'how' and 'what' questions, not 'do' or 'should' questions. The former invite exploration; the latter invite premature validation.

  2. Step 2: Conduct Desk Research to Map the Landscape

    Start with secondary research before spending time and budget on primary research. Review existing data: analytics, support tickets, previous research reports, competitor analyses, industry reports, academic papers, and market data. This gives you a baseline understanding and helps you avoid asking users questions you could have answered yourself.

    Organize your desk research into themes: user demographics and behaviors, market trends, competitive landscape, analogous domains (industries facing similar challenges), and technology constraints. Use a simple spreadsheet or Miro board to capture sources, key findings, and open questions that emerge.

    Desk research typically takes 2-5 days depending on the domain. The goal is not exhaustive coverage but sufficient context to make your primary research conversations much sharper.

    Tip: Don't just research your direct competitors. Look at analogous experiences in adjacent industries—they often reveal more innovative patterns than your immediate competitive set.

  3. Step 3: Plan and Conduct User Interviews

    User interviews are the backbone of discovery research. Plan for 8-15 interviews across different user segments to reach thematic saturation. Recruit participants who represent the diversity of your user base, including edge cases and non-users who chose alternatives.

    Write a semi-structured interview guide with 8-12 open-ended questions organized around your research themes. Start broad ('Tell me about the last time you...') and progressively drill deeper. Leave room for follow-up questions—the best insights often come from the unexpected tangents.

    Conduct interviews in pairs when possible: one person leads the conversation, the other takes detailed notes. Record sessions (with consent) so you can revisit exact quotes later. Each interview should run 45-60 minutes. Debrief immediately after each session to capture top-of-mind observations while they're fresh.

    Tip: Ask about specific past experiences, not hypothetical futures. 'Tell me about the last time you had this problem' yields far richer data than 'Would you use a product that does X?'

  4. Step 4: Observe Users in Context

    Contextual observation (sometimes called ethnographic fieldwork or contextual inquiry) means watching people in their natural environment as they encounter the problem you're exploring. This method reveals the gap between what people say they do and what they actually do.

    Depending on your domain, this might mean visiting a workplace, shadowing a customer through a service journey, or conducting a diary study where users document their experiences over days or weeks. If in-person observation isn't feasible, remote methods like screen recordings, photo diaries, or video ethnography can substitute.

    During observation, capture everything: the environment, tools and artifacts in use, workarounds, interruptions, emotional cues, and interactions with others. Avoid interpreting in the moment—just record. You'll make sense of it later in the Define phase.

    Tip: Bring a camera (with permission). Photos and short video clips are far more persuasive to stakeholders than written notes, and they help the team remember context weeks later.

  5. Step 5: Engage Stakeholders and Subject Matter Experts

    Don't limit your discovery to end users. Interview internal stakeholders (product owners, customer support leads, sales teams, engineers) and external subject matter experts. Each group holds a different piece of the puzzle.

    Customer support and sales teams are goldmines—they hear user complaints and requests daily. Engineers often understand technical constraints that shape what's possible. Business stakeholders articulate the strategic context and success metrics.

    Prepare different interview guides for each group. With stakeholders, focus on business goals, known pain points, and what success looks like. With subject matter experts, explore domain nuances, emerging trends, and historical context that shapes user behavior.

    Tip: Stakeholder interviews early in discovery also build buy-in. People who feel heard during research are far more likely to champion the findings later.

  6. Step 6: Capture and Organize Raw Findings

    As research progresses, you'll accumulate a large volume of raw data: interview transcripts, observation notes, screenshots, quotes, statistics, and artifacts. Resist the urge to synthesize prematurely—that's the Define phase's job—but do organize your data so it's accessible.

    Create a research repository using tools like Notion, Dovetail, or even a shared Google Drive. Tag findings by source, participant, theme, and research question. Pull out verbatim quotes and notable observations onto sticky notes (physical or digital) for later affinity mapping.

    At the end of each research week, write a brief 'research pulse' update for stakeholders: what you've done, emerging themes (explicitly labeled as preliminary), and what's coming next. This keeps the team engaged and prevents the 'research black hole' problem where weeks pass with no visible output.

    Tip: Use a consistent tagging system from day one. Retrofitting tags onto hundreds of notes after the research is complete is painful and error-prone.

  7. Step 7: Assess Coverage and Close the Discover Phase

    Before transitioning to the Define phase, review your research against the original brief. Have you explored each research question from multiple angles? Are there user segments or contexts you haven't reached? Are you hearing new themes, or have responses started to repeat (thematic saturation)?

    If gaps remain, prioritize and fill them with targeted follow-up—a few more interviews, a specific piece of desk research, or a quick observational session. If you've reached saturation across your key questions, you're ready to move into synthesizing insights to define the problem.

    End the Discover phase with a research share-out: a 30-60 minute session where the team presents raw findings, favorite quotes, surprising moments, and open questions. This isn't a polished presentation—it's a shared immersion experience that prepares everyone for synthesis.

    Tip: Create a 'parking lot' for interesting findings that fall outside your current scope. They're valuable for future projects and prevent you from expanding scope in the current one.

Examples

Example: Discovery Research for a Healthcare Appointment Booking System

A digital health company wants to improve how patients book specialist appointments. The product team suspects the current system is frustrating but doesn't know exactly where it breaks down or for whom. They have 3 weeks for the Discover phase.

The team starts by framing a research brief with three open questions: How do patients currently navigate the referral-to-appointment journey? What role do caregivers and admin staff play? Where do patients abandon or find workarounds?

Week 1 focuses on desk research: they analyze 6 months of support tickets (finding that 40% relate to appointment confusion), review competitor booking flows, and read published research on healthcare access barriers.

Week 2 involves 12 user interviews across three segments: tech-savvy patients who self-manage, elderly patients with caregiver support, and patients in rural areas with limited specialist access. They also interview 4 clinic admin staff who handle booking on the backend.

Week 3 includes contextual observation: two team members shadow patients through actual appointment booking at two clinics, noting that physical paperwork and phone calls still dominate despite a digital system being available. They also observe an admin processing 30 appointments in a morning shift.

By the end of week 3, the team has 200+ tagged observations, 16 interview transcripts, and a landscape analysis. They hold a 45-minute research share-out where they present raw findings, play three powerful audio clips, and identify preliminary tension areas—but explicitly label these as 'areas to explore in synthesis, not conclusions.' The team is now ready to move into the Define phase with a shared, evidence-based understanding of the problem space.

Example: Discover Phase for an Internal Collaboration Tool

A 500-person company's leadership believes their teams collaborate poorly and wants to invest in better tooling. A design team is asked to explore the collaboration problem before any specific solution is considered.

The team writes a brief focused on understanding how cross-functional teams actually collaborate today, what friction points exist, and what 'good collaboration' means to different roles.

For desk research, they pull data from existing tools—Slack message volumes, meeting frequency analytics, project management tool usage patterns—and review internal engagement survey results highlighting communication as a pain point.

They conduct 10 interviews across engineering, marketing, sales, and operations, using role-stratified recruitment. They discover that 'collaboration problems' mean completely different things to different teams: engineers want fewer meetings, marketers want faster feedback loops, and sales wants visibility into product timelines.

For observation, they sit in on four different team meetings and two cross-functional handoff moments, documenting communication patterns, tool-switching behavior, and information loss at handoff points.

The discovery reveals that the problem isn't tooling—it's misaligned expectations about communication norms. This insight, surfaced through divergent exploration rather than premature solution design, fundamentally reframes the project scope before the team enters the Define phase.

Best Practices

  • Triangulate every important finding across at least two different research methods before treating it as a strong signal—interviews, observation, and data should corroborate each other.

  • Recruit for diversity, not convenience. Seek out extreme users, non-users, and edge cases alongside your core audience—they reveal design opportunities that mainstream users can't articulate.

  • Timebox your Discover phase explicitly (typically 2-4 weeks) and communicate the timeline to stakeholders. Open-ended research without a deadline leads to analysis paralysis.

  • Separate data collection from interpretation. During interviews and observation, focus on capturing what people say and do. Save your 'what it means' analysis for dedicated synthesis sessions.

  • Involve at least one non-researcher team member (engineer, PM, or business stakeholder) in live research sessions. First-hand exposure to users builds empathy that no report can replicate.

  • Document your assumptions before starting research. Revisit them at the end of discovery to see which were confirmed, challenged, or completely overturned—this makes the value of research tangible to stakeholders.

Common Mistakes

Jumping to solutions during discovery conversations—asking users 'Would you like feature X?' instead of exploring their actual behaviors and pain points.

Correction

Keep your interview guide focused on past experiences and current behaviors. Ban solution-oriented questions from the Discover phase entirely. You'll ideate in the Develop phase.

Relying on a single research method, typically just user interviews, and treating those findings as the complete picture.

Correction

Use at least three different research methods (e.g., interviews + observation + desk research) to triangulate findings. Each method has blind spots that others compensate for.

Interviewing only the most accessible or vocal users, which creates a skewed understanding of the problem space.

Correction

Build a deliberate recruitment screener that ensures representation across user segments, including reluctant participants, churned users, and people who chose competitor products.

Synthesizing too early—clustering findings into themes after just 3-4 interviews and then using remaining interviews to confirm those early patterns.

Correction

Stay in divergent mode throughout the Discover phase. Do post-session debriefs to capture reactions, but save formal synthesis (affinity mapping, theme creation) for the Define phase after all research is complete.

Producing a 50-page research report that no one reads, effectively wasting the research investment.

Correction

Favor lightweight, shareable formats: a wall of categorized sticky notes, a 10-minute video highlight reel of user quotes, or a 2-page summary with links to the raw data repository.

Frequently Asked Questions

How many user interviews should I conduct in the Discover phase of the double diamond design process?

Plan for 8-15 interviews across different user segments. Research shows thematic saturation typically occurs around 12 interviews for a well-defined domain. If you're exploring a broad or unfamiliar problem space, lean toward the higher end. Quality of recruitment matters more than raw numbers.

What's the difference between the Discover phase and the Define phase in the double diamond?

The Discover phase uses divergent thinking to broadly explore and gather raw data about the problem space. The Define phase uses convergent thinking to synthesize those findings into a clear problem statement. Discover expands your understanding; Define narrows it to an actionable focus.

How long should the Discover phase take in a double diamond design process?

Typically 2-4 weeks depending on project complexity, access to users, and team size. A focused sprint with dedicated researchers can accomplish meaningful discovery in 2 weeks. Larger or more ambiguous problem spaces may need 4-6 weeks. Always timebox to prevent scope creep.

Can I skip desk research and go straight to user interviews?

You can, but you'll waste interview time asking questions that existing data already answers. Desk research gives you baseline context and sharpens your interview questions. Even 2-3 days of secondary research significantly improves the quality of your primary research conversations.

How do I convince stakeholders to invest time in discovery research instead of jumping to solutions?

Frame discovery research as risk reduction: it costs far less to spend 2-3 weeks understanding the problem than to build the wrong solution and rework it. Share examples of projects where skipped discovery led to costly pivots. Involve stakeholders in research sessions so they experience user pain firsthand.

What tools are best for organizing discovery research findings?

Dovetail and Condens are purpose-built for research repositories with tagging and analysis. Miro and FigJam work well for collaborative note capture and affinity mapping. For simpler setups, a well-structured Notion database or Google Sheets with consistent tagging is perfectly effective. Choose based on team size and budget.