Nielsen's 10 usability heuristics are ten broad rules of thumb for judging an interface: show system status, speak the user's language, allow undo, stay consistent, prevent errors, favour recognition over recall, support experts, keep it minimal, help people recover from errors, and provide help. They are the checklist behind most heuristic evaluations.
Below, each heuristic gets a plain-English meaning, an example, and the UX law that explains why it works. That last part is the piece most guides skip.
The interface should always tell people what is going on, within a reasonable time. A file upload that shows a progress bar and an estimate follows this rule. A button that stays silent after you tap it breaks it.
Behind it: the Doherty Threshold says to respond within about 400 milliseconds, and Design Every State covers loading, empty and error moments. Check: tap every button and see whether something visibly changes at once.
Use the words and ideas your users already have, not your internal jargon. "Delete" beats "Terminate record", and a shopping cart icon works because people know carts.
Behind it: Information Architecture, which is about labelling and grouping things the way users do. Check: read every label aloud to someone outside the team and watch for a pause.
People make mistakes and need a clear way out: undo, cancel, back. Gmail's Undo Send is a well-known example. It turns a permanent action into a recoverable one.
Behind it: when software acts for you, an easy undo is part of earning Calibrated Trust. Check: pick a destructive action and look for the way back.
The same thing should work the same way, inside your product and across the web. A logo that returns to the home page and a magnifier that means search are standards worth keeping.
Behind it: the Alignment Principle and Token Layering, because consistent styling comes from shared rules, not from copying by eye. Check: find two screens that do the same job and compare them.
A good error message is worse than a design that stops the error. Confirm destructive actions, disable choices that cannot work, and accept input in more than one format.
Behind it: Postel's Law: be forgiving in what you accept. Check: type a phone number three different ways and see which ones the form takes.
Show options instead of asking people to remember them. A list of recent addresses beats typing one from memory.
Behind it: Miller's Law, since working memory is small, and Hick's Law, since long lists slow decisions. Check: look for any place that asks people to remember something from an earlier screen.
Offer shortcuts for experts without getting in the way of beginners. Keyboard shortcuts and saved filters are classic examples. The UX Quest challenge screens let you pick an answer with the number keys and confirm with Enter.
Behind it: Fitts's Law, which says to make frequent targets large and close. Check: time a frequent task for a new user and an experienced one.
Every extra element competes with the ones that matter. Cut what does not help the task, and the important parts get seen.
Behind it: the Aesthetic-Usability Effect, Density Matches Context and the Law of Pragnanz. Check: squint at the screen and see what stands out.
Say what went wrong in plain words and what to do next. "Error 402" does neither. "Your card was declined. Try another card or check the number" does both.
Behind it: Design Every State, because an error is a state that needs designing like any other. Check: trigger three errors on purpose and read each message as a stranger would.
The best interface needs no manual. When help is needed, make it short, searchable and tied to the task. A hint beside the confusing field beats a long help centre.
Behind it: Time-to-Value. The sooner people get a result, the less help they need. Check: watch where new users go looking for help, and put an answer there.
Heuristics are rules of thumb for judging a screen. UX laws describe how people behave. A heuristic tells you what to check, and the law often tells you why it matters.
| Heuristic | UX laws that explain it |
|---|---|
| Visibility of system status | Doherty Threshold, Design Every State |
| Match between the system and the real world | Information Architecture |
| User control and freedom | Calibrated Trust |
| Consistency and standards | Alignment Principle, Token Layering |
| Error prevention | Postel's Law |
| Recognition rather than recall | Miller's Law, Hick's Law |
| Flexibility and efficiency of use | Fitts's Law |
| Aesthetic and minimalist design | Aesthetic-Usability Effect, Density Matches Context, Law of Pragnanz |
| Help users recognise, diagnose and recover from errors | Design Every State |
| Help and documentation | Time-to-Value |
Run a heuristic evaluation on one flow with three to five people, rate each problem from 0 to 4, and fix the worst first. To build the eye for it, practise on real screens: every UX law in UX Quest comes with one, and each law page says whether its challenge is free or part of Pro.
Visibility of system status; match between the system and the real world; user control and freedom; consistency and standards; error prevention; recognition rather than recall; flexibility and efficiency of use; aesthetic and minimalist design; help users recognise, diagnose and recover from errors; and help and documentation.
Jakob Nielsen. He and Rolf Molich formalised heuristic evaluation in 1990, and Nielsen later refined the list into the ten heuristics people use today.
No. Heuristics are broad rules of thumb for judging an interface. UX laws describe how people behave, such as how quickly they decide or how much they can remember. The two work together: a heuristic says what to check, and a law often explains why it matters.
Walk through one flow, check each screen against the ten rules, and log every problem with the heuristic it breaks and a severity from 0 to 4. A group of three to five people does this best.
Yes, especially status, user control and error recovery. AI adds a question the list does not cover well: how far the person should trust the output. Calibrated Trust looks at that.