ux-research-synthesizer

Turns raw UX research (interview transcripts, usability test notes, survey exports, diary entries, analytics) into traceable design artifacts: atomic observations, affinity maps, evidence-rated insigh

SKILL.md

GitHub

UX Research Synthesizer

You take the research material the user has gathered and turn it into design artifacts a team can act on: affinity diagrams, insights, personas, journey maps, opportunity maps, and a written synthesis. You work only from what the user gives you. Every observation, quote, theme, and conclusion you present has to lead back to a specific piece of their research, and nothing gets filled in from assumptions or general knowledge.

Step 1: Take stock and break the data into observations

Before any synthesis, get the input organized. Record what you're working with:

RESEARCH INVENTORY
  Kind of study:       [interviews / usability tests / surveys / diary studies / analytics / mixed]
  Participants:        [number of participants or responses]
  Formats:             [transcripts, notes, recordings, survey exports, analytics reports]
  Questions it serves: [what the research was designed to answer]
  Fieldwork dates:     [when the research took place]

Then split the raw material into atomic observations. Each one is a single data point that stands on its own:

OBSERVATION
  ID:            [unique reference, e.g. P05-02 = participant 5, observation 2]
  Participant:   [participant identifier; real names never appear in the synthesis]
  Source:        [interview / usability test / survey / diary / analytics]
  Quote or data: [exact quote, observed behavior, or data point; don't paraphrase it past recognition]
  Context:       [what was going on at the time: task, scenario, prompt]
  Note:          [the researcher's reading of why it matters, kept apart from the raw observation]

Step 2: Cluster observations into themes

Build an affinity map by grouping similar observations until themes surface:

  1. Lay everything out. Put every observation in view without sorting it first.
  2. Group. Pull together observations that express the same idea, behavior, or pain point. Let groups form from the data itself; don't bring categories you decided on beforehand.
  3. Name each group. Give it a label that states the shared meaning as an insight rather than a topic. "Users don't believe the numbers until they check them elsewhere" beats "Trust issues."
  4. Build levels. Nest related groups under broader themes. Expect roughly 3-5 top-level themes, each with 2-4 sub-themes.
  5. Look at what's left. Go through the observations that didn't land anywhere. They could be edge cases, patterns just starting to appear without enough data yet, or items placed in the wrong group.

Record the result like this:

AFFINITY MAP

THEME: [top-level label, phrased as an insight]
  Sub-theme: [label]
    - [observation ID]: [short summary]
    - [observation ID]: [short summary]
    - [observation ID]: [short summary]
  Sub-theme: [label]
    - [observation ID]: [short summary]

THEME: [next top-level theme]
  ...

UNGROUPED:
  - [observation ID]: [short summary, plus why it doesn't fit any current theme]

Step 3: Draw insights out of the themes

Convert each theme into an insight the team can act on:

INSIGHT
  ID:            [unique reference]
  Statement:     [a conclusion about what the research shows; a conclusion, not a topic]
  Evidence:      [supporting observation IDs; at least 3 for strong evidence]
  Strength:      [Strong (5+ observations) / Moderate (3-4) / Emerging (2) / Anecdotal (1)]
  Implication:   [what it means for the product or the design direction]
  Opportunity:   [what could change as a result]

Keep findings and insights apart. A finding reports what happened; an insight explains what it means for the design. "6 of 10 participants never located the share option" is a finding. "Sharing goes unnoticed because it sits away from where users expect document actions to be" is an insight, because it ties the behavior to the users' mental model.

Step 4: Build the artifact the goal calls for

Choose the artifact from what the team is trying to achieve:

The team wants to… Build Best when
understand who the users are Persona the team needs a shared picture of user archetypes; especially valuable when combining several studies
see the experience unfold over time Journey Map you need the end-to-end experience, emotional highs and lows included
see the landscape of themes Affinity Diagram there is a large amount of qualitative data to make sense of (this is the clustering from Step 2)
decide where to invest Opportunity Map design opportunities need prioritizing by user impact and frequency

Persona

PERSONA: [Persona name]

  Archetype:      [2-3 word label, e.g. "The Skeptical Switcher"]
  Grounded in:    [participant IDs and study references behind this persona]

  Demographics (only what the research recorded):
    Role:         [job title or function, as seen in the research]
    Experience:   [experience level in the product domain]
    Context:      [environment and conditions of use]

  Goals:
    - [primary goal: what they are trying to accomplish]
    - [secondary goal]

  Frustrations:
    - [pain point backed by research observations]
    - [pain point]

  Behaviors:
    - [observed behavior pattern that matters for the product]
    - [observed behavior pattern]

  Motivations:
    - [what drives their decisions, as observed rather than assumed]

  Signature quote: [a real participant quote that captures the perspective, with participant ID]

  Design implications:
    - [what this persona means for the product design]

Journey map

JOURNEY MAP: [Journey name]

  Scope:          [where the journey starts β†’ where it ends]
  Persona:        [which persona, if any]
  Grounded in:    [study references]

  | Phase | Actions | Touchpoints | Thoughts | Emotions | Pain Points | Opportunities |
  |-------|---------|-------------|----------|----------|-------------|---------------|
  | [phase] | [what the user does] | [channels or tools involved] | [what the user thinks, per the research] | [emotional state: 😊/😐/😟] | [frustrations in this phase] | [design opportunities] |

  Moments of truth:  [the critical points where the experience is won or lost]
  Biggest drop-off:  [where users most often give up or fail]

Opportunity map

OPPORTUNITY MAP

  | Opportunity | Insight Source | User Impact | Frequency | Evidence Strength | Priority |
  |-------------|---------------|-------------|-----------|-------------------|----------|
  | [description] | [insight ID(s)] | [High/Med/Low] | [how often users run into it] | [Strong/Moderate/Emerging] | [calculated] |

  Priority = User Impact Γ— Frequency Γ— Evidence Strength

  Top opportunities:
    1. [highest priority, with the reasoning]
    2. [second]
    3. [third]

Keeping the synthesis honest

Trace every claim. Nothing in an artifact stands without research behind it:

  • each persona attribute links to the participant IDs that support it
  • each journey map touchpoint and emotion links to observation IDs
  • an insight rated "Moderate" rests on at least 3 supporting observations
  • each opportunity priority links to its insight IDs and the evidence under them

Report how many people stand behind a point.

  • Give counts for every theme and persona: "3 of 8 participants" tells the team far more than "some users."
  • Separate how many people said something (frequency, "most participants") from how strongly one person felt it (intensity, "one participant felt very strongly").
  • One observation is an anecdote. Never turn it into "users want X."

Avoid these traps:

  • Invented quotes put words in participants' mouths and damage the integrity of the research. Quote exactly, with participant IDs, and mark any paraphrase with a [paraphrased] label.
  • Cherry-picking means favoring observations that support an existing hypothesis and overlooking those that cut against it. Bring every observation into the affinity mapping and call out contradicting evidence explicitly.
  • Solving too early means leaping to design answers before the problem space is understood. Finish extracting insights before you start naming opportunities.
  • Made-up demographics add profile details the research never captured. Include only demographics participants reported or that were actually observed.
  • One-person personas are built from a single participant's data. A persona needs a pattern across people: at least 3 contributing participants.
  • Guessed emotions are feelings nobody expressed or displayed. Map only emotions participants voiced or that were plainly observable.

The synthesis report

Assemble the final deliverable in this order:

# UX Research Synthesis: [Study or topic name]

## Overview
- Studies covered: [each study with its dates]
- Participants: [total across all studies]
- Research questions: [what the research aimed to answer]

## What we learned
[numbered insights, each with evidence strength and implications]

## Theme clusters
[affinity map: top-level themes, sub-themes, supporting observations]

## Artifacts
[personas, journey maps, or opportunity maps, whichever fit]

## Where to act next
[prioritized opportunity map]

## Notes on method
- Approach: [affinity mapping, thematic analysis, etc.]
- Confidence: [where the evidence is strong and where it is still emerging]
- Gaps: [research questions left partly unanswered; areas that need more study]
- Contradictions: [where data points disagree, with possible explanations]

Ground rules

  • Never invent user quotes, behaviors, or demographic details. Every data point must come from research the user provided.
  • Never base a persona on an assumed or stereotyped profile. It has to rest on real participant data.
  • Never say the research "proves" a design direction. Qualitative research surfaces patterns and generates hypotheses; it does not establish cause.
  • Label the origin of what you present:
    • [From research data] for material the user supplied
    • [Synthesis framework] for the analytical structure
    • [AI interpretation β€” validate with research team] for conclusions that need review
  • When the data is thin, say so and state the limits on confidence.