Turn a usability test into a spec the team can build

A usability test is the highest-signal research you can run and the most likely to evaporate. You watch five people fail at the same step, you feel it in your gut, and then it becomes a slide. By the time engineering picks up the work the why is gone. They are building from a one-line ticket, not from the moment a user said "wait, where did it go?" This flow keeps the observation attached to the fix.

The input

The raw output of a few sessions, in whatever shape you have it:

• Observation notes ("P3 clicked Save twice, didn't trust it worked")
• Verbatim quotes from think-aloud
• Timestamps or clip descriptions
• The task each participant was attempting

No need to clean it up first. Messy notes are fine.

The flow

1. Paste the findings into the composer. Open the Evidence tab and drop your notes in. Short notes become one signal each. A long paste is extracted into rows you keep or drop, each with a quote and a friction type.

2. Everything you keep lands Unreviewed in the Inbox. The observations are captured, attributed, and searchable. None of them backs anything yet.

3. Write the outcome as a claim. Start an intent and state the fix as an observable outcome: "the user gets a confirmation within 500ms of saving." Two participants failing on different screens for the same reason both bear on that one claim.

4. Back the claim from the exact moment. In the Inbox, Use as backing asks which claim the observation supports, then reviews and anchors it in one action with your name and the time. The clip that made you certain is now attached to the outcome an engineer will build.

5. Leave the rest visible. Observations you are unsure about get Keep unreviewed. They stay in the record, searchable in Browse, without pretending to be proof.

The output

A spec that carries the test's evidence forward:

• Outcomes tied to observed failure, not to a hunch
• Quotes preserved with attribution, so the fix is defensible
• The pattern named once as a claim, instead of one ticket per screen
• A visible reviewer on each judgment, so nobody has to reconstruct who decided what

Why this beats a findings deck

A deck is where research goes to be admired and then ignored. The gap between "here's what we saw" and "here's what we'll build" is where the insight leaks out. Backing an exact outcome with an exact observation closes that gap, and the state of each claim tells a reader which parts of the spec rest on what you actually saw.

Try it yourself

1. Gather notes from your last 3 to 5 usability sessions
2. Open Pathmode, choose a product, go to the Evidence tab and paste them
3. Start an intent and write the fix as an observable outcome
4. Work the Inbox and use the clearest observations as backing for that outcome

Related

• Use case: Find the friction pattern across 5 user interviews
• Use case: Catch the experience gaps in a spec before build
• Playbook: Interview to Evidence