| name | e2e-ux-test |
| description | Adversarial UX test — drive the live web UI as the product's most tech-hostile persona to hunt friction, then filter the rant into RED/YELLOW/WHITE/GREEN verdicts. Trigger on "ux test", "friction test", "asshole user test". |
Adversarial UX Test
e2e-test asks does it work? — this skill asks would a human tolerate it? You hunt friction, not bugs: jargon, click-mazes, cold-start dead ends, unreadable screens, paywall hostility. The method is the mom test, but angry: fully inhabit the worst-case persona, rant in their voice, then break character and filter the rant like a product manager. The filter is what makes this an instrument instead of entertainment.
Two invariants:
- Evidence rule — every complaint rests on a screenshot under
ai-docs/ux-test/<persona>/ that you Read back after capturing.
- In character from first click through the end of the rant. Break character only at the filter.
Browser mechanics come from the browser-usage skill. Test the deployed or staging app; a URL from the user beats hunting for one.
Phase 1 — The persona
Check ai-docs/ux-personas/ first. A card for this app already exists → reuse it; this run becomes a regression pass against its ledger. Otherwise build one from the card template in references/persona-gallery.md — five questions plus the runs ledger, with industry seeds and a worked example.
Phase complete when the card exists at ai-docs/ux-personas/<slug>.md, answers all five questions, and is specific enough to hold character for twenty minutes of browsing — "a user who dislikes the app" fails that bar.
Phase 2 — Browse in character
Cold start: register as a NEW user — tag the account and anything you create with a uxtest- marker for cleanup. The empty-state, first-run experience is where most friction lives; a pre-seeded admin account skips exactly the screens that matter.
Attempt the persona's ONE task, start to finish — a goal-driven run, so every detour the UI forces on you is a finding in itself. Count every click on the path to task completion. Along the way, visit each friction category:
- First impression — would they bother past the landing page?
- Core workflow — the ONE task, end to end
- Error recovery — do something wrong on purpose; can they get back?
- Readability — text size, contrast, information density
- Speed — does it feel faster than their current method?
- Terminology — jargon they wouldn't know
- Navigation — do they know where they are? can they get back?
Per pain point: screenshot → ai-docs/ux-test/<slug>/<NN>-<desc>.png → Read it back. Run agent-browser console and agent-browser errors on every page — silent JS errors are the highest-value finds. If a subscription/paywall exists, probe the locked-out state: what happens to their data when they can't pay?
Phase complete when the ONE task is done or abandoned-in-character, every friction category has been visited, the click count is recorded, and every complaint has a screenshot you read back.
Phase 3 — The rant
Write the persona's review, fully in voice, to ai-docs/ux-test/<slug>/rant.md:
# <PERSONA>'s review of <PRODUCT>
Overall: <keep using it? Yes / No / Maybe, with conditions>
THE GOOD (grudging admissions)
THE BAD (would stop them using it)
THE UGLY (would make them quit on the spot)
SPECIFIC COMPLAINTS
1. <page/feature>: "<quote in persona voice>" — what happened vs what they expected — <screenshot>
VERDICT: "<one line, in voice>"
Phase complete when every Phase 2 pain point appears in the rant with its screenshot linked.
Phase 4 — The pragmatism filter
Break character here. As a product person, give every rant line exactly one color:
- RED — real UX bug. Any user hits this, not just grumpy ones. A 35-year-old competent-but-busy user would have the same complaint; genuine accessibility issues; >5 clicks to the ONE task is RED regardless of persona.
- YELLOW — valid, edge users only. Real, but fixing it for everyone adds little.
- WHITE — persona noise. "I want it to work like paper"; fixing it would add complexity for the 80% who are fine.
- GREEN — feature request hiding inside a complaint, often a missing onboarding moment.
Perception caveat: you inferred readability from a DOM, not through 58-year-old eyes. Verify contrast/font-size complaints against the screenshot before granting RED; otherwise mark them inferred.
Two calibration gates, both checked before moving on:
- Zero complaints → the persona was too tech-savvy. Make them older, less patient, more set in their ways, and redo Phase 2.
- Zero WHITE → the product has real problems, not a grumpy persona. Say exactly that in the report.
Phase complete when every complaint carries one color and both gates have been checked.
Phase 5 — Ledger, cleanup, report
Append this run's row to the persona card's runs ledger. On a rerun, diff against the previous entry and call out regressions ("core task was 4 clicks in June, now 7") — these outrank any new finding.
Cleanup before reporting: delete the uxtest--tagged account and data where the app allows it; where it doesn't, note what was left behind for the report. Keep ai-docs/ux-test/ — that's the evidence trail.
Final message: the rant (visceral), then the filtered table (color, complaint, screenshot, suggested fix), then the ledger diff, then anything cleanup left behind. Offer tickets via AskUserQuestion — if yes, file RED and GREEN items through the jira skill (persona quote + the objective issue underneath + suggested fix, max 10), and YELLOW as one catch-all. WHITE stays in the report only.
