replay-ux-audit

What this skill does

# Replay UX Audit

Watch 5-10 session replays for a specific feature, page, or flow, then synthesize patterns into a ranked friction map. This skill turns hours of manual replay watching into a structured UX report grounded in real user behavior.

---

## CRITICAL: Tool Reference

**Primary tools:**
- **`Amplitude:get_session_replays`** — Find sessions matching event filters, user properties, or time windows. Use this to target sessions for a specific feature or flow.
- **`Amplitude:get_session_replay_events`** — Decode a replay into an interaction timeline: navigations, clicks, inputs, scrolls. This is what you "watch."

**Supporting tools:**
- **`Amplitude:get_events`** — Discover valid event names. Never guess event names.
- **`Amplitude:get_event_properties`** — Discover properties for filtering (page path, feature area, etc.).
- **`Amplitude:query_chart`** — Pull quantitative context (funnel conversion rates, feature adoption) to anchor the qualitative replay findings.
- **`Amplitude:get_feedback_insights`** / **`Amplitude:get_feedback_mentions`** — Cross-reference replay friction with customer feedback themes.

---

## Instructions

### Step 1: Define the Audit Scope

Determine what to audit from the user's request:

- **Page or URL pattern**: A specific page (e.g., /settings, /checkout)
- **Feature or flow**: A multi-step process (e.g., onboarding, report creation)
- **Event-based**: Sessions containing a specific event (e.g., "Export Clicked")
- **Broad**: "Audit the whole product" — narrow this down. Ask: "Which area would you like me to start with?" Suggest 2-3 areas based on high-traffic pages or known problem areas if you can identify them.

Also determine:
- **Time window**: Default to last 14 days unless specified.
- **User segment** (optional): Specific plan, platform, cohort, or user type.

### Step 2: Get Context and Discover Events

1. Call `Amplitude:get_context`. If multiple projects, ask which to audit.
2. Call `Amplitude:get_events` to find events related to the target area. Look for:
   - Page view or navigation events for the target area
   - Key interaction events (clicks, form submissions) within the flow
   - Error or failure events that may indicate friction
3. If the user mentioned a flow or funnel, identify the key step events so you can filter sessions that attempted the flow.

### Step 3: Gather Quantitative Baseline (Optional but Recommended)

Before watching replays, establish context with 1-2 chart queries. Budget: 2 calls max.

- If auditing a **funnel**: Use `Amplitude:query_chart` to get the current conversion rate and identify the worst drop-off step. This tells you where to focus your replay attention.
- If auditing a **page**: Query the page's traffic volume and any error rates to understand scale.
- If auditing a **feature**: Query adoption/usage frequency to understand how many users interact with it.

This quantitative baseline makes your qualitative findings more actionable — "40% of users drop off at step 3, and here's what we see them doing" is stronger than "users seem confused at step 3."

### Step 4: Find Target Sessions

Use `Amplitude:get_session_replays` to find 8-12 sessions (request `limit: 12` to allow for some sessions with missing replay data).

**Filter strategy by audit type:**

- **Page audit**: Filter by event on that page (use page path property if available).
- **Flow audit**: Filter by the entry event of the flow. Optionally add a second filter for sessions that did NOT complete the flow (to focus on drop-offs).
- **Feature audit**: Filter by the feature's key interaction event.
- **Segment comparison**: Run two searches — one for each segment — to compare behavior.

If the user specified a segment (plan type, platform, etc.), add user property filters.

### Step 5: Watch Sessions — Extract Interaction Timelines

For each session, call `Amplitude:get_session_replay_events` with `event_limit: 300`.

**Budget: 5-8 sessions.** Skip sessions that return empty or minimal data.

**While analyzing each session, track these friction signals:**

| Signal | What to look for in the timeline |
|---|---|
| **Rage clicks** | 3+ clicks on the same coordinates within a short time span |
| **Hesitation** | Long pauses (>10 seconds) between navigation and first interaction on a page |
| **Back-and-forth** | Navigating to a page, then back, then forward again |
| **Abandoned inputs** | Starting to type in a field, then navigating away without submitting |
| **Excessive scrolling** | Large scroll deltas suggesting the user is searching for something |
| **Dead-end navigation** | Visiting a page and immediately leaving (bounce within seconds) |
| **Repeat attempts** | Performing the same action multiple times (re-submitting a form, re-clicking a button) |

For each session, write a brief summary:
- Pages visited in the target area
- Key actions taken
- Friction signals observed (with timestamps)
- Whether the user completed their apparent goal

### Step 6: Synthesize Friction Patterns

This is the core analytical step. Aggregate findings across all watched sessions.

1. **Group friction signals by location.** Cluster observations by the page or step where they occurred.
2. **Count frequency.** How many of the watched sessions showed this friction? Express as "seen in X of Y sessions."
3. **Assess severity.** Use this rubric:

| Severity | Criteria |
|---|---|
| **Critical** | Blocks task completion. User gives up or encounters an error. Seen in 50%+ of sessions. |
| **High** | Causes significant confusion or delay. User eventually succeeds but with visible struggle. Seen in 30%+ of sessions. |
| **Medium** | Causes minor hesitation or suboptimal paths. User recovers quickly. Seen in 20%+ of sessions. |
| **Low** | Cosmetic or minor annoyance. Seen in <20% of sessions or only in edge cases. |

4. **Identify root cause hypotheses.** For each friction pattern, hypothesize why it happens:
   - Unclear UI labeling or hierarchy
   - Missing feedback after an action (loading state, confirmation)
   - Unexpected behavior (click does nothing, page doesn't respond)
   - Information not where users expect it (excessive scrolling/searching)
   - Error state without clear recovery path
   - Too many steps or cognitive load

5. **Cross-reference with feedback** (if available). Call `Amplitude:get_feedback_insights` with keywords from your friction findings. If users are complaining about the same thing you're seeing in replays, that's high-confidence signal.

### Step 7: Present the UX Audit

Structure the output as a friction map that a PM or designer can act on.

**Required sections:**

1. **Audit Summary** (3-4 sentences): What was audited, how many sessions were watched, the single biggest finding, and overall UX health assessment. Written as a narrative you could paste into a design review doc.

2. **Scope & Methodology**:
   - Feature/flow/page audited
   - Time window
   - Sessions analyzed: N (with replay links)
   - User segment (if filtered)
   - Quantitative baseline (if gathered in Step 3)

3. **Friction Map** — Ranked by severity, then frequency:

For each friction point:

```
### [Friction Point Title — action-oriented, ≤10 words]
**Severity:** [Critical/High/Medium/Low] | **Frequency:** Seen in X of Y sessions

**What happens:** Describe the user behavior observed — what they do, where they
hesitate, what goes wrong. Be specific about the page and interaction.

**Likely cause:** Your hypothesis for why this friction exists.

**Evidence:**
- Session replay links showing this pattern
- Quantitative data (if available): conversion rate at this step, error rate, etc.
- Customer feedback quotes (if found)

**Suggested fix:** One concrete, actionable recommendation.
```

4. **Positive Patterns** (1-2 items): What's working well. Which parts of the experience were smooth across sessions. This provides balance and highlights what to preserve.

5. **Recommended Next Steps** (3-5 numbered items): Start each with