| name | ux-webapp |
| description | UX audit + design spec for web apps. Use for usability reviews, accessibility checks, user flows, microcopy, wireframes, and implementation-ready acceptance criteria. |
UX for Web Apps
This skill helps you do high-quality UX work on web applications:
- Evaluate existing UX (heuristics + accessibility + flows)
- Propose concrete improvements (interaction + IA + content)
- Produce implementation-ready specs (states, rules, acceptance criteria, analytics)
- Validate with lightweight testing plans
When to Use This Skill
Use this skill when the user asks for:
- UX review / audit / heuristic evaluation / usability critique
- Improve onboarding, forms, settings, dashboards, funnels
- Redesign a flow (signup, checkout, search, CRUD, etc.)
- Accessibility review (keyboard nav, focus, screen reader basics)
- Wireframes (textual), user flows, information architecture, microcopy
- "Write the spec" / "Define acceptance criteria" for UX changes
Default Operating Mode
- Do not block on missing context. Make minimal assumptions, label them, and proceed.
- Ask at most 5 clarifying questions only if the answers would change recommendations materially.
- Default to Quick UX Pass (lightweight feedback). Only escalate to full audits/specs when explicitly requested or clearly warranted.
- Avoid "pixel" design. Provide interaction rules + layout intent and component guidance.
- Capture your own screenshots when browser tools are available (see Visual Inspection below). If visuals aren't available after requesting, proceed with a code-only review and label it clearly.
Visual Inspection
Always attempt to see the actual UI before giving advice. Code alone is insufficient for UX evaluation.
When Browser Tools Are Available
If you have access to browser/chrome-tester MCP tools:
- Launch the app in the browser tool
- Capture screenshots of the relevant flows/pages
- Interact with the UI to understand real behavior
- Test keyboard navigation and tab order
- Check responsive behavior at different viewport sizes
When No Browser Tools Available
If you cannot capture screenshots yourself:
- Ask the user for screenshots of the relevant screens/flows
- If screenshots aren't provided in the same turn, proceed with a code-only review and mark it as lower confidence
- Clearly label any advice as "based on code review only" with lower confidence
- Focus on structural issues (missing states, error handling, accessibility attributes)
Do not hallucinate visual details. If you haven't seen it, say so.
Design Context
Adapt recommendations to the type of product:
| Context | Pattern Preference | Delight Level | Examples |
|---|
| B2B / SaaS / Internal Tools | Conservative, conventional | Low | Admin dashboards, CRMs, dev tools |
| Consumer Apps | Balanced | Medium | Social apps, productivity, e-commerce |
| Marketing / Landing Pages | Creative, distinctive | High | Product launches, campaigns, portfolios |
Ask about context if unclear.
Decision Tree
| Input | Action |
|---|
| Screenshots / URL / flow description | Quick UX Pass (default) or full audit if requested |
| Feature idea / problem statement only | Propose the flow + lightweight spec |
| Access to codebase | Capture screenshots first (if browser tools available), then Quick UX Pass |
| Browser tools available | Use them. Launch app, capture screenshots, then evaluate |
Output Formats
Default: Quick UX Pass. Only escalate when explicitly requested or clearly warranted.
| Format | When to Use | Output |
|---|
| Quick UX Pass (default) | "Review this", "Is this good?", "Quick feedback" | Top 5-10 issues with severity, rationale, and fixes |
| UX Audit | "Full audit", "Comprehensive review", complex multi-screen flows | Flow map + issue backlog + prioritized roadmap |
| Design Spec | "Write the spec", "Acceptance criteria", new feature design | Interaction rules, states, copy, criteria, analytics |
| Validation Plan | "Test plan", "How do we validate this?" | Usability test script + tasks + success criteria |
Escalation signals: User says "thorough", "comprehensive", "full", "deep dive", or task involves 5+ screens/states.
Issue Reporting Format
| ID | Location | Problem | Evidence | Principle | Sev | Impact | Confidence | Effort | Priority | Recommendation | Acceptance Criteria |
|---|
| 1 | Login | Submit button disabled with no explanation | Users click repeatedly | H5 / L4 | 3 | 3 | 4 | 2 | 6.0 | Show helper text | Given incomplete form, When user views submit, Then helper shows required fields |
Severity Scale (0-4):
- 0: Not a problem / nit
- 1: Cosmetic; doesn't impede task completion
- 2: Minor; causes friction or mild error risk
- 3: Major; frequently blocks tasks or causes serious mistakes
- 4: Critical; prevents task completion, causes data loss, or creates severe trust/safety issues
Reference Materials
| File | Contents |
|---|
reference/HEURISTICS.md | Nielsen's 10 heuristics + cognitive laws + severity scale |
reference/CHECKLISTS.md | Forms, navigation, a11y, responsive checklists |
templates/UX_AUDIT.md | Audit output template |
templates/DESIGN_SPEC.md | Implementation spec template |
templates/USABILITY_TEST.md | User testing plan template |
Deliverable Checklist
When responding, always deliver:
- A prioritized list of issues/fixes OR a proposed flow/spec
- Concrete acceptance criteria (Given/When/Then)
- Any assumptions you made (labeled clearly)
- Cite heuristics or cognitive laws for every recommendation (no "vibes")
