From a Wall of Notes to One Sentence

Eight interviews done, two hundred sticky notes on the wall, everyone in the room nodding. Two weeks later the team is building exactly what it had planned before the research started, and someone has produced a slide showing that users, in fact, wanted precisely that.

Nothing was faked. This is simply what happens when research is collected but never converted. Notes are not findings, findings are not insights, and insights are not a task anyone can start on. This article is about the three conversions in between.

The dangerous middle

The move from raw material to conclusion is the one place in the process where you can quietly get anything you like out of the data. Confirmation bias does its best work here: two hundred notes contain support for almost any position, and the honest-feeling act of "pulling out the themes" is exactly where a predetermined answer sneaks back in.

Two protections, both cheap:

Write your expectations down before you synthesise. Then you can see which conclusions were already in your head, and hold them to a higher standard than the rest.

Do it with someone else, from the raw notes. Not from your summary — your summary is already an interpretation. Two people grouping the same raw material will disagree, and the disagreements are the interesting parts.

Affinity mapping

The standard technique comes from Jiro Kawakita, a Japanese anthropologist who developed the KJ method in the 1960s for exactly this problem: turning a mass of field observations into structure without deciding the structure in advance.

The procedure is nearly mechanical, which is its virtue:

One observation per note. Something that happened or was said — not your conclusion about it. "Kept a separate spreadsheet of order numbers," not "wants better search."
Spread them all out. Physically, or on a board. Everything visible at once.
Group bottom-up, silently at first. Put together the notes that feel related, without arguing and without pre-made categories. If you start with categories you'll find them.
Name each group with a sentence, not a word. "Onboarding" is a filing label. "People start with data they already have somewhere else, and we ask them to type it in fresh" is a finding.
Look for the groups that surprise you. The pile you didn't expect is worth more than the four you did.

That fourth step is the one that separates real synthesis from tidying up. A one-word label lets everyone keep their own private interpretation. A sentence forces the group to agree on something that could be wrong.

Observation → pattern → insight → problem

Four levels, and it's worth being strict about which one you're holding.

Observation — a single thing that happened. "She copied the order number into a notepad before opening the form."

Pattern — the same thing across several people. "Six of eight kept order numbers outside the system."

Insight — the explanation, and it has to be non-obvious. "The form is the only place the number is visible, and it's cleared on submission — so people cache it manually because the system forgets."

Problem statement — the insight framed as a task with a criterion. "People lose their reference number at the moment they most need it. After the fix, no one should need to write anything down between steps."

The test of an insight is uncomfortable and useful: would it change what someone builds? "Users want it to be faster and simpler" passes no test — nobody was arguing for slower and more complicated. If your finding could not have come out the other way, it isn't a finding.

If the opposite conclusion was never possible, you haven't learned anything.

Jobs to be done

A framing tool worth having, popularised by Clayton Christensen with the milkshake story: a fast-food chain trying to sell more milkshakes discovered that a large share were bought before 9 a.m. by lone drivers. The job wasn't dessert. It was keep one hand occupied and stave off hunger through a boring commute — competing not with other desserts but with bananas, bagels and doughnuts.

The value is that it names the situation, not the person. A job statement has a fixed shape:

When I ___ [situation], I want to ___ [motivation], so I can ___ [expected outcome].

"When I'm handed a report five minutes before a meeting, I want to see what changed since last time, so I can speak about it without reading it all." That sentence tells a designer what to build far more directly than any description of the person's age or job title.

Personas, honestly

Alan Cooper introduced personas in 1998, and they're now the most abused artefact in the field.

A bad persona is a stock photo, an invented name, an age, a marital status and three hobbies, none of which affect a single design decision. It's a fiction that makes a team feel research-adjacent.

A good persona is behavioural and built from data: what this group is trying to do, how often, with what skill level, under what constraints, with what alternatives available. Age appears only if age actually changes the design.

The honest recommendation: if you're not going to build them from real observations, skip them. A short list of behavioural segments — "first-timers setting this up alone," "people processing forty of these a day" — does the same job with less theatre and lies less.

Journey maps carry the same warning. A map of stages, actions, thoughts, pain points and opportunities is genuinely powerful for finding the gaps between screens, where most bad experiences live. Built from imagination, it's an expensive drawing of your own assumptions.

Framing the problem

The final conversion turns an insight into something a team can start on today.

A workable problem statement has four parts: who, in what situation, what's blocking them, and how you'll know it's fixed. That last part is what stops a problem statement from being a mood.

Then How Might We — a phrasing from Sidney Parnes' work on creative problem solving, later adopted at IDEO and now everywhere. It reopens a problem for solutions without prescribing one. It has two failure modes, and both are common:

Too broad — "How might we improve the experience?" produces nothing usable.
A solution in disguise — "How might we add a progress bar to checkout?" has already decided.

Right-sized: "How might we let people leave checkout and come back without losing their place?" Constrained enough to work on, open enough to have several answers.

Finally, prioritise before you design, because research always produces more problems than you can solve. Nielsen's severity rating works well: score each problem on frequency (how many people hit it), impact (how badly it hurts when they do) and persistence (whether they get past it after learning, or hit it every single time). Persistence is the one people forget — a problem people never learn around is worth more attention than a scarier one they route past after the first week.

In practice

One observation per note, in their words. No conclusions on notes. The discipline sounds petty and is the whole difference between synthesis and confirmation.

Name every group with a full sentence. If you can't write one, the group isn't a finding yet.

Apply the reversal test. Take each conclusion and state its opposite. If the opposite is absurd, delete the conclusion — it's a truism wearing a lab coat.

Write your assumptions before the wall goes up. Then mark which conclusions matched them and be suspicious of those specifically.

Turn one insight into a job statement. When I ___, I want to ___, so I can ___. If you can't fill the third slot, you have a behaviour but not a motive.

Score the problems before touching a design tool. Frequency, impact, persistence. Then take the top one. The list you deliberately postponed is a deliverable too.

Check yourself

Close the article and answer in your own words:

Why is synthesis the most dangerous step for bias, and what two habits protect it?
What's the difference between naming a group with a word and naming it with a sentence?
Give an example of the chain observation → pattern → insight → problem from your own product.
What is the reversal test and what does failing it mean?
What does a job statement capture that a persona usually doesn't?
What separates a good persona from a bad one, and when should you skip them entirely?
Why is persistence the most easily forgotten part of a severity score?

In short

Research that never converts into a decision is a hobby. Notes → findings → insights → a stated problem.
Synthesis is where confirmation bias operates. Write your expectations first and group raw notes with someone else.
Affinity mapping (the KJ method): one observation per note, group bottom-up without pre-set categories, name each group with a sentence.
An insight must be able to have come out the other way. "Users want it faster" is not a finding.
Jobs to be done names the situation, not the person: when I ___, I want to ___, so I can ___.
Personas are only worth building from behaviour and data; otherwise use behavioural segments. Journey maps built from imagination are expensive drawings of your assumptions.
Frame the problem with who, when, what blocks them and how you'll know. Prioritise by frequency, impact and persistence.