adversarial-ux-test · git:20260703.247aff5 · 2026-07-03 · sha256 b9e22cef99904336

adversarial-ux-test git:20260703.247aff5A

Immutable. This exact content never changes and is served at /api/v1/blob/b9e22cef99904336.

---
name: adversarial-ux-test
description: Test an app as a difficult, low-patience persona, then filter complaints into actionable UX issues.
metadata: {"cybara":{"requires":{"anyBins":["chromium","google-chrome","msedge"]}}}
---

# Adversarial UX Test

Use this before demos, launches, onboarding changes, or major UI releases when the user wants friction found by a realistic hard-to-please persona.

## Workflow

1. Define one persona:
   - Role, age range, technical comfort, core task, frustration triggers, and voice.
2. Browse the app as that persona:
   - First impression.
   - Core workflow.
   - Error recovery.
   - Readability and accessibility.
   - Speed and perceived effort.
   - Terminology.
   - Navigation and return paths.
3. Record evidence:
   - Screenshots for each major issue.
   - Console errors.
   - Network failures.
   - Click count for the core task.
4. Write the persona rant:
   - In character, with concrete quotes and page references.
5. Apply the pragmatism filter:
   - Red: real UX bug.
   - Yellow: valid but lower priority.
   - Green: feature request with strong value.
   - White: persona noise.
6. Produce tickets only for Red and Green items.

## Rules

- One persona per session.
- Test the core workflow before touring settings.
- Do not create more than 10 tickets.
- Separate entertaining persona feedback from objective product findings.
- Do not turn "I hate computers" into product work unless it exposes a real accessibility or workflow issue.

## Report Shape

```text
Persona: <name and constraints>
Task: <core task>
Verdict: <would they keep using it?>

Persona feedback:
- "<quote>" - <what happened>

Filtered findings:
- RED: <issue, evidence, suggested fix>
- YELLOW: <issue>
- GREEN: <request>
- WHITE: <noise>

Tickets:
- <title> - <evidence> - <fix>
```