| 1 | # Heuristics Scoring Guide |
| 2 | |
| 3 | Score each of Nielsen's 10 Usability Heuristics on a 0–4 scale. Be honest: a 4 means genuinely excellent, not "good enough." |
| 4 | |
| 5 | ## Nielsen's 10 Heuristics |
| 6 | |
| 7 | ### 1. Visibility of System Status |
| 8 | |
| 9 | Keep users informed about what's happening through timely, appropriate feedback. |
| 10 | |
| 11 | **Check for**: |
| 12 | - Loading indicators during async operations |
| 13 | - Confirmation of user actions (save, submit, delete) |
| 14 | - Progress indicators for multi-step processes |
| 15 | - Current location in navigation (breadcrumbs, active states) |
| 16 | - Form validation feedback (inline, not just on submit) |
| 17 | |
| 18 | **Scoring**: |
| 19 | | Score | Criteria | |
| 20 | |-------|----------| |
| 21 | | 0 | No feedback; user is guessing what happened | |
| 22 | | 1 | Rare feedback; most actions produce no visible response | |
| 23 | | 2 | Partial; some states communicated, major gaps remain | |
| 24 | | 3 | Good; most operations give clear feedback, minor gaps | |
| 25 | | 4 | Excellent; every action confirms, progress is always visible | |
| 26 | |
| 27 | ### 2. Match Between System and Real World |
| 28 | |
| 29 | Speak the user's language. Follow real-world conventions. Information appears in natural, logical order. |
| 30 | |
| 31 | **Check for**: |
| 32 | - Familiar terminology (no unexplained jargon) |
| 33 | - Logical information order matching user expectations |
| 34 | - Recognizable icons and metaphors |
| 35 | - Domain-appropriate language for the target audience |
| 36 | - Natural reading flow (left-to-right, top-to-bottom priority) |
| 37 | |
| 38 | **Scoring**: |
| 39 | | Score | Criteria | |
| 40 | |-------|----------| |
| 41 | | 0 | Pure tech jargon, alien to users | |
| 42 | | 1 | Mostly confusing; requires domain expertise to navigate | |
| 43 | | 2 | Mixed; some plain language, some jargon leaks through | |
| 44 | | 3 | Mostly natural; occasional term needs context | |
| 45 | | 4 | Speaks the user's language fluently throughout | |
| 46 | |
| 47 | ### 3. User Control and Freedom |
| 48 | |
| 49 | Users need a clear "emergency exit" from unwanted states without extended dialogue. |
| 50 | |
| 51 | **Check for**: |
| 52 | - Undo/redo functionality |
| 53 | - Cancel buttons on forms and modals |
| 54 | - Clear navigation back to safety (home, previous) |
| 55 | - Easy way to clear filters, search, selections |
| 56 | - Escape from long or multi-step processes |
| 57 | |
| 58 | **Scoring**: |
| 59 | | Score | Criteria | |
| 60 | |-------|----------| |
| 61 | | 0 | Users get trapped; no way out without refreshing | |
| 62 | | 1 | Difficult exits; must find obscure paths to escape | |
| 63 | | 2 | Some exits; main flows have escape, edge cases don't | |
| 64 | | 3 | Good control; users can exit and undo most actions | |
| 65 | | 4 | Full control; undo, cancel, back, and escape everywhere | |
| 66 | |
| 67 | ### 4. Consistency and Standards |
| 68 | |
| 69 | Users shouldn't wonder whether different words, situations, or actions mean the same thing. |
| 70 | |
| 71 | **Check for**: |
| 72 | - Consistent terminology throughout the interface |
| 73 | - Same actions produce same results everywhere |
| 74 | - Platform conventions followed (standard UI patterns) |
| 75 | - Visual consistency (colors, typography, spacing, components) |
| 76 | - Consistent interaction patterns (same gesture = same behavior) |
| 77 | |
| 78 | **Scoring**: |
| 79 | | Score | Criteria | |
| 80 | |-------|----------| |
| 81 | | 0 | Inconsistent everywhere; feels like different products stitched together | |
| 82 | | 1 | Many inconsistencies; similar things look/behave differently | |
| 83 | | 2 | Partially consistent; main flows match, details diverge | |
| 84 | | 3 | Mostly consistent; occasional deviation, nothing confusing | |
| 85 | | 4 | Fully consistent; cohesive system, predictable behavior | |
| 86 | |
| 87 | ### 5. Error Prevention |
| 88 | |
| 89 | Better than good error messages is a design that prevents problems in the first place. |
| 90 | |
| 91 | **Check for**: |
| 92 | - Confirmation before destructive actions (delete, overwrite) |
| 93 | - Constraints preventing invalid input (date pickers, dropdowns) |
| 94 | - Smart defaults that reduce errors |
| 95 | - Clear labels that prevent misunderstanding |
| 96 | - Autosave and draft recovery |
| 97 | |
| 98 | **Scoring**: |
| 99 | | Score | Criteria | |
| 100 | |-------|----------| |
| 101 | | 0 | Errors easy to make; no guardrails anywhere | |
| 102 | | 1 | Few safeguards; some inputs validated, most aren't | |
| 103 | | 2 | Partial prevention; common errors caught, edge cases slip | |
| 104 | | 3 | Good prevention; most error paths blocked proactively | |
| 105 | | 4 | Excellent; errors nearly impossible through smart constraints | |
| 106 | |
| 107 | ### 6. Recognition Rather Than Recall |
| 108 | |
| 109 | Minimize memory load. Make objects, actions, and options visible or easily retrievable. |
| 110 | |
| 111 | **Check for**: |
| 112 | - Visible options (not buried in hidden menus) |
| 113 | - Contextual help when needed (tooltips, inline hints) |
| 114 | - Recent items and history |
| 115 | - Autocomplete and suggestions |
| 116 | - Labels on icons (not icon-only navigation) |
| 117 | |
| 118 | **Scoring**: |
| 119 | | Score | Criteria | |
| 120 | |-------|----------| |
| 121 | | 0 | Heavy memorization; users must remember paths and commands | |
| 122 | | 1 | Mostly recall; many hidden features, few visible cues | |
| 123 | | 2 | Some aids; main actions visible, secondary features hidden | |
| 124 | | 3 | Good recognition; most things discoverable, few memory demands | |
| 125 | | 4 | Everything discoverable; users never need to memorize | |
| 126 | |
| 127 | ### 7. Flexibility and Efficiency of Use |
| 128 | |
| 129 | Accelerators, invisible to novices, speed up expert interaction. |
| 130 | |
| 131 | **Check for**: |
| 132 | - Keyboard shortcuts for common actions |
| 133 | - Customizable interface elements |
| 134 | - Recent items and favorites |
| 135 | - Bulk/batch actions |
| 136 | - Power user features that don't complicate the basics |
| 137 | |
| 138 | **Scoring**: |
| 139 | | Score | Criteria | |
| 140 | |-------|----------| |
| 141 | | 0 | One rigid path; no shortcuts or alternatives | |
| 142 | | 1 | Limited flexibility; few alternatives to the main path | |
| 143 | | 2 | Some shortcuts; basic keyboard support, limited bulk actions | |
| 144 | | 3 | Good accelerators; keyboard nav, some customization | |
| 145 | | 4 | Highly flexible; multiple paths, power features, customizable | |
| 146 | |
| 147 | ### 8. Aesthetic and Minimalist Design |
| 148 | |
| 149 | Interfaces should not contain irrelevant or rarely needed information. Every element should serve a purpose. |
| 150 | |
| 151 | **Check for**: |
| 152 | - Only necessary information visible at each step |
| 153 | - Clear visual hierarchy directing attention |
| 154 | - Purposeful use of color and emphasis |
| 155 | - No decorative clutter competing for attention |
| 156 | - Focused, uncluttered layouts |
| 157 | |
| 158 | **Scoring**: |
| 159 | | Score | Criteria | |
| 160 | |-------|----------| |
| 161 | | 0 | Overwhelming; everything competes for attention equally | |
| 162 | | 1 | Cluttered; too much noise, hard to find what matters | |
| 163 | | 2 | Some clutter; main content clear, periphery noisy | |
| 164 | | 3 | Mostly clean; focused design, minor visual noise | |
| 165 | | 4 | Perfectly minimal; every element earns its pixel | |
| 166 | |
| 167 | ### 9. Help Users Recognize, Diagnose, and Recover from Errors |
| 168 | |
| 169 | Error messages should use plain language, precisely indicate the problem, and constructively suggest a solution. |
| 170 | |
| 171 | **Check for**: |
| 172 | - Plain language error messages (no error codes for users) |
| 173 | - Specific problem identification ("Email is missing @" not "Invalid input") |
| 174 | - Actionable recovery suggestions |
| 175 | - Errors displayed near the source of the problem |
| 176 | - Non-blocking error handling (don't wipe the form) |
| 177 | |
| 178 | **Scoring**: |
| 179 | | Score | Criteria | |
| 180 | |-------|----------| |
| 181 | | 0 | Cryptic errors; codes, jargon, or no message at all | |
| 182 | | 1 | Vague errors; "Something went wrong" with no guidance | |
| 183 | | 2 | Clear but unhelpful; names the problem but not the fix | |
| 184 | | 3 | Clear with suggestions; identifies problem and offers next steps | |
| 185 | | 4 | Perfect recovery; pinpoints issue, suggests fix, preserves user work | |
| 186 | |
| 187 | ### 10. Help and Documentation |
| 188 | |
| 189 | Even if the system is usable without docs, help should be easy to find, task-focused, and concise. |
| 190 | |
| 191 | **Check for**: |
| 192 | - Searchable help or documentation |
| 193 | - Contextual help (tooltips, inline hints, guided tours) |
| 194 | - Task-focused organization (not feature-organized) |
| 195 | - Concise, scannable content |
| 196 | - Easy access without leaving current context |
| 197 | |
| 198 | **Scoring**: |
| 199 | | Score | Criteria | |
| 200 | |-------|----------| |
| 201 | | 0 | No help available anywhere | |
| 202 | | 1 | Help exists but hard to find or irrelevant | |
| 203 | | 2 | Basic help; FAQ or docs exist, not contextual | |
| 204 | | 3 | Good documentation; searchable, mostly task-focused | |
| 205 | | 4 | Excellent contextual help; right info at the right moment | |
| 206 | |
| 207 | --- |
| 208 | |
| 209 | ## Score Summary |
| 210 | |
| 211 | **Total possible**: 40 points (10 heuristics × 4 max) |
| 212 | |
| 213 | | Score Range | Rating | What It Means | |
| 214 | |-------------|--------|---------------| |
| 215 | | 36–40 | Excellent | Minor polish only; ship it | |
| 216 | | 28–35 | Good | Address weak areas, solid foundation | |
| 217 | | 20–27 | Acceptable | Significant improvements needed before users are happy | |
| 218 | | 12–19 | Poor | Major UX overhaul required; core experience broken | |
| 219 | | 0–11 | Critical | Redesign needed; unusable in current state | |
| 220 | |
| 221 | --- |
| 222 | |
| 223 | ## Issue Severity (P0–P3) |
| 224 | |
| 225 | Tag each individual issue found during scoring with a priority level: |
| 226 | |
| 227 | | Priority | Name | Description | Action | |
| 228 | |----------|------|-------------|--------| |
| 229 | | **P0** | Blocking | Prevents task completion entirely | Fix immediately; this is a showstopper | |
| 230 | | **P1** | Major | Causes significant difficulty or confusion | Fix before release | |
| 231 | | **P2** | Minor | Annoyance, but workaround exists | Fix in next pass | |
| 232 | | **P3** | Polish | Nice-to-fix, no real user impact | Fix if time permits | |
| 233 | |
| 234 | **Tip**: If you're unsure between two levels, ask: "Would a user contact support about this?" If yes, it's at least P1. |
| 235 |