UX Heuristics Framework
Unverified●24/40Claude Code◐PartialHas SKILL.md but declares no allowed-tools — Claude Code will ask for permission each time
Cursor◐PartialPlain prose you can paste in — but no Cursor rules file
Codex◐PartialPlain prose you can paste in — but no AGENTS.md
Gemini CLI◐PartialPlain prose you can paste in
Copilot◐PartialPlain prose you can paste in — but no Copilot instructions file
npx agentalley add ux-heuristicsWho is stuck, and on what
People land on my website and leave without buying or signing up, and I have no idea why. I'm too close to it to see what's confusing.
What it gives you
A prioritized, plain-language list of the spots that make visitors hesitate, each with a specific wording or layout fix you can hand to whoever built your site.
When NOT to use it
It won't redesign your site, build anything, or judge your visuals — it reviews clarity and wording from what you describe, not a live screenshot.
The whole source
Frontmatter — 4 properties
| name | ux-heuristics |
|---|---|
| description | Evaluate and improve interface usability using heuristic analysis. Use when the user mentions "usability audit", "users are confused", "form usability", "navigation problems", "Nielsen heuristics", "cognitive walkthrough", or "is this easy to use". Also trigger when reviewing a design for usability issues, improving form-completion rates, or evaluating information architecture and navigation. Covers Krug''s laws, Nielsen''s 10 heuristics, severity ratings, dark-pattern recognition, and accessibility. For visual design fixes, see refactoring-ui. For conversion-focused audits, see cro-methodology. |
| license | MIT |
| metadata | author: wondelai version: "1.6.0 |
| 1 | --- |
| 2 | name: ux-heuristics |
| 3 | description: 'Evaluate and improve interface usability using heuristic analysis. Use when the user mentions "usability audit", "users are confused", "form usability", "navigation problems", "Nielsen heuristics", "cognitive walkthrough", or "is this easy to use". Also trigger when reviewing a design for usability issues, improving form-completion rates, or evaluating information architecture and navigation. Covers Krug''s laws, Nielsen''s 10 heuristics, severity ratings, dark-pattern recognition, and accessibility. For visual design fixes, see refactoring-ui. For conversion-focused audits, see cro-methodology.'B1 — Line is 617 characters — unreadable by eye |
| 4 | license: MIT |
| 5 | metadata: |
| 6 | author: wondelai |
| 7 | version: "1.6.0" |
| 8 | ---A5 — No allowed-tools declared — no way to tell what this skill may touch |
| 9 | |
| 10 | # UX Heuristics Framework |
| 11 | |
| 12 | Practical usability principles for evaluating and improving user interfaces. Users don't read, they scan; they don't make optimal choices, they satisfice; they don't figure out how things work, they muddle through. |
| 13 | |
| 14 | ## Core Principle |
| 15 | |
| 16 | **"Don't Make Me Think"** — every page should be self-evident. If something requires thinking, it's a usability problem. Users have limited patience and cognitive bandwidth, so design for the scanning, satisficing, and muddling-through behavior described above. |
| 17 | |
| 18 | ## Scoring |
| 19 | |
| 20 | **Goal: 10/10.** Audit the interface, rate every issue on the severity scale below, then score the interface from its Quick Diagnostic results: start at 10 and subtract per failed diagnostic row, weighted by the worst severity it triggers (catastrophic/major rows cost ~2, minor/cosmetic ~1). Bands: **9-10** = no severity-3+ issues and ≤1 failed diagnostic row; **6-8** = some major issues or several failed rows; **3-5** = a catastrophic issue or many failed rows; **≤2** = core tasks blocked. Always state the current score, the highest-severity issues, and the specific fixes needed to reach 10/10.B1 — Line is 602 characters — unreadable by eye |
| 21 | |
| 22 | ## Krug's Usability Principles |
| 23 | |
| 24 | Laws 1-3 are Krug's Three Laws of Usability; #4, the Trunk Test, is his navigation orientation check. |
| 25 | |
| 26 | ### 1. Don't Make Me Think |
| 27 | |
| 28 | **Core concept:** Every question mark that pops into a user's head adds cognitive load and distracts from the task. |
| 29 | |
| 30 | **Why it works:** Users are on a mission — they don't want to puzzle over labels or decode clever marketing language. The less thinking required, the more likely they complete the task. |
| 31 | |
| 32 | **Key insights:** |
| 33 | - Clever names lose to clear names every time |
| 34 | - Marketing-speak creates friction; plain language removes it |
| 35 | - Unfamiliar categories force users to stop and interpret |
| 36 | - Ambiguous links and buttons cause hesitation |
| 37 | |
| 38 | **Product applications:** |
| 39 | |
| 40 | | Context | Application | Example | |
| 41 | |---------|-------------|---------| |
| 42 | | **Navigation labels** | Self-evident names | "Get directions" not "Calculate route to destination" | |
| 43 | | **CTAs** | Action verbs users understand | "Sign in" not "Access your account portal" | |
| 44 | | **Error states** | Tell users what to do next | "Check your email format" not "Validation error" | |
| 45 | |
| 46 | **Copy patterns:** |
| 47 | - Action-oriented buttons: verb + noun ("Create account", "Download report")A4 — This skill pulls in web or user content but never says to treat that content as data. A signal, not proof. |
| 48 | - Avoid jargon: "Save" not "Persist", "Remove" not "Disassociate" |
| 49 | - If a label needs explanation, simplify the label |
| 50 | |
| 51 | **Ethical boundary:** Clarity should serve users — never use plain language as a veneer to hide unfavorable terms. |
| 52 | |
| 53 | See: [references/krug-principles.md](references/krug-principles.md) when you need the full Krug method — scanning/satisficing/muddling psychology, the goodwill reservoir, homepage and tagline guidance, and the $0 usability-testing protocol (how many users, the test script). |
| 54 | |
| 55 | ### 2. It Doesn't Matter How Many Clicks |
| 56 | |
| 57 | **Core concept:** The myth says "users leave after 3 clicks." In reality users don't mind clicks if each one is painless, obvious, and confidence-building. |
| 58 | |
| 59 | **Why it works:** Cognitive effort per click matters more than click count. Users abandon when they lose confidence, not when they run out of patience for clicking. |
| 60 | |
| 61 | **Key insights:** |
| 62 | - Each click should be painless, obvious, and confidence-building |
| 63 | - Three mindless clicks beat one click that requires deliberation |
| 64 | - Shallow nav with clear labels beats deep nav with vague ones |
| 65 | |
| 66 | **Product applications:** |
| 67 | |
| 68 | | Context | Application | Example | |
| 69 | |---------|-------------|---------| |
| 70 | | **Checkout flows** | Make each step obvious | Clear step indicators with descriptive labels | |
| 71 | | **Settings** | Clear categories over flat lists | "Account > Security > Change password" (3 confident clicks) | |
| 72 | | **Onboarding** | Small, clear steps | Wizard with one clear action per step | |
| 73 | |
| 74 | **Copy patterns:** |
| 75 | - Progress indicators: "Step 2 of 4: Shipping details" |
| 76 | - Confirmations at each step: "Great, your email is verified. Now let's set up your profile." |
| 77 | - Clear link text: "View all running shoes" not "Click here" |
| 78 | |
| 79 | **Ethical boundary:** Never use extra steps to bury cancellation flows — every click should move users toward their goal, not away from it. |
| 80 | |
| 81 | ### 3. Get Rid of Half the Words |
| 82 | |
| 83 | **Core concept:** Remove half the words on each page, then half of what's left. Brevity makes useful content prominent and respects the user's time. |
| 84 | |
| 85 | **Key insights:** |
| 86 | - Happy-talk ("Welcome to our website!") wastes space |
| 87 | - Instructions nobody reads should be removed |
| 88 | - "Please" and "Kindly" and polite fluff add noise |
| 89 | - Shorter pages mean less scrolling and faster scanning |
| 90 | |
| 91 | **Product applications:** |
| 92 | |
| 93 | | Context | Application | Example | |
| 94 | |---------|-------------|---------| |
| 95 | | **Landing pages** | Cut welcome copy, lead with value | Remove "Welcome to..." paragraphs | |
| 96 | | **Error messages** | State problem and fix, nothing more | "Password too short (min 8 chars)" | |
| 97 | | **Empty states** | Action-oriented, minimal | "No results. Try a different search." | |
| 98 | |
| 99 | **Copy patterns:** |
| 100 | - Before: "Please kindly note that you will need to enter your password in order to proceed to the next step." → After: "Enter your password to continue." |
| 101 | - Before: "We've received your message and will get back to you as soon as possible." → After: "Message sent. We'll reply within 24 hours." |
| 102 | |
| 103 | **Ethical boundary:** Brevity must not omit critical information — concise disclosures for pricing, terms, and data usage are a user right. |
| 104 | |
| 105 | ### 4. The Trunk Test |
| 106 | |
| 107 | **Core concept:** Drop a user on any random page (like being released from a car trunk at a random spot) — they should instantly answer six orientation questions: What site is this? What page? What are the major sections? What are my options here? Where am I in the hierarchy? Where's search? |
| 108 | |
| 109 | **Why it works:** Good navigation gives constant orientation. Users who can't tell where they are feel lost and leave. |
| 110 | |
| 111 | Apply it as the navigation check: page titles must match the link the user clicked, a "you are here" indicator (highlighted nav item, bold breadcrumb) must be present, and section headings must orient ("Your Account > Billing" not just "Settings"). |
| 112 | |
| 113 | **Ethical boundary:** Navigation labels must honestly represent site structure — never use misleading labels to funnel users into marketing pages. |
| 114 | |
| 115 | See: [references/krug-principles.md](references/krug-principles.md) when running the Trunk Test or designing navigation — it maps each of the six questions to the page element that answers it, plus breadcrumb and permanent-navigation rules. |
| 116 | |
| 117 | ## Nielsen's 10 Usability Heuristics |
| 118 | |
| 119 | ### 1. Visibility of System Status |
| 120 | Keep users informed through timely feedback. Every action needs acknowledgment — progress bars for uploads, confirmations for submissions, skeleton screens for loading. Silent failures destroy trust. Copy pattern: "Saving..." → "Saved". |
| 121 | |
| 122 | ### 2. Match Between System and Real World |
| 123 | Speak users' language: "Sign in" not "Authenticate", "Search" not "Query." Follow real-world metaphors (trash bin, shopping cart) and natural ordering (street → city → state → zip). |
| 124 | |
| 125 | ### 3. User Control and Freedom |
| 126 | Provide clear "emergency exits." Undo beats "Are you sure?" dialogs — users click through confirmations without reading. Every flow needs cancel/exit, and back buttons must never break. |
| 127 | |
| 128 | ### 4. Consistency and Standards |
| 129 | Same words, styles, and behaviors mean the same thing throughout. Internal consistency (your app) plus external consistency (platform conventions: logo top-left, search top-right). One term per concept — "Projects" everywhere, never mixed with "Workspaces." |
| 130 | |
| 131 | ### 5. Error Prevention |
| 132 | Prevent problems before they occur: constrained inputs (date pickers over text fields), autocomplete, sensible defaults, "unsaved changes" warnings. Slips (accidental wrong action) and mistakes (wrong intention) need different prevention. |
| 133 | |
| 134 | ### 6. Recognition Rather Than Recall |
| 135 | Minimize memory load — show options, don't require memorization. Breadcrumbs, recent searches, pre-filled fields, dropdowns with decoded values. Working memory holds ~7 items; recognition is far easier than recall. |
| 136 | |
| 137 | ### 7. Flexibility and Efficiency of Use |
| 138 | Serve both novices and experts: keyboard shortcuts, bulk actions, saved searches, command palettes (Cmd+K). Progressive disclosure keeps it simple for beginners while experts access full power. |
| 139 | |
| 140 | ### 8. Aesthetic and Minimalist Design |
| 141 | Every element must earn its place — when everything screams for attention, nothing stands out. Show what matters now, hide what doesn't. One primary CTA per page. |
| 142 | |
| 143 | ### 9. Help Users Recognize, Diagnose, and Recover from Errors |
| 144 | Error messages need three parts: what happened, why, and how to fix it. Plain language ("Connection failed" not "ECONNREFUSED"), specific ("Password must be 8+ characters" not "Invalid"), never blame the user, preserve their input. |
| 145 | |
| 146 | ### 10. Help and Documentation |
| 147 | Help should be searchable, task-focused ("How to..." not technical reference), and contextual (tooltips, inline hints, guided tours). |
| 148 | |
| 149 | See: [references/nielsen-heuristics.md](references/nielsen-heuristics.md) when auditing against a specific heuristic — it expands each of the 10 into good-implementation / common-violation / severity tables with copy patterns and ethical boundaries. |
| 150 | |
| 151 | ## Severity Rating Scale |
| 152 | |
| 153 | Rate each issue found in an audit: |
| 154 | |
| 155 | | Severity | Rating | Description | Priority | |
| 156 | |----------|--------|-------------|----------| |
| 157 | | **0** | Not a problem | Disagreement, not usability issue | Ignore | |
| 158 | | **1** | Cosmetic | Minor annoyance, low impact | Fix if time | |
| 159 | | **2** | Minor | Causes delay or frustration | Schedule fix | |
| 160 | | **3** | Major | Significant task failure | Fix soon | |
| 161 | | **4** | Catastrophic | Prevents task completion | Fix immediately | |
| 162 | |
| 163 | Weigh three factors: **frequency** (how often it occurs), **impact** (how severe when it occurs), **persistence** (one-time or ongoing). |
| 164 | |
| 165 | See: [references/audit-template.md](references/audit-template.md) when running a full heuristic evaluation — a structured per-screen template that captures issues, severity, and recommended fixes in a consistent format. |
| 166 | |
| 167 | ## Common Mistakes |
| 168 | |
| 169 | | Mistake | Why It Fails | Fix | |
| 170 | |---------|-------------|------| |
| 171 | | **Mystery meat navigation** | Icons without labels force guessing | Add text labels alongside icons | |
| 172 | | **Too many choices** | Decision paralysis slows users | Reduce to 7 plus/minus 2 items | |
| 173 | | **No "you are here" indicator** | Users feel lost in the hierarchy | Highlight current section in nav and breadcrumbs | |
| 174 | | **No inline validation** | Submit, error, scroll cycle frustrates | Validate on blur with specific messages | |
| 175 | | **Unclear required fields** | Users confused about what's mandatory | Mark optional fields, not required | |
| 176 | | **Wall of text** | Nobody reads dense paragraphs | Break up with headings, bullets, whitespace | |
| 177 | | **Jargon in labels** | Users don't speak your internal language | User-test all labels, use plain language | |
| 178 | | **No loading indicators** | Users think the system is broken | Show spinner, progress bar, or skeleton screen | |
| 179 | | **Tiny tap targets** | Mobile users misclick constantly | Minimum 44x44 px touch targets | |
| 180 | | **Hover-only information** | Mobile and keyboard users miss it | Don't hide critical info behind hover | |
| 181 | | **No undo** | Users afraid to take any action | Provide undo for all non-destructive actions | |
| 182 | | **Poor error messages** | "Invalid input" tells users nothing | Explain what's wrong and how to fix it | |
| 183 | | **Low contrast text** | Unreadable for many users | WCAG AA minimum (4.5:1 contrast) | |
| 184 | | **Inconsistent nav location** | Users can't find navigation | Fixed position, same place on every page | |
| 185 | | **Broken back button** | Violates the browser contract | Never hijack or break browser history | |
| 186 | |
| 187 | See: [references/wcag-checklist.md](references/wcag-checklist.md) when auditing accessibility (contrast, keyboard, screen-reader, focus) — a complete WCAG 2.1 AA checklist with testing tools. See [references/cultural-ux.md](references/cultural-ux.md) when designing for global audiences — RTL layouts, color meanings, form/name/date conventions, and localization pitfalls. |
| 188 | |
| 189 | ## Quick Diagnostic |
| 190 | |
| 191 | | Question | If No | Action | |
| 192 | |----------|-------|--------| |
| 193 | | Can I tell what site/page this is immediately? | Users are lost | Add clear logo, page title, breadcrumbs | |
| 194 | | Is the main action obvious? | Users don't know what to do | Visual hierarchy, single primary CTA | |
| 195 | | Is the navigation clear? | Users can't find their way | Apply the Trunk Test, add "you are here" indicators | |
| 196 | | Can I find the search? | Goal-driven users are blocked | Visible search box in header | |
| 197 | | Does the system show what's happening? | Users lose trust and re-click | Loading states, confirmations, progress | |
| 198 | | Are error messages helpful? | Users get stuck | Plain language with a specific fix | |
| 199 | | Can users undo or go back? | Users are afraid to act | Undo, cancel, and back options everywhere | |
| 200 | | Does it work without hover? | Mobile/keyboard users excluded | Visible alternatives to hover interactions | |
| 201 | | Are all interactive elements labeled? | Users guess at icons | Text labels or descriptive tooltips | |
| 202 | | Does anything make me stop and think "huh?" | Cognitive load too high | Simplify — if it needs explanation, redesign it | |
| 203 | |
| 204 | ## Heuristic Conflicts |
| 205 | |
| 206 | Heuristics sometimes contradict each other. When they do: |
| 207 | - **Simplicity vs. Flexibility**: use progressive disclosure |
| 208 | - **Consistency vs. Context**: consistent patterns, contextual prominence |
| 209 | - **Efficiency vs. Error Prevention**: prefer undo over confirmation dialogs |
| 210 | - **Discoverability vs. Minimalism**: primary actions visible, secondary hidden |
| 211 | |
| 212 | See: [references/heuristic-conflicts.md](references/heuristic-conflicts.md) when two heuristics pull in opposite directions and the four rules above don't settle it — resolution frameworks with worked trade-off examples. |
| 213 | |
| 214 | ## Dark Patterns Recognition |
| 215 | |
| 216 | Dark patterns violate heuristics deliberately to manipulate users: forced continuity (hard to cancel), roach motel (easy in, hard out), confirmshaming (guilt-based options), hidden costs (surprise fees at checkout). |
| 217 | |
| 218 | See: [references/dark-patterns.md](references/dark-patterns.md) when you suspect a design manipulates rather than serves users — the complete taxonomy, ethical alternatives, and relevant regulations. |
| 219 | |
| 220 | ## When to Use Each Method |
| 221 | |
| 222 | | Method | When | Time | Findings | |
| 223 | |--------|------|------|----------| |
| 224 | | Heuristic evaluation | Before user testing | 1-2 hours | Major violations | |
| 225 | | User testing | After heuristic fixes | 2-4 hours | Real behavior | |
| 226 | | A/B testing | When optimizing | Days-weeks | Statistical validation | |
| 227 | | Analytics review | Ongoing | 30 min | Patterns and problems | |
| 228 | |
| 229 | ## Further Reading |
| 230 | |
| 231 | Based on usability principles developed by Steve Krug and Jakob Nielsen: |
| 232 | |
| 233 | - [*"Don't Make Me Think, Revisited"*](https://www.amazon.com/Dont-Make-Think-Revisited-Usability/dp/0321965515?tag=wondelai00-20) by Steve Krug |
| 234 | - [*"Rocket Surgery Made Easy"*](https://www.amazon.com/Rocket-Surgery-Made-Easy-Yourself/dp/0321657292?tag=wondelai00-20) by Steve Krug (DIY usability testing) |
| 235 | - [*"10 Usability Heuristics for User Interface Design"*](https://www.nngroup.com/articles/ten-usability-heuristics/) by Jakob Nielsen (Nielsen Norman Group) |
| 236 | |
| 237 | ## About the Author |
| 238 | |
| 239 | **Steve Krug** is a usability consultant whose *Don't Make Me Think* (2000, revised 2014) is the most widely read book on web usability. He demonstrated that usability testing doesn't require a lab or large budget — just watching a few real users try to accomplish tasks. |
| 240 | |
| 241 | **Jakob Nielsen, PhD** is co-founder of the Nielsen Norman Group and author of the 10 Usability Heuristics (1994), still the most-used framework for heuristic evaluation worldwide. *The New York Times* called him "the guru of Web page usability." |
| 242 |
Reviews
Installed this one?Write the first review and take the Trailblazer badge.
Alternatives
Brand Protection — Amazon 🛡️Amazon brand protection toolkit. Detect hijackers, counterfeits, and unauthorized sellers. Includes MAP violation monitoring, trademark abuse detection, complaint templates for Brand Registry, and test buy evidence collection guides. No API key required.◐····●35/40Brand Protection — eBay 🛡️eBay brand protection toolkit. Detect unauthorized sellers, counterfeits, and VeRO violations. Includes price monitoring, trademark abuse detection, VeRO complaint templates, and enforcement guides. No API key required.◐····●35/40Brand Protection — Shopify/DTC 🛡️Shopify/DTC brand protection toolkit. Detect counterfeit stores, unauthorized resellers, and trademark violations. Includes DMCA takedown templates, domain monitoring, and social media infringement detection. No API key required.◐····●35/40Brand Protection — TikTok Shop 🛡️TikTok Shop brand protection toolkit. Detect unauthorized sellers, counterfeit products, and affiliate abuse. Includes TikTok IP Protection reporting, influencer misuse detection, and complaint templates. No API key required.◐····●35/40