Synthesizing Insights to Define the Problem

Synthesize discovery findings into themes, insights and one agreed problem statement to define the problem in the Double Diamond Define phase.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

Synthesizing insights to define the problem is the work of the Define phase, the convergent half of the first diamond in the Double Diamond. Discover leaves the team with a large, untidy body of evidence. Define reduces it to a clear statement of which problem the second diamond will work on, for whom, and why.

The Design Council puts it simply: the insight gathered in discovery "can help you to define the challenge in a different way" (Framework for Innovation). Its earlier study of design in large companies described Define as the stage where user needs are interpreted and aligned with business objectives, with project development, management and sign-off as its key activities and a project brief as its outcome (Eleven lessons).

The inputs are raw findings with their sources, the original challenge, and knowledge of the organisation's constraints and goals. The outputs are a set of themes, a short list of insight statements, one chosen problem statement, a few "How might we" questions to open the Develop phase, and a record of which evidence supports the choice.

Define is where many projects quietly go wrong. Teams under time pressure jump from findings to a feature list, or they write a problem statement that is really a solution in disguise ("users need a dashboard"). Others produce a statement so broad ("improve the customer experience") that it rules nothing out. A good definition is narrow enough to tell the team where to start and open enough to allow several different solutions.

This skill covers how to organise findings, move from observations to insights, choose among competing problems, write the statement, and get it agreed.

How It Works

Synthesis moves up a ladder of abstraction in three rungs: observations, themes and insights.

Observations are what the research recorded: a quote, a behaviour, a data point. Themes are groups of observations that share something. Insights explain a theme: why the pattern exists and what it means for the people involved. An insight is usually a sentence with a tension in it, such as "Patients trust the paper letter more than the portal, so they phone to confirm what the portal already shows."

The standard tool for the first climb is affinity diagramming, which the Nielsen Norman Group defines as organising related observations, ideas or findings into distinct clusters, and runs in three steps: write findings on individual notes, cluster and label them, then prioritise clusters and next steps (NN/g on affinity diagramming). The same article notes that the conversations during clustering matter more than the finished board, because that is where the team builds a shared reading of the evidence.

Clustering is a group activity for a reason. Individuals tend to see the themes they expected. A mixed group that argues about where a note belongs surfaces alternative readings, and the arguments are often where insights come from. Expect a stretch where the board feels chaotic and nobody agrees. Facilitators call this the "groan zone," after Sam Kaner's diamond of participation, and it is a normal part of moving from divergent to convergent thinking (i2Insights on the groan zone).

Choosing the problem is a separate decision from finding insights. Several insights may each point to a worthwhile problem. Judge them on how much evidence supports each one, how severe and widespread the problem is for the people affected, whether it is within the organisation's reach, and how it relates to the goals that funded the work. The chosen problem may not be the one in the original brief.

The problem statement is then rewritten as questions that open the next diamond. IDEO.org's Design Kit recommends turning insight statements into "How might we" questions that suggest a solution is possible without prescribing one (Design Kit on How Might We). The Nielsen Norman Group warns against questions that embed a solution, target a symptom, or are framed negatively (NN/g on HMW questions).

Step-by-Step Guide

Step 1: Get every finding into one place

Collect notes, quotes and observations from all Discover activities into one board or sheet, one finding per note, each with its source and segment. Read through as a team before sorting anything so everyone has seen the whole set. Remove duplicates but keep near-duplicates from different sources, since repetition across sources is evidence. Flag findings that came second-hand so they carry less weight later.

Step 2: Cluster findings into themes

Sort the notes into groups by similarity, in silence at first, then discuss the groups that are contested. Name each cluster with a sentence that says what the notes have in common, since single-word labels such as "Trust" hide the actual pattern. Split clusters that are really two ideas and merge ones that overlap. The NN/g affinity diagramming guide describes this generate, cluster and prioritise sequence in detail. Stop when new rearrangements no longer change the story.

Step 3: Write insight statements

For each important theme, write one or two sentences that explain why the pattern exists and what tension it creates for people. Test each insight against the evidence: point to the notes that support it and check whether any contradict it. Discard insights that restate the theme without explaining it. Aim for a short list, since a long one usually means the team has not yet converged.

Step 4: Choose the problem to take forward

List the candidate problems your insights point to. Compare them on strength of evidence, severity and reach for the people affected, fit with organisational goals, and whether the team can act on them. A simple grid with those criteria as columns keeps the discussion concrete. Make the choice explicit and note which problems you are setting aside, so they are not lost.

Step 5: Write the problem statement

Describe who is affected, what they are trying to do, what gets in the way, and why it matters, in a few sentences with no solution in them. Check it against three tests: it is backed by the evidence, it rules some solutions out, and it leaves more than one solution open. Rewrite until a person who missed the research can understand it.

Step 6: Turn the statement into "How might we" questions

Write several "How might we" questions from the problem statement and the key insights. Keep them at a scope that suggests where to start without prescribing an answer, as IDEO.org's Design Kit recommends. Remove any that contain a solution ("How might we build an app that...") or a negative frame. Pick a few to open the Develop phase.

Step 7: Get the definition agreed and recorded

Walk the sponsor and the people who will build the solution through the evidence, the insights and the statement. Ask them to challenge it now. Once agreed, record the statement, the supporting evidence and the rejected alternatives in one place the whole team can find. This is the reference every idea in the second diamond will be judged against.

Best Practices

• Synthesise with the people who did the research. Notes lose context. The people who ran the sessions remember tone, hesitations and what was not said.
• Keep evidence attached to every insight. Each insight should link back to the notes that support it, which makes it defensible when a stakeholder disagrees.
• Write cluster labels as sentences. "Patients phone to double-check online bookings" carries meaning. "Trust" does not.
• Look for contradictions as well as patterns. A finding that does not fit may point to a segment you missed or a flaw in your reading.
• Allow the problem to change. If the evidence points away from the original brief, say so plainly and show why.
• Time-box the discussion but not the thinking. Fix session lengths, and allow a gap between sessions so the team can reflect before choosing.

Common Mistakes

• Writing a solution as the problem: "Users need a better dashboard" names an output. Rewrite it around what users are trying to do and what blocks them, and leave the dashboard as one possible answer.
• Choosing a problem so broad it rules nothing out: "Improve customer experience" gives the Develop phase no direction. Narrow it to a specific group, situation and obstacle.
• Letting one vivid quote drive the definition: A memorable story can outweigh a pattern across many sessions. Check each insight against the full set of notes.
• Synthesising alone: A single analyst's reading carries a single set of biases. Cluster as a group and argue about contested notes.
• Skipping sign-off: An unagreed problem definition comes back as disputes about solutions. Get explicit agreement before opening the second diamond.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Double Diamond

Related Skills

• Conducting Discovery Research in the Double Diamond
• Facilitating Divergent Ideation in the Double Diamond
• Converging on Final Solutions in the Deliver Phase
• Double Diamond Thinking: Divergent and Convergent Modes
• How to Create a Double Diamond Diagram
• Double Diamond vs Design Thinking: Choosing a Framework
• Adapting the Double Diamond UX Framework for Design Projects

Sources

• Design Council: Framework for Innovation
• Design Council: Eleven lessons, managing design in eleven global brands
• NN/g: Affinity Diagramming
• i2Insights: Collaboration, from groan zone to growth zone
• IDEO.org Design Kit: How Might We
• NN/g: Using How Might We Questions

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.