Synthesizing Insights to Define the Problem in the Double Diamond Framework

This skill teaches you how to apply convergent thinking in the Define phase of the double diamond framework — analyzing discovery findings, clustering themes, and crafting a precise problem statement that focuses your team on the right challenge.

To synthesize insights in the double diamond framework's Define phase, cluster your discovery research into themes using affinity mapping, identify patterns and tensions across findings, then craft a focused problem statement (such as a "How Might We" or point-of-view statement). Prioritize based on user impact and feasibility, and validate the framing with stakeholders before moving into ideation.

Outcome: You'll be able to transform messy, divergent research data into a single, well-framed problem statement that aligns your team and sets up effective ideation in the Develop phase.

Synthesized from public framework references and reviewed for accuracy.

ProductIntermediate2-4 hours per synthesis session

Prerequisites

  • Completed discovery research with raw findings
  • Familiarity with the double diamond framework's four phases
  • Basic understanding of divergent vs. convergent thinking
  • Affinity mapping or thematic analysis basics

Overview

The Define phase is the critical convergent moment in the first diamond of the double diamond framework. After the Discover phase has expanded your understanding through broad research, the Define phase demands the opposite: ruthless narrowing. You must take everything you learned — interview transcripts, observation notes, survey data, competitive analysis — and distill it into a single, actionable problem statement that your team will carry into the second diamond.

This skill is where many teams stumble. It's tempting to skip synthesis and jump straight to solutions, or to define the problem too broadly ("improve the user experience") or too narrowly ("add a search bar"). Effective problem definition requires a structured convergent thinking process: clustering raw data into themes, identifying the most significant patterns and tensions, and then framing the challenge in a way that is specific enough to act on but open enough to allow creative solutions.

Mastering this skill is essential because the quality of your problem statement directly determines the quality of everything that follows. A well-synthesized problem definition aligns stakeholders, focuses ideation, and provides a clear success metric. Within the double diamond framework, the Define phase output — often called a design brief or problem statement — is the hinge between understanding the problem space and exploring the solution space.

How It Works

Convergent thinking in the Define phase works by progressively reducing complexity. You start with a large volume of raw research findings — potentially hundreds of data points from the Discover phase — and apply a series of analytical filters to identify what matters most.

The process follows a funneling logic. First, you organize data spatially (affinity mapping) so that natural clusters emerge. Then you name those clusters as themes — these are the recurring patterns, needs, pain points, or behaviors that showed up across multiple sources. Next, you evaluate these themes through lenses like user impact, business relevance, and feasibility to prioritize which themes represent the most important challenge to solve.

Finally, you articulate the chosen challenge as a problem statement. The most common formats are "How Might We" (HMW) questions, point-of-view (POV) statements, or design briefs. Each format serves a slightly different purpose: HMW questions open up ideation, POV statements ground the problem in a specific user's experience, and design briefs provide comprehensive context for the team.

The key insight is that synthesis is not just summarization. You are not creating a research report — you are making an interpretive leap. You are deciding, based on evidence, what the real problem is. This requires both analytical rigor (what does the data actually say?) and design judgment (which framing will lead to the most impactful solutions?).

Step-by-Step

  1. Step 1: Gather and Externalize All Discovery Findings

    Before synthesis can begin, you need all your research outputs visible and accessible. Print transcripts, export survey results, gather observation photos, and write individual findings on sticky notes (physical or digital). Each sticky note should capture one discrete observation, quote, or data point — not an interpretation.

    The goal is to get everything out of people's heads and notebooks and onto a shared surface. If you conducted research as a team, have each researcher independently write their findings before the group session. This prevents groupthink and ensures the full breadth of Discover-phase data is represented.

    Aim for quantity at this stage. A typical synthesis session for a medium-complexity project might start with 80–200 individual data points.

    Tip: Use a consistent format for each note: one finding per note, include the source (e.g., 'P3 interview,' 'analytics'), and stick to observable facts rather than premature interpretations.

  2. Step 2: Cluster Findings Using Affinity Mapping

    Working as a team, begin grouping related findings together. Move sticky notes that seem to share a common thread into proximity. Don't create categories first — let the clusters emerge organically from the data. This is bottom-up analysis.

    As clusters form, you'll notice some findings belong in multiple groups, some don't fit anywhere, and some clusters naturally merge. That's normal. Keep working the wall until you have 5–12 distinct groupings. The outliers — findings that resist categorization — are often the most interesting, so don't discard them.

    This step should be done silently at first (each person placing notes independently) and then discussed as a group. Silent sorting prevents dominant voices from driving the structure prematurely.

    Tip: If you're working remotely, tools like Miro or FigJam replicate the affinity mapping experience well. Set a timer for the silent sorting phase (10–15 minutes) to maintain focus.

  3. Step 3: Name Themes and Write Insight Statements

    For each cluster, write a header that captures the underlying theme — not just a topic label, but an insight statement. The difference matters. A topic label is 'Onboarding.' An insight statement is 'New users abandon onboarding because they can't see the value before investing effort.'

    Good insight statements have three qualities: they are grounded in evidence (multiple data points support them), they reveal a tension or unmet need, and they imply a design opportunity without prescribing a solution.

    Review each theme with the team. Challenge weak themes — if a cluster only has 2-3 notes from a single source, it may not be robust enough to stand alone. Merge or deprioritize thin themes.

    Tip: Test your insight statement by asking: 'So what?' If the statement doesn't immediately suggest why it matters to users or the business, it needs sharpening.

  4. Step 4: Prioritize Themes by Impact and Feasibility

    You'll likely have more themes than you can address in a single project. Use a prioritization exercise to identify which theme represents the most important challenge. Common methods include dot voting, a 2×2 matrix (user impact vs. business value), or a forced ranking.

    Be honest about constraints. A theme might represent the biggest user pain point, but if it requires changes outside your team's control, it may not be the right focus for this cycle. The double diamond framework encourages iteration — you can return to other themes later.

    Involve stakeholders in this prioritization. Their buy-in at this stage prevents misalignment later when you present solutions. Share the evidence behind each theme so prioritization is data-driven, not opinion-driven.

    Tip: If stakeholders push for a theme that the research doesn't strongly support, don't just capitulate. Present the data clearly and negotiate — you might agree to address their preferred theme as a secondary focus.

  5. Step 5: Craft Your Problem Statement

    Take your top-priority theme and translate it into a formal problem statement. Choose the format that best fits your team's needs:

    • How Might We (HMW): 'How might we help new users see immediate value before asking them to complete a lengthy setup process?' — Best when you want to open up ideation.
    • Point of View (POV): '[User type] needs [need] because [insight].' — Best when you want to ground the problem in a specific persona.
    • Design Brief: A one-page document that includes the problem statement, key constraints, success criteria, and relevant context. — Best for larger teams or longer projects.

    Regardless of format, a good problem statement is specific (not 'improve the experience'), user-centered (rooted in a real need you observed), and solution-agnostic (it doesn't imply a particular answer).

    Tip: Write 3–5 variations of your problem statement and compare them. Read each aloud and ask the team: 'Would this inspire a brainstorm that leads to genuinely different solutions?' If they all lead to the same obvious solution, your framing is too narrow.

  6. Step 6: Validate the Problem Statement

    Before moving into the Develop phase of the double diamond framework, validate your problem statement with two audiences: the research participants (or representative users) and your project stakeholders.

    For users, this can be as simple as sharing the insight and asking: 'Does this resonate with your experience?' You're checking that your synthesis hasn't drifted from reality. For stakeholders, present the problem statement alongside the evidence trail — show how you went from raw data to themes to this specific framing.

    If validation reveals misalignment, iterate. The Define phase is not a one-shot exercise. You may need to revisit your themes, adjust prioritization, or reframe the problem statement. This iteration is a feature, not a failure — it's exactly what the convergent phase of the double diamond is designed for.

    Tip: Keep a 'problem statement changelog' — track how your framing evolved and why. This documentation is invaluable for onboarding new team members and for retrospectives.

Examples

Example: E-commerce Checkout Drop-off Synthesis

A product team completed the Discover phase for an e-commerce platform experiencing 68% cart abandonment. They conducted 15 user interviews, analyzed session recordings, and reviewed support tickets. They now have over 150 individual findings to synthesize.

The team runs a 90-minute affinity mapping session and identifies 8 clusters: shipping cost surprises, account creation friction, payment method limitations, trust/security concerns, mobile layout issues, coupon code confusion, slow page loads, and return policy anxiety.

They write insight statements for each. For example, 'Shipping cost surprises' becomes: 'Users feel deceived when shipping costs appear only at the final checkout step, after they've invested time entering their information — this breaks trust and triggers abandonment.'

Using a 2×2 prioritization matrix (user impact vs. implementation feasibility), they identify shipping cost transparency and account creation friction as the highest-impact, most-feasible themes.

They craft their problem statement: 'How might we help shoppers understand the total cost of their purchase early enough in the journey that they can make a confident buying decision without feeling surprised at checkout?'

This statement is validated with 5 users who confirm the frustration, and with the product director who confirms it aligns with the Q2 revenue retention goal. The team is now ready to enter the Develop phase of the double diamond framework with a focused, evidence-backed challenge.

Example: Internal Tool Adoption Synthesis for Enterprise

A design team at a large enterprise is tasked with improving adoption of an internal project management tool. Discover-phase research included 20 employee interviews across 4 departments, a company-wide survey (n=340), and contextual inquiry sessions observing how teams actually manage projects.

During affinity mapping, the team uncovers a surprising pattern. While the initial hypothesis was that the tool had usability problems, the strongest clusters point to organizational issues: managers don't enforce usage, teams maintain shadow spreadsheets because they don't trust the tool's data accuracy, and the tool doesn't integrate with the email-based workflows people already rely on.

The team names the dominant theme: 'Employees rationally choose not to use the tool because migrating their existing workflow carries effort and risk, while the benefits of adoption are invisible at the individual level — only management sees the aggregated data.'

They write multiple HMW variations:

  • 'How might we make the benefits of using the tool visible to individual contributors, not just managers?'
  • 'How might we reduce the effort of migrating from spreadsheet-based workflows?'
  • 'How might we make the tool's data trustworthy enough that teams voluntarily abandon their shadow systems?'

After prioritization with stakeholders, they select a combined problem statement: 'How might we make the project management tool deliver immediate, personal value to individual contributors so that adoption becomes a rational choice rather than a mandated chore?'

This reframing — from 'fix the UI' to 'fix the value proposition' — fundamentally changes the solution space for the Develop phase, demonstrating how synthesis in the double diamond framework can redirect an entire project.

Best Practices

  • Always trace your problem statement back to specific research evidence — every claim should be supported by at least 2-3 independent data points from the Discover phase.

  • Involve cross-functional team members in the synthesis session. Engineers, marketers, and customer support reps often notice patterns that designers miss because they bring different domain lenses.

  • Time-box your affinity mapping sessions (90 minutes max per session). Synthesis fatigue leads to sloppy clustering and premature convergence on the most obvious themes.

  • Write problem statements that are broad enough to allow multiple solution directions but narrow enough that you could measure whether you've addressed them. 'Reduce new user time-to-value from 12 minutes to under 3' is better than 'improve onboarding.'

  • Create a 'parking lot' for strong themes you deprioritized. These become your backlog for future double diamond cycles and prevent valuable research from being lost.

  • Separate the synthesis session from the ideation session by at least a day. Cognitive switching between convergent (Define) and divergent (Develop) thinking is hard — give your team a mental break between modes.

Common Mistakes

Jumping from raw research directly to solutions without a proper synthesis step

Correction

Force yourself to complete the full affinity mapping and theme identification process before writing any problem statement. The Define phase exists in the double diamond framework precisely because unsynthesized research leads to solving the wrong problem.

Writing problem statements that embed a preferred solution (e.g., 'How might we build a chatbot to help users find answers?')

Correction

Strip any solution language from your problem statement. Rewrite it as a user need: 'How might we help users find answers quickly without leaving their current workflow?' This keeps the solution space open for the Develop phase.

Giving equal weight to all research findings regardless of how frequently or strongly they appeared

Correction

Use a weighting system. A pain point mentioned by 8 out of 10 interview participants and confirmed by analytics data deserves more attention than a single offhand comment. Quantity of supporting evidence matters for theme robustness.

Allowing the highest-paid person's opinion (HiPPO) to override research-backed themes during prioritization

Correction

Structure your prioritization with explicit criteria (user impact, evidence strength, business alignment, feasibility) and score each theme before discussing. This makes it harder for any individual to override the data.

Defining the problem too broadly, resulting in a statement so vague it could apply to any project

Correction

Apply the 'newspaper headline test' — if your problem statement could be a headline for a completely different company's product, it's too broad. Add specificity about the user segment, context, and measurable gap until it's uniquely yours.

Frequently Asked Questions

How long should the Define phase take in the double diamond framework?

The Define phase typically takes 1–2 weeks for a medium-complexity project, including time for affinity mapping (half a day), theme refinement (1–2 days), stakeholder alignment (1–2 sessions), and problem statement validation. Rushing it undermines everything downstream.

What's the difference between a problem statement and a How Might We question?

A problem statement declares the challenge ('Users abandon checkout because shipping costs surprise them at the final step'). A How Might We question reframes that challenge as an invitation to ideate ('How might we help users understand total costs early in their journey?'). Many teams use both — the statement for alignment, the HMW for brainstorming.

How many problem statements should I produce in the Define phase?

Aim for one primary problem statement. You may generate 3–5 candidates during synthesis, but convergent thinking means narrowing to a single focus. If you can't choose, it's a sign you need sharper prioritization criteria or more data.

Can I use the double diamond framework Define phase for quantitative data, not just qualitative?

Absolutely. Quantitative data (analytics, survey scores, funnel metrics) strengthens synthesis by validating qualitative themes. The best Define-phase outputs combine 'what is happening' (quantitative) with 'why it's happening' (qualitative) into a unified problem statement.

What if stakeholders disagree with the problem statement I've synthesized?

Present the evidence trail transparently: raw findings → clusters → themes → prioritization → problem statement. If stakeholders still disagree, explore whether the disagreement is about the data interpretation or about business priorities. The latter is a legitimate input to prioritization, not a reason to discard research.

How does the Define phase in the double diamond framework differ from problem definition in design thinking?

The double diamond framework's Define phase is structurally similar to design thinking's Define stage, but it more explicitly emphasizes convergent thinking as a counterbalance to the preceding divergent Discover phase. The diamond metaphor makes the narrowing process visual and intentional, whereas design thinking frameworks sometimes treat Define as a single step rather than a deliberate convergence.