Use this when you've completed usability test sessions (moderated or unmoderated) and need to synthesize the raw observations into severity-scored findings, task success metrics, and a stakeholder-ready summary. Completes the loop started by usability test planning.
Related skills: Use
/research-synthesizefor broader research synthesis. Feed findings into/ux-auditfor full product assessment. Pair with/design-reviewto evaluate proposed fixes.
Process
Step 1: Gather inputs
Ask the user to provide:
- Session data -- observation notes, recordings timestamps, task completion logs, or transcripts from usability test sessions
- Test plan -- the original task list, success criteria, and participant profiles (if from a prior test plan)
- Number of participants -- how many people completed each task
- Test method -- moderated (live), unmoderated (recorded), or guerrilla (informal)
- Product context -- what was being tested and at what fidelity (prototype, staging, production)
Step 2: Task success analysis
Score each task across all participants:
## Task Success Analysis -- {{product/feature name}}
| Task | Participants | Direct success | Indirect success | Failure | Abandonment | Avg. time | Target time |
|------|-------------|----------------|-----------------|---------|-------------|-----------|-------------|
| (task 1) | (n) | (count/%) | (count/%) | (count/%) | (count/%) | (time) | (time) |
### Definitions
- **Direct success** -- completed without errors or backtracking
- **Indirect success** -- completed but with errors, confusion, or assistance
- **Failure** -- could not complete the task
- **Abandonment** -- gave up before completing
Step 3: Finding extraction
For each usability problem observed, create a structured finding:
## Findings
### Finding {{N}}: {{Brief description}}
- **Severity:** Critical / Major / Minor / Cosmetic
- **Frequency:** (X of Y participants encountered this)
- **Task(s) affected:** (which tasks)
- **What happened:** (Describe the observable behavior -- what users did, said, or failed to do)
- **Why it matters:** (Impact on task completion, user confidence, or business metric)
- **Evidence:** (Specific participant quotes, timestamps, or behavioral observations)
- **Recommendation:** (How to fix it -- specific enough to act on)
Step 4: Severity scoring
Apply consistent severity criteria:
| Severity | Definition | Action |
|---|---|---|
| Critical | Prevents task completion. Multiple participants failed. | Fix before release |
| Major | Causes significant delay or confusion. Users complete with difficulty. | Fix in current cycle |
| Minor | Noticeable friction but users recover quickly. | Plan for next cycle |
| Cosmetic | Aesthetic or preference issue. No impact on task success. | Backlog |
Cross-check severity against frequency:
- A problem 1 participant hit is likely Minor unless it blocked task completion.
- A problem 4+ participants hit (in a 5-person test) is at least Major.
Step 5: Pattern analysis
Group findings into themes:
### Pattern Analysis
| Pattern | Findings | Frequency | Root cause hypothesis |
|---------|----------|-----------|----------------------|
| (e.g., "Navigation confusion") | #2, #5, #8 | 4/5 participants | (Hypothesis about why this keeps happening) |
Step 6: Stakeholder summary
Produce a concise summary for stakeholders who won't read the full report:
## Executive Summary
**What we tested:** (1 sentence)
**Participants:** (count, segment, method)
**Key findings:**
1. (Most critical finding -- 1 sentence)
2. (Second finding -- 1 sentence)
3. (Third finding -- 1 sentence)
**Overall assessment:** (Ready for launch / Needs iteration / Major rework needed)
**Top 3 recommendations:**
1. (Highest-impact fix)
2. (Second fix)
3. (Third fix)
Step 7: Review
Ask the user:
- Do the severity ratings match what you observed in sessions?
- Are there findings I missed from your notes?
- Do the recommendations feel actionable for your team?
- Should I create stories from the top findings using
/story-write?
Output location
Present the findings as formatted text in the conversation. The executive summary can be shared directly with stakeholders. Individual findings can be converted to backlog items.
Example Output
Input
- Session data: 6 moderated sessions on Zoom; observer notes show 4/6 participants couldn't locate the "Recurring Transfer" option during onboarding, 3/6 used the back button repeatedly during identity verification, 2/6 abandoned the final confirmation screen after not seeing a summary of fees, selected quotes: "I don't know where to go from here" (P2), "Wait, is this going to charge me every month?" (P5), "I already hit back like three times" (P3)
- Test plan: 4 tasks — (1) Set up a one-time transfer, (2) Set up a recurring weekly transfer, (3) Complete identity verification, (4) Confirm and submit first transfer; success criteria = task completed in under 90 seconds without facilitator assistance
- Number of participants: 6 participants; mixed segment of new retail banking customers aged 28–55
- Test method: Moderated (live), remote via Zoom with think-aloud protocol
- Product context: Staging environment of Meridian Bank's new "QuickSend" money transfer flow, desktop web, pre-launch build
Output (abbreviated)
Task Success Analysis — Meridian Bank QuickSend Onboarding Flow
| Task | Participants | Direct success | Indirect success | Failure | Abandonment | Avg. time | Target time |
|---|---|---|---|---|---|---|---|
| 1. One-time transfer | 6 | 4 (67%) | 2 (33%) | 0 | 0 | 74s | 90s |
| 2. Recurring weekly transfer | 6 | 1 (17%) | 1 (17%) | 4 (67%) | 0 | 142s | 90s |
| 3. Identity verification | 6 | 2 (33%) | 2 (33%) | 0 | 2 (33%) | 118s | 90s |
| 4. Confirm and submit | 6 | 2 (33%) | 2 (33%) | 0 | 2 (33%) | 96s | 90s |
Definitions
- Direct success — completed without errors or backtracking
- Indirect success — completed but with errors, confusion, or assistance
- Failure — could not complete the task
- Abandonment — gave up before completing
Findings
Finding 1: "Recurring Transfer" option is not discoverable
- Severity: Critical
- Frequency: 4 of 6 participants
- Task(s) affected: Task 2
- What happened: Participants scanned the transfer type screen and selected "One-Time" by default, assuming it was the only option. The "Recurring" toggle appears below the fold and uses muted gray styling that participants overlooked entirely.
- Why it matters: Task 2 had a 67% failure rate — the highest of any task. Users who can't find recurring transfers will either leave or call support, eroding the self-serve value proposition of QuickSend.
- Evidence: P1 selected one-time and submitted before realizing the error. P4: "I don't see anything about repeating it — is that somewhere else?" P6 scrolled down only after facilitator asked what else they noticed on the page.
- Recommendation: Promote the transfer type selector (One-Time / Recurring) to a visible, above-the-fold toggle using equal visual weight for both options. Remove the default pre-selection of "One-Time."
Finding 2: Identity verification back-navigation resets progress without warning
- Severity: Major
- Frequency: 3 of 6 participants
- Task(s) affected: Task 3
- What happened: Participants who hit the browser back button during the multi-step ID verification flow were returned to step 1 with all previously entered data cleared. No warning dialog appeared.
- Why it matters: 2 participants abandoned the task entirely after losing their data a second time. Loss of progress in a trust-sensitive flow damages confidence in the product at a critical moment.
- Evidence: P3: "I already hit back like three times and it keeps starting over." P5 closed the tab after the second reset. Observer note at 00:14:32: P2 visibly frustrated, long pause before re-entering SSN.
- Recommendation: Preserve form state across back-navigation using session storage. Add a "Leave verification?" confirmation dialog when the browser back button is detected mid-flow.
Finding 3: Fee disclosure absent from confirmation screen causes abandonment
- Severity: Major
- Frequency: 2 of 6 participants
- Task(s) affected: Task 4
- What happened: The final confirmation screen shows transfer amount and recipient but omits the $1.50 transfer fee. Two participants paused for 30+ seconds and ultimately did not submit, citing uncertainty about total cost.
- Why it matters: Abandonment at the confirmation step means zero revenue conversion despite a user completing 90% of the funnel. Fee transparency is also a regulatory best practice.
- Evidence: P5: "Wait, is this going to charge me every month?" P2 scrolled the confirmation screen repeatedly and said "I just want to make sure there are no hidden fees before I hit submit."
- Recommendation: Add a fee summary line ("Transfer fee: $1.50 | Total debited: $51.50") to the confirmation screen above the submit button. Ensure fee is surfaced at the amount-entry step as well.
Pattern Analysis
| Pattern | Findings | Frequency | Root cause hypothesis |
|---|---|---|---|
| Information hierarchy failures | #1, #3 | 4–6/6 participants | Key decision inputs (transfer type, fee) are visually de-emphasized or positioned below the fold, causing users to act on incomplete information |
| Destructive navigation with no recovery | #2 | 3/6 participants | Back-navigation state is not preserved; the flow treats verification as a single-page transaction rather than a resumable multi-step process |
Executive Summary
What we tested: The QuickSend money transfer onboarding flow on Meridian Bank's staging environment, covering transfer setup, identity verification, and confirmation. Participants: 6 new retail banking customers (ages 28–55), moderated remote sessions, think-aloud protocol.
Key findings:
- 4 of 6 participants could not find the Recurring Transfer option, causing a 67% failure rate on that task — the feature is buried below the fold.
- Browser back-navigation during identity verification silently resets all entered data, leading to abandonment by 2 participants.
- The confirmation screen omits transfer fees, causing last-second hesitation and 2 drop-offs at the final submit step.
Overall assessment: ⚠️ Needs iteration — the flow has one critical blocker (recurring transfer discoverability) and two major issues that will suppress conversion and trust at launch.
Top 3 recommendations:
- Redesign the transfer type selector to give Recurring equal visual prominence to One-Time, above the fold, with no default pre-selection.
- Add a back-navigation guard and session-state persistence to the identity verification flow to prevent data loss.
- Surface the transfer fee explicitly on both the amount-entry screen and the confirmation screen before the submit action.