brainstorming
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or planning anything new, in software or out of it (a talk, a business, a renovation).
ux-auditAudit a user flow for friction and drop-off points. Use when the user says "UX audit", "audit this flow", "where are users dropping off", "why isn't this converting", "review the onboarding", "usability audit", "what's causing friction", "user journey review", or wants to identify why users struggle with a flow - even if they don't explicitly say "UX audit".
Independent GitHub snapshot · Automated classification · Original documentation governs
name: ux-audit description: > Audit a user flow for friction and drop-off points. Use when the user says "UX audit", "audit this flow", "where are users dropping off", "why isn't this converting", "review the onboarding", "usability audit", "what's causing friction", "user journey review", or wants to identify why users struggle with a flow
Based on "Don't Make Me Think" by Steve Krug. Krug's core principle: every question a user has to ask themselves is a source of friction. Good UX eliminates questions. Users don't read - they scan. They don't make optimal choices - they satisfice (pick the first option that seems good enough). Design for scanning, not reading. Design for satisficing, not deliberation.
Krug's usability testing insight: you don't need 20 users. 5 users reveal ~85% of usability problems (Nielsen's law). The fastest audit tool is watching one real user try to use the product.
State the flow you're auditing and what success looks like:
List every screen and decision point a user encounters. Include:
Steps requiring memory or prior knowledge are friction points.
For each screen: can a user who arrives with no context answer these questions in 5 seconds?
If any answer requires more than a quick scan, there's a clarity problem.
Flag every step where the user must:
Most flows are designed for the happy path. Audit the non-happy paths:
| Priority | Criteria |
|---|---|
| P1 | Blocks completion of the flow for significant user segments |
| P2 | Adds significant friction but users can complete with effort |
| P3 | Minor confusion, edge cases, polish |
UX Audit: [flow name]
Date: [date]
Flow: [start] to [end]
Current completion rate: [x]% (if known)
P1 Issues:
[screen/step]: [problem] -> [impact] -> [recommended fix]
P2 Issues:
[screen/step]: [problem] -> [impact] -> [recommended fix]
P3 Issues:
[screen/step]: [problem] -> [recommended fix]
Quick wins (high impact, low effort):
[list]
1. Auditing without watching real users Bad: Designer audits their own flow based on their own understanding. Good: Watch 3-5 real users attempt the flow. Say nothing. Note where they hesitate, misclick, or ask questions.
2. Auditing only the happy path Bad: Audit covers only the ideal case (valid inputs, no errors, no confusion). Good: Explicitly test error states, re-entry, and edge cases.
3. P1 everything Bad: Every finding marked critical. Good: Prioritize ruthlessly. One genuine P1 is worth more than 10 vague concerns.
4. Audit without a benchmark Bad: Findings with no baseline. Good: Know the current completion rate before the audit. After fixes, measure again.