Heuristic Evaluation
Systematic usability review using established principles.
When to Trigger
- User shares a screenshot, mockup, or prototype
- User asks for design feedback or review
- User asks "what's wrong with this"
- User wants to improve an interface
- Before shipping user-facing changes
Quick Start
- Ask user to share the interface (screenshot, URL, or description)
- Ask: "Any specific flows or areas of concern?"
- Run evaluation using Nielsen's 10 (default) or requested framework
Core Workflow
Heuristic Evaluation Progress:
- [ ] Step 1: Capture interface context
- [ ] Step 2: Select evaluation framework
- [ ] Step 3: Evaluate against each heuristic
- [ ] Step 4: Score severity of issues
- [ ] Step 5: Prioritize recommendations
Step 1: Capture Context
Before evaluating, understand:
- What is this? (App type, purpose)
- Who uses it? (Target users, expertise level)
- What task? (Primary user flow being evaluated)
If not provided, ask: "What are users trying to accomplish here?"
Step 2: Select Framework
Default: Nielsen's 10 Usability Heuristics
Alternatives (if user requests or context suggests):
- Shneiderman's 8 Golden Rules — for interaction-heavy interfaces
- Cognitive Walkthrough — for first-time user experience
- Custom rubric — if user provides one
See references/frameworks.md for full framework details.
Step 3: Nielsen's 10 Evaluation
For each heuristic, identify violations:
| # |
Heuristic |
What to look for |
| 1 |
Visibility of system status |
Loading indicators, progress, confirmation, current state |
| 2 |
Match real world |
Familiar language, logical order, conventions from domain |
| 3 |
User control & freedom |
Undo, cancel, exit, back navigation, escape hatches |
| 4 |
Consistency & standards |
Same words/actions mean same things, platform conventions |
| 5 |
Error prevention |
Confirmations for destructive actions, constraints, defaults |
| 6 |
Recognition over recall |
Visible options, contextual help, no memorization required |
| 7 |
Flexibility & efficiency |
Shortcuts, customization, accelerators for experts |
| 8 |
Aesthetic & minimalist |
No irrelevant info, clear hierarchy, signal vs noise |
| 9 |
Help users with errors |
Plain language errors, specific problem, constructive solution |
| 10 |
Help & documentation |
Searchable, task-focused, concise, accessible when needed |
Step 4: Score Severity
Rate each issue found:
| Score |
Severity |
Description |
| 0 |
Not a problem |
Disagreement with heuristic but not usability issue |
| 1 |
Cosmetic |
Fix only if time permits |
| 2 |
Minor |
Low priority, causes minor friction |
| 3 |
Major |
High priority, significant impact on task completion |
| 4 |
Catastrophic |
Must fix before release, prevents task completion |
Scoring factors:
- Frequency: How often does user encounter this?
- Impact: How much does it block the task?
- Persistence: Can users work around it?
Step 5: Prioritize Output
Rank issues by: Severity × Frequency
Group into:
- Fix immediately (Severity 4, or Severity 3 + high frequency)
- Fix soon (Severity 3, or Severity 2 + high frequency)
- Fix later (Severity 1-2, low frequency)
Output Template
Automatically save the output to design/08-heuristic-evaluation.md using the Write tool while presenting it to the user.
## Heuristic Evaluation: [Interface Name]
**Evaluated**: [Date]
**Framework**: Nielsen's 10 Usability Heuristics
**Scope**: [Specific flow or screens evaluated]
### Summary
- Critical issues: [count]
- Major issues: [count]
- Minor issues: [count]
### Critical Issues (Fix Immediately)
#### Issue 1: [Brief description]
- **Heuristic violated**: #[number] — [name]
- **Location**: [Where in the interface]
- **Problem**: [What's wrong]
- **Impact**: [How it affects users]
- **Recommendation**: [How to fix]
- **Severity**: [0-4]
[Repeat for each critical issue]
### Major Issues (Fix Soon)
[Same format]
### Minor Issues (Fix Later)
[Same format, can be condensed to a table]
### Strengths Observed
- [What the interface does well]
### Next Steps
1. [Prioritized action]
2. [Prioritized action]
Adaptive Behavior
If user provides a screenshot:
- Analyze visually
- Call out specific elements by location
- Be concrete: "The save button in the top right..." not "buttons should..."
If user describes interface:
- Ask clarifying questions before evaluating
- Focus on described pain points first
If user is designer:
- Skip heuristic definitions
- Use shorthand: "H4 violation" instead of explaining consistency
If user is developer:
- Include implementation-aware suggestions
- Note which fixes are quick wins vs architectural changes
Handoff
After presenting the evaluation, suggest:
"Use this report to prioritize fixes. Want me to help refine any screens based on these findings?"
Note: File is automatically saved to design/08-heuristic-evaluation.md for reference.
Integration Points
Works well with:
assumption-mapping — before building, question if the design addresses real needs
critique — for broader feedback beyond usability
accessibility-audit — for WCAG-specific evaluation
References
- references/frameworks.md — Full heuristic definitions and alternatives
- references/examples.md — Sample evaluations
1---2name: heuristic-evaluation3description: Systematic usability evaluation using established heuristics (Nielsen's 10, Shneiderman's 8, or custom rubrics). Use when reviewing UI designs, screenshots, prototypes, or live products for usability issues. Triggers on "review this design", "what's wrong with this UI", "usability check", "evaluate this interface", or when user shares screenshots/mockups asking for feedback.4---56# Heuristic Evaluation78Systematic usability review using established principles.910## When to Trigger1112- User shares a screenshot, mockup, or prototype13- User asks for design feedback or review14- User asks "what's wrong with this"15- User wants to improve an interface16- Before shipping user-facing changes1718## Quick Start19201. Ask user to share the interface (screenshot, URL, or description)212. Ask: "Any specific flows or areas of concern?"223. Run evaluation using Nielsen's 10 (default) or requested framework2324## Core Workflow2526```27Heuristic Evaluation Progress:28- [ ] Step 1: Capture interface context29- [ ] Step 2: Select evaluation framework30- [ ] Step 3: Evaluate against each heuristic31- [ ] Step 4: Score severity of issues32- [ ] Step 5: Prioritize recommendations33```3435### Step 1: Capture Context3637Before evaluating, understand:38- **What is this?** (App type, purpose)39- **Who uses it?** (Target users, expertise level)40- **What task?** (Primary user flow being evaluated)4142If not provided, ask: "What are users trying to accomplish here?"4344### Step 2: Select Framework4546**Default**: Nielsen's 10 Usability Heuristics4748**Alternatives** (if user requests or context suggests):49- Shneiderman's 8 Golden Rules — for interaction-heavy interfaces50- Cognitive Walkthrough — for first-time user experience51- Custom rubric — if user provides one5253See [references/frameworks.md](references/frameworks.md) for full framework details.5455### Step 3: Nielsen's 10 Evaluation5657For each heuristic, identify violations:5859| # | Heuristic | What to look for |60|---|-----------|------------------|61| 1 | **Visibility of system status** | Loading indicators, progress, confirmation, current state |62| 2 | **Match real world** | Familiar language, logical order, conventions from domain |63| 3 | **User control & freedom** | Undo, cancel, exit, back navigation, escape hatches |64| 4 | **Consistency & standards** | Same words/actions mean same things, platform conventions |65| 5 | **Error prevention** | Confirmations for destructive actions, constraints, defaults |66| 6 | **Recognition over recall** | Visible options, contextual help, no memorization required |67| 7 | **Flexibility & efficiency** | Shortcuts, customization, accelerators for experts |68| 8 | **Aesthetic & minimalist** | No irrelevant info, clear hierarchy, signal vs noise |69| 9 | **Help users with errors** | Plain language errors, specific problem, constructive solution |70| 10 | **Help & documentation** | Searchable, task-focused, concise, accessible when needed |7172### Step 4: Score Severity7374Rate each issue found:7576| Score | Severity | Description |77|-------|----------|-------------|78| 0 | Not a problem | Disagreement with heuristic but not usability issue |79| 1 | Cosmetic | Fix only if time permits |80| 2 | Minor | Low priority, causes minor friction |81| 3 | Major | High priority, significant impact on task completion |82| 4 | Catastrophic | Must fix before release, prevents task completion |8384**Scoring factors**:85- Frequency: How often does user encounter this?86- Impact: How much does it block the task?87- Persistence: Can users work around it?8889### Step 5: Prioritize Output9091Rank issues by: Severity × Frequency9293Group into:941. **Fix immediately** (Severity 4, or Severity 3 + high frequency)952. **Fix soon** (Severity 3, or Severity 2 + high frequency)963. **Fix later** (Severity 1-2, low frequency)9798## Output Template99100**Automatically save the output to `design/08-heuristic-evaluation.md` using the Write tool** while presenting it to the user.101102```markdown103## Heuristic Evaluation: [Interface Name]104105**Evaluated**: [Date]106**Framework**: Nielsen's 10 Usability Heuristics107**Scope**: [Specific flow or screens evaluated]108109### Summary110- Critical issues: [count]111- Major issues: [count] 112- Minor issues: [count]113114### Critical Issues (Fix Immediately)115116#### Issue 1: [Brief description]117- **Heuristic violated**: #[number] — [name]118- **Location**: [Where in the interface]119- **Problem**: [What's wrong]120- **Impact**: [How it affects users]121- **Recommendation**: [How to fix]122- **Severity**: [0-4]123124[Repeat for each critical issue]125126### Major Issues (Fix Soon)127[Same format]128129### Minor Issues (Fix Later)130[Same format, can be condensed to a table]131132### Strengths Observed133- [What the interface does well]134135### Next Steps1361. [Prioritized action]1372. [Prioritized action]138```139140## Adaptive Behavior141142**If user provides a screenshot:**143- Analyze visually144- Call out specific elements by location145- Be concrete: "The save button in the top right..." not "buttons should..."146147**If user describes interface:**148- Ask clarifying questions before evaluating149- Focus on described pain points first150151**If user is designer:**152- Skip heuristic definitions153- Use shorthand: "H4 violation" instead of explaining consistency154155**If user is developer:**156- Include implementation-aware suggestions157- Note which fixes are quick wins vs architectural changes158159## Handoff160161After presenting the evaluation, suggest:162> "Use this report to prioritize fixes. Want me to help refine any screens based on these findings?"163164**Note:** File is automatically saved to `design/08-heuristic-evaluation.md` for reference.165166## Integration Points167168Works well with:169- `assumption-mapping` — before building, question if the design addresses real needs170- `critique` — for broader feedback beyond usability171- `accessibility-audit` — for WCAG-specific evaluation172173## References174175- [references/frameworks.md](references/frameworks.md) — Full heuristic definitions and alternatives176- [references/examples.md](references/examples.md) — Sample evaluations