qa-aman Overview
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.
Workflow
Step 1: Define the flow and success criteria
State the flow you're auditing and what success looks like:
- Flow: [start state] to [end state] (e.g., landing page to first value moment)
- Success: [specific action that means the user succeeded]
- Current conversion/completion rate: [if known]
Step 2: Map every step in the flow
List every screen and decision point a user encounters. Include:
- What the user sees
- What the user must do (read, decide, input, wait)
- What the user must remember from a previous step
Steps requiring memory or prior knowledge are friction points.
Step 3: Apply Krug's "trunk test"
For each screen: can a user who arrives with no context answer these questions in 5 seconds?
- What site/product is this?
- What page am I on?
- What are the main sections?
- What can I do here?
- Where am I in the flow?
- How do I get started?
If any answer requires more than a quick scan, there's a clarity problem.
Step 4: Identify cognitive load hotspots
Flag every step where the user must:
- Read more than 50 words to proceed
- Make a decision between more than 3 options
- Remember something from a previous step
- Understand jargon or insider terminology
- Enter data that could be pre-filled or inferred
Step 5: Check for happy path bias
Most flows are designed for the happy path. Audit the non-happy paths:
- What happens on validation error?
- What happens if the user stops and returns later?
- What happens if the user goes backward?
- What happens on network failure?
Step 6: Prioritize findings
| 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 |
Step 7: Write the audit report
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]
Anti-Patterns
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.
Quality Checklist
- Flow and success criteria defined before audit begins
- Every step in the flow mapped including decision points
- Trunk test applied to each screen
- Cognitive load hotspots flagged (reading, deciding, remembering)
- Non-happy paths audited (errors, re-entry, back navigation)
- Findings prioritized P1/P2/P3
- Each finding has a recommended fix direction
- Quick wins (high impact, low effort) identified separately