How product designers turn qualitative and quantitative research into insights, opportunities, and stronger decisions.

On a trip to East Java, Cahyadi once watched people separate tiny grains of gold from river sediment.

From a distance, the work looked almost impossible. Each pan held water, mud, dark sand, pebbles, and fragments that caught the light for only a second. The valuable material did not arrive labeled. It was mixed with everything else.

The person holding the pan did not simply remove random stones. He tilted it, moved the water in a controlled circle, watched how materials behaved, and repeated the motion. Slowly, what was lighter washed away. What was heavier remained.

Years later, Cahyadi remembered that image while standing in front of a wall covered with research notes.

His product team had interviewed eighteen merchants, reviewed hundreds of support tickets, studied transaction funnels, and collected feedback from sales teams across several cities. The wall was full. The shared drive was fuller. Everyone had learned something, but nobody could agree on what the research meant.

One sticky note said, “Settlement is too slow.” Another said, “Merchant checks balance every morning.” A dashboard showed fewer active users after the first week. A sales manager insisted that education was the problem. Customer support believed confusing status labels were responsible.

The team had information. They did not yet have insight.

The ability to turn scattered evidence into a meaningful point of view is called Synthesize Information.

🪨 A Pile of Notes Is Not an Insight

The team’s first research readout was eighty slides long. Each interview had a summary. Every chart was carefully labeled. Quotes were grouped by participant. Nobody could say what decision should change.

This is a common trap. We confuse organized information with synthesized understanding.

A summary tells us what was said or observed. Synthesis asks what the pieces might mean together.

It involves looking across sources, noticing patterns and contradictions, forming interpretations, and expressing a point of view that can guide action. This is not a purely mechanical step. Designers use judgment to decide what to connect, what to separate, and which explanation is most useful to investigate.

Cahyadi returned to the wall with a smaller group. Instead of arranging notes by participant, they arranged them by moments in the merchant’s week: receiving payments, checking status, paying suppliers, reconciling records, and resolving exceptions.

The shape of the problem changed.

“Settlement is too slow” was not always about transaction speed. For some merchants, the deeper issue was not knowing when money would become usable. They had supplier payments due and needed certainty more than raw speed.

The team had begun to sift meaning from description.

🔍 Look for Patterns, Then Look for What Breaks Them

Pattern recognition is central to synthesis, but frequency alone does not determine importance.

Ten participants may mention a minor inconvenience, while one unusual case exposes a structural problem. A strong pattern can reveal a shared need. An exception can reveal the boundary of the team’s current explanation.

Cahyadi’s team noticed that many merchants checked their balance several times after a busy sales period. The initial interpretation was simple: merchants wanted real-time balance updates.

Then one participant did something different. She maintained a handwritten notebook beside the cashier and compared it with the app at closing time. When amounts did not match, she did not contact support immediately. She waited until the next day because she believed pending money might “move by itself” overnight.

That behavior suggested a different issue. The product displayed numbers, but it did not help merchants form a reliable mental model of pending, available, and settled funds.

The team rewrote the pattern:

Not “merchants repeatedly check balance.”

But “when the movement of money is unclear, merchants create repeated checking and manual records to regain a sense of control.”

The second statement connects behavior, context, and an underlying need. It is more actionable because it suggests several possibilities without prescribing one feature.

🌊 Move Between Data and Interpretation

Synthesis becomes dangerous when interpretation floats away from evidence. It also becomes weak when teams refuse to interpret anything that cannot be counted.

The useful movement is back and forth.

Cahyadi’s team placed quantitative and qualitative evidence beside each other. Funnel data showed that many merchants stopped opening the app after the first month. Interviews revealed that some merchants used the app intensely only when a payment was disputed. Support tickets showed repeated confusion about similar status terms. Field observation revealed handwritten reconciliation practices.

Together, the sources supported a stronger hypothesis: the product was built as a transaction viewer, while merchants were trying to use it as a tool for financial certainty.

That hypothesis was not a proven universal truth. It was the best current explanation connecting multiple observations.

Design reasoning often works this way. We encounter surprising facts and ask what might explain them. We form a plausible interpretation, then return to the world to test whether it holds. This possibility-oriented reasoning is sometimes called abductive reasoning.

The phrase matters less than the habit: do not wait for the answer to appear automatically from the notes. Build an explanation, make its assumptions visible, and test it.

🥇 Gold Does Not Shine Until the Mud Moves

During the workshop, Cahyadi asked everyone to write one possible meaning for the same cluster of evidence. The product manager wrote, “Merchants need faster settlement.” A researcher wrote, “Merchants need predictable access to funds.” A designer wrote, “Merchants cannot see the journey of money.” A sales colleague wrote, “Merchants need language they can explain to employees.”

None of these statements was accepted immediately.

The team compared each interpretation against the evidence. Which observations did it explain? Which did it ignore? What would the team expect to see if it were true? What research or experiment could challenge it?

This prevented the most senior voice from becoming the automatic conclusion. It also prevented synthesis from becoming an aesthetic exercise in arranging colorful notes.

Eventually, the team developed three insight statements:

  1. Merchants value predictability because supplier commitments make uncertain timing more stressful than a known delay.
  2. Status labels describe the system’s internal state, but merchants think in terms of whether money can be used and what action is needed.
  3. When the product does not provide a trustworthy explanation, merchants create parallel records and repeated checks.

These insights gave the team a direction without locking it into a single interface.

🧩 Turn Insight Into an Opportunity, Not a Feature Order

A useful insight changes what the team can imagine.

If the conclusion had been “add a faster settlement button,” the solution space would have narrowed too soon. Instead, the team asked:

How might we help merchants understand where their money is, when it will become usable, and what they can do when something changes?

That opportunity led to several concepts: a clearer money timeline, plain-language status explanations, expected availability dates, proactive notifications, and a guided exception path. Some ideas involved interface changes. Others required policy, data, or operational coordination.

Synthesis had revealed that the experience was larger than the screen.

This is why insight statements should not merely repeat complaints. “Users find status confusing” is a problem description. “System-centered labels prevent merchants from connecting transaction states to the decisions they must make” offers a more generative point of view.

The purpose is not to sound clever. The purpose is to help a team see possibilities that were previously hidden.

⚖️ Synthesis Is a Point of View With Receipts

Designers sometimes worry that interpretation introduces bias. It does. So does deciding which metric to display, which participant to recruit, and which question to ask.

The answer is not to pretend interpretation can disappear. The answer is to make it accountable.

Cahyadi documented the evidence behind each insight, the cases that did not fit, the assumptions still uncertain, and the next questions to investigate. The team could trace a strategic statement back to observable material.

This made disagreement productive. A stakeholder could challenge the connection between evidence and interpretation instead of simply saying, “I do not like this conclusion.”

A strong synthesis is neither raw data nor unsupported intuition. It is a reasoned point of view that remains close enough to the evidence to be examined and flexible enough to evolve.

🏞️ What Remains in the Pan

At the end of the week, most sticky notes were no longer on the wall. They had not been thrown away. They had been absorbed into patterns, insights, opportunity areas, and open questions.

Cahyadi remembered the river pan. The gold had always been present, but value emerged only through careful movement. Too gentle, and nothing separated. Too forceful, and something important could be washed away.

Research synthesis requires the same patience. We stay close to the material, move it into new relationships, notice what remains, and resist falling in love with the first thing that shines.

The goal is not to reduce complexity until the story becomes simple. It is to create enough clarity that a team can act without pretending the complexity was never there.

When your research repository feels full but your direction still feels empty, do not ask only, “What did people say?”

Ask, “What becomes possible if these pieces mean something together?”

🧺 Takeaways to Bring Into Your Next Project

  • A collection of notes is information. Synthesis turns it into a reasoned point of view.
  • Reorganize evidence across people, moments, behaviors, and contexts to reveal new relationships.
  • Study both recurring patterns and the exceptions that challenge them.
  • Move back and forth between evidence and interpretation instead of treating either as sufficient alone.
  • Write insights that connect behavior, context, tension, and underlying meaning.
  • Make interpretations traceable, testable, and open to revision.
  • Use insight to open opportunity spaces, not to disguise a predetermined feature request.

P.S. Next up:

“Rapidly Experiment: Like a Chef Testing Small Portions Before Serving the Full Menu” 👀

🔗 About This Series

This is article 3 of Designerly Thinking: Eight Core Design Abilities, followed by a reflection epilogue. The abilities come from the Stanford d.school and are not intended as a rigid sequence.

  1. Design Your Design Work: Like Setting Up Your Kitchen Before You Cook
  2. Learn from Others: Like Watching a Barista Who Knows Your Order and Your Mood
  3. Synthesize Information: Like Sifting Gold from Sand to Find Meaning in Messy Research
  4. Rapidly Experiment: Like a Chef Testing Small Portions Before Serving the Full Menu
  5. Move Between Concrete and Abstract: Like a Doctor Connecting Symptoms to the Larger System
  6. Build and Craft Intentionally: Like a Watchmaker Engineering Every Gear
  7. Communicate Deliberately: Like a Diplomat Aligning Allies in a High-Stakes Room
  8. Navigate Ambiguity: Like a Captain Forging the Route Through the Fog
  9. Reflection: Like a Warung After Closing, Turning a Busy Day into Better Judgment

Synthesize Information: Like Sifting Gold from Sand to Find Meaning in Messy Research 🏞️ was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.