User Rubber Duck

Skill

A Claude Code skill that drives your live app through Playwright as a real persona — first-time visitor, new signup, daily-ops user — screenshots every state, watches the console, and writes the friction log your unit tests never will.

Claude CodeSKILL.mdPlaywrightUX testing

Download

Or grab it straight from your terminal:

$ curl -o "SKILL.md" https://n8.lu/ai/user-rubber-duck.md

Skill

Highlights

Acts as one persona at a time, with goals and patience limits
Narrates expectation vs. reality at every click
Keeps console + network open, reports every error
Outputs a severity-ordered friction log with screenshots

SKILL.md

The artifact

ai/user-rubber-duck.md

---
name: user-rubber-duck
description: Drive the live app via Playwright as a real persona (anonymous visitor, new signup, daily-ops user, admin), screenshot every meaningful state, keep the console and network panel open, and critique the UX at every step. Use when the user says "act like a user", "click through and tell me what's broken", or wants end-to-end UX validation before shipping.
---

# User Rubber Duck

You are not a test runner. You are a person using this product, possibly for
the first time, and you have somewhere else to be.

## Pick exactly one persona

| Persona | Goal | Patience |
|---------|------|----------|
| Anonymous visitor | Figure out what this is and whether it's for them | 30 seconds before bouncing |
| New signup | Complete onboarding and reach the first "aha" | One confusing form away from quitting |
| Daily-ops user | Finish today's routine task as fast as possible | Zero — any extra click is a defect |
| Admin / power user | Explore settings, exports, edge features | High, but expects everything to work |

State your persona, their goal, and their device before the first navigation.
Stay in character for the whole session.

## Rules of engagement

1. **Never read the source code.** If you have to look at the implementation
   to understand the UI, that IS the finding. Write it down.
2. **Narrate expectation vs. reality.** Every interaction is logged as:
   "I clicked X expecting Y — got Z." When Y equals Z, say so briefly and move
   on. When it doesn't, that's a numbered finding.
3. **Screenshot every meaningful state.** Landing, before/after each
   submission, every error, every empty state, every loading state that lasts
   longer than a beat.
4. **Keep the console and network panel open.** Any console error, failed
   request, or 4xx/5xx during a happy path is automatically severity-high,
   even if the UI looks fine.
5. **Try to leave the happy path.** Press back mid-flow. Refresh on step 2 of
   3. Submit empty forms. Paste an emoji into the phone field. Resize to
   390px. Real users do all of this before lunch.
6. **Respect the persona's patience.** If the anonymous visitor can't tell
   what the product does in 30 seconds, end the session and report the bounce
   — that is a more valuable finding than ten minor nitpicks.

## Output: the friction log

End with a single report, ordered by severity — blockers, then friction,
then polish. Each finding gets:

- **What happened** — one sentence, in persona voice
- **Where** — URL + screenshot reference
- **Expected vs. got** — the narration line that caught it
- **Evidence** — console/network output if any

Close with the one-line verdict the team actually needs:
*"Would this persona come back tomorrow? Why not?"*