User Research Synthesis

User Research Synthesis

The Law

RESEARCH THAT DOES NOT PRODUCE A DECISION PRODUCES A DOCUMENT.
"Users said X" without "therefore we will Y" is observation without direction — the team reads the report, nods, and builds what they already planned.
An insight → decision chain, documented and traceable IS research synthesis.

When to Use

Trigger after:

• Any user interview, usability test, or survey that informs a product decision
• Any discovery sprint before a new feature is scoped
• Any moment when "what do users want?" is used to justify a direction

When NOT to Use

• Competitive analysis (no user data involved — use a different framework)
• Usage analytics review (quantitative data without qualitative context — different synthesis process)
• Research stored for reference without an active product decision being made

The Synthesis Structure

Raw research is observation. Synthesis is the translation of observation into decision. Every step below must be completed before the synthesis is done.

1 — Observations

What did users actually do, say, or show? Only direct evidence — no interpretation yet.

Observation format:
[User type], [context], [verbatim quote or behaviour]:
"[exact quote]" or "[described behaviour]"

Rules:

• Quote directly where possible — paraphrase introduces interpretation
• Include the context (what task were they doing? what were they trying to achieve?)
• Do not include "they seemed to want..." at this stage — that is interpretation

2 — Patterns

Which observations repeat across multiple users? A pattern requires at least 3 independent instances.

Pattern: [Name]
Instances: [User A, User B, User C] — each with reference to observation
Strength: strong (5+ instances) / moderate (3–4) / weak (-synthesis-.md`. This document is the evidence base for every product decision made from this research.

## Rationalization Red Flags

These thoughts mean synthesis was not completed — stop:

- *"The research speaks for itself"* — research requires interpretation; interpretation requires documentation; undocumented interpretation cannot be challenged, revised, or learned from
- *"Users want X"* — how many users? in what context? doing what task? "users want X" without these is a summary that hides the evidence
- *"We'll use this to inform future decisions"* — this means the research will not produce a decision; "inform" is the word used when research is filed and forgotten
- *"The team heard the sessions, they know the insights"* — they know their interpretation of the sessions, which differs per person; the synthesis document is what makes the interpretation shared
- *"We don't have time to synthesise, we need to move fast"* — you will spend the time anyway, debating "what users really meant" in planning meetings; the synthesis front-loads that cost

## Completion Statement Format

When user-research-synthesis is satisfied, state it like this:

Research synthesis complete. File: product/research/-synthesis-.md ✓

Sessions: Observations: ✓ Patterns:

Insights: Decisions produced: Build: Don't build: Further research:

Decision audit: insights () = decisions () ✓

Every insight must map to a decision. "Informing future work" is not a decision.

## Why This Matters

User research without synthesis produces a library of evidence for arguments that have already been decided. Teams that skip synthesis don't skip the decisions — they make them based on the most memorable quote from the sessions, which is usually the most dramatic one, not the most representative one. The synthesis document is what turns 10 hours of sessions into 3 concrete decisions.

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [RBraga01](https://github.com/RBraga01)
- **Source:** [RBraga01/builder-product](https://github.com/RBraga01/builder-product)
- **License:** MIT
- **Homepage:** https://rbraga01.github.io/builder-product/

Install and usage instructions live in the source repository linked above.