UX Heuristics Framework

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.

Core Principle

"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.

Scoring

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.

Krug's Usability Principles

Laws 1-3 are Krug's Three Laws of Usability; #4, the Trunk Test, is his navigation orientation check.

1. Don't Make Me Think

Core concept: Every question mark that pops into a user's head adds cognitive load and distracts from the task.

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.

Key insights:

• Clever names lose to clear names every time
• Marketing-speak creates friction; plain language removes it
• Unfamiliar categories force users to stop and interpret
• Ambiguous links and buttons cause hesitation

Product applications:

Copy patterns:

• Action-oriented buttons: verb + noun ("Create account", "Download report")
• Avoid jargon: "Save" not "Persist", "Remove" not "Disassociate"
• If a label needs explanation, simplify the label

Ethical boundary: Clarity should serve users — never use plain language