The test is over. Now what do you do with all these notes?

The last participant waves goodbye and the call ends. You look at what five sessions left behind: a doc with 104 notes, a few screenshots, half a page of quotes. On Monday someone will ask "so, what did we learn?" and right now the honest answer is: a lot, probably, somewhere in here.

How to analyze usability test results in three steps

Analyzing usability test results comes down to three moves: pool every observation in one place, cluster the pile into patterns, and rank the patterns by severity and frequency. The method is tool-neutral. It works on a wall of sticky notes, in a spreadsheet, or in a research tool. And the goal is not a thirty-page report. It's a short list, three problems or so, each with evidence attached, that your team will actually fix.

The three steps take an afternoon for a typical five-session study. Here's each one.

Step 1: One pile, one observation per note

First, get everything into a single pile: session notes, quotes, moments from the transcript, anything you marked during the sessions. NN/g describes this stage as collecting the observations and quotes that speak to your research questions, and it comes with a warning: not every data point deserves equal weight. Something you watched a participant do counts for more than an opinion they volunteered. "Participant 3 clicked the wrong tab twice" is evidence; "Participant 3 thinks the design is clean" is a mood.

Keep each note to one observation, and keep the who and the when attached. "Participant 2, minute 12: typed a teammate's email into the search bar" can be traced back and defended later; "people were confused about inviting" can't. If your notes were timestamped during the sessions, this step is mostly already done. If they weren't, do the tidying now, before memory fades.

Step 2: Cluster the pile into patterns

Now the classic move: affinity mapping. Spread the notes out, then group the ones that describe the same underlying behavior. NN/g's version of the exercise runs in exactly this order, generate notes, cluster them into themes, then prioritize the clusters, and it works just as well solo in a spreadsheet as it does with a team at a whiteboard.

Two rules make the clusters worth having:

• Group by behavior, not by screen. "Settings-page notes" is a folder, not a finding. "People look for invite in three different places" is a finding, even though those notes came from three screens.
• Name each cluster as a claim with a count. Not "invite issues" but "4 of 5 participants couldn't find how to invite a teammate." The name should survive being pasted into Slack on its own.

If your notes already carry a type tag, this step gets easier: split observations from problems, insights, and bugs up front, and you can set the opinions and bug reports aside and cluster only the behavior.

A hundred notes usually collapse into something like a dozen patterns. Some will be big, some will be two lonely notes about the logo. That's fine. The point of this step is that you now have arguable claims instead of scattered moments.

Step 3: Rank by severity, then frequency

Not all twelve patterns deserve a sprint ticket. Jakob Nielsen's severity scale is the standard way to sort them, rating each problem 0 to 4 based on three factors: how often it occurs, how hard it is to recover from, and whether it keeps happening once users know about it.

Then cross severity with how many participants hit it:

One caution on the numbers: with five participants, frequency is a compass, not a measurement. "4 of 5" tells you the problem is real and common; it doesn't tell you 80% of your users will hit it. (Why small-sample numbers still point the right way is covered in how many participants you actually need.) Severity is the tiebreaker: a catastrophe one person hit outranks a cosmetic glitch everyone noticed.

What this looks like on a real pile

Five sessions on a project tool's onboarding, 104 notes. While sorting, three notes keep landing next to each other: "Participant 2, min 12: typed a teammate's email into the search bar, said 'I guess it's here?'", "Participant 4: opened Settings looking for invite, backed out twice", "Participant 5: gave up and said they'd just Slack people a link." Different screens, same behavior. The cluster gets named "Inviting teammates is invisible from the main screen (4 of 5)" and, since every one of those four stalled for minutes or quit, a severity of 3.

By the end there are 11 patterns. Two are severity 3 and hit most participants; one is a severity 4 that only Participant 1 hit, a data-loss path, which jumps the queue anyway. Those three become sprint tickets with the supporting quotes pasted in. The other eight go to the backlog with their evidence attached. A hundred and four notes in, three actions out, and nobody has to take your word for any of it.

The heavy lifting is optional

That's the whole method, and it runs without any dedicated tool. But the front-loaded grunt work, gathering the notes and reattaching the who and the when, is the part you can skip. Interbang bundles your session notes and the transcript into Markdown and hands them straight to Claude or ChatGPT. You ask the AI for a first-pass clustering, and you decide what to keep and what to drop. Because every note carries its own evidence, you can trace any cluster the AI proposes back to the exact session and minute it came from. It doesn't do the analysis for you; it hands you clean material to analyze.

Share three things, not thirty pages

The report is where insights usually go to die, so keep it small enough to be read:

1. The top problems, each stated as the cluster name, with severity, count, and one or two verbatim quotes as evidence.
2. One thing that worked. It builds trust in the method and stops the team from "fixing" something healthy.
3. What happens next: which fixes go in, and when you'll retest. A usability test earns its keep when the loop closes, test, fix, test again.

That third item quietly raises the next question: when you run the second round, how will you show things actually got better? That's a piece of its own.

Frequently asked questions

How soon after the sessions should I do this? Within a day or two, while the sessions are still vivid. Notes go cold surprisingly fast, and a note like "Participant 4 struggled here" is only useful while you still remember what "here" meant. Booking the analysis afternoon when you book the sessions is the easiest way to protect it.

What if only one participant hit a problem? Check severity before frequency. If it blocks a task or loses data, one sighting is enough to act on. If it's minor, park it in the backlog and watch whether it reappears next round. Frequency with five participants is directional, so let impact carry the decision.

Do I need special software for this? No. A wall of sticky notes or a spreadsheet handles a five-session study fine. Where dedicated tools earn their cost is volume and recall: when studies pile up, research analysis tools like Dovetail or Condens keep old evidence findable.

What does the deliverable actually look like? One page. Three prioritized problems with evidence, one thing that worked, next steps with dates. If you need a longer appendix for stakeholders, link the full cluster list, but never make the one-pager depend on it.