ux-interview
SolidPlays the role of a real user in an interview-style usability test. Takes context about the product (URL, description, focus areas), auto-suggests a persona (overridable), then drives real Chrome via the claude-in-chrome extension to explore the product think-aloud style — narrating live reactions while flagging confusion, friction, and delight, and capturing GIFs/screenshots of the friction moments. Produces a structured UX report with severity-ranked pain points, what worked, and prioritized recommendations. Learns over time which findings the user considers signal vs noise. Use when you want a real-user-perspective audit of a web product to catch UX/UI/product issues that automated tests can't catch.
Install
Quality Score: 83/100
Skill Content
Details
- Author
- mostafa-drz
- Repository
- mostafa-drz/claude-skills
- Created
- 7 months ago
- Last Updated
- yesterday
- Language
- HTML
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
ui-test
Runs UI tests described in plain English by driving real Chrome via the Claude-in-Chrome extension. Covers end-to-end flows (clicks, forms, assertions), visual checks (screenshot + optional baseline diff), accessibility (axe-core), performance (Web Vitals + light Lighthouse-style metrics), and an interactive --debug mode that tails console + network and surfaces issues without needing explicit assertions. Accepts inline descriptions or test files in `./tests/ui/*.md`. Per-run folders contain artifacts (screenshots, console, network, axe report, perf metrics) plus a single-file 2026-aesthetic HTML report with a verdict-forward layout. Learns from per-run feedback — false-positive categories, screenshot strategy, severity floors, and per-project baselines personalize future runs. Use when the user wants to verify a UI flow, screenshot a regression, audit accessibility, profile a page, or debug something visibly broken in a real browser session.
ux-audit
Walk through a product UI as a real user — take screenshots, find broken flows, and produce a structured report with every fix listed. Use when: audit the UI or UX, do a UX review, QA a feature, check if something looks right, verify a user flow or onboarding, walk through a journey, 'is X broken?', 'check how X works'. Do NOT use for: proving that a specific change works with pass/fail evidence for a PR, fixing a specific known bug, reading a component's code, deploying, writing tests, or answering questions about code structure.
ux-research
Use when you need EVIDENCE about real users — to plan a study, run usability tests (~5 users, think-aloud, realistic tasks), interview users (JTBD/critical-incident), field-study in context, run surveys or A/B, or validate a journey/prototype against actual behavior before the design or scope is locked. Picks the right method for the question and lifecycle phase, separates observation from interpretation, and never lets stated opinion stand in for observed behavior.