e2e-ux-test

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.