A practical guide to Jakob Nielsen's 10 usability heuristics. Learn each principle with real examples, common violations, and how to apply heuristic evaluation in your design process.
Jakob Nielsen's 10 usability heuristics, published in 1994, remain the most widely used framework for evaluating interface design. They are called "heuristics" rather than "rules" because they are broad principles of interaction design, not specific usability guidelines. They describe the qualities that usable interfaces share, and they provide a structured vocabulary for identifying and discussing usability problems.
The system should always keep users informed about what is going on, through appropriate feedback within a reasonable time.
When you upload a file, a progress bar tells you the system is working. When you submit a form, a confirmation message tells you it was received. When you click a button, a visual change (color shift, loading spinner) tells you the action registered. Without these signals, users do not know whether their action worked, which leads to repeated clicks, frustration, and errors.
Common violations: forms that submit silently without confirmation, buttons that look the same whether clicked or not, processes that run in the background without any indication of progress. If a user has to wonder "did that work?" the system has failed this heuristic.
The system should speak the users' language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
A shopping cart icon works because it maps to a real-world concept. "Add to cart" is universally understood. "Append item to persistent session-scoped collection" describes the same action in system language that no user would recognize. Use the vocabulary your users use, which you discover through user interviews, not the vocabulary your engineering team uses.
This heuristic also applies to information order. A checkout flow that asks for shipping address before payment method matches the real-world sequence of "where should we send it, then how are you paying." Reversing this order feels unnatural even if it is technically equivalent.
Users often perform actions by mistake. They need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended process. Support undo and redo.
Gmail's "undo send" feature is a textbook example. It gives users a brief window to reverse an action they might regret. More broadly, any destructive action (deleting, publishing, sending) should have either a confirmation step, an undo mechanism, or both.
Common violations: wizards with no "back" button, modal dialogs with no way to dismiss them, irreversible deletions without warning. The principle extends beyond undo: users should always feel in control of where they are in the interface and how to get somewhere else.
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
If "Save" means one thing on Page A and something different on Page B, users will be confused and make errors. If your application uses a blue button for primary actions throughout but switches to a green button on one page, users will hesitate because the pattern has changed. Consistency applies to terminology, visual design, interaction patterns, and information architecture.
External consistency matters too. If every other web application uses a gear icon for settings, using a wrench icon in your application forces users to learn a new convention for no benefit. Follow established patterns unless you have a strong reason to deviate, and recognize that "it looks more unique" is not a strong reason.
Even better than good error messages is a careful design that prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
A date picker that only shows valid dates prevents invalid date entry more effectively than an error message that says "invalid date format." A search field with autocomplete prevents typos more effectively than "no results found." A form that disables the submit button until all required fields are valid prevents incomplete submissions.
The distinction is between slips (unconscious errors, like clicking the wrong button) and mistakes (conscious errors based on incorrect mental models). Slips are prevented through design constraints. Mistakes are prevented through clear information and confirmation steps.
Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the interface to another. Instructions for use of the system should be visible or easily retrievable.
A dropdown menu with visible options is recognition. A text field where users must remember and type a command is recall. Recognition is easier because the options are present; recall requires retrieving information from memory without cues.
Common violations: interfaces that require users to memorize codes or abbreviations, search that requires exact spelling of product names, settings that were configured during onboarding and cannot be found later. If users have to remember where something is or what it was called, the interface is relying too heavily on recall.
Accelerators, unseen by the novice user, may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Keyboard shortcuts are the classic example. A new user navigates menus. An expert user presses Ctrl+S. Both accomplish the same task, but the expert path is faster. Other accelerators include saved searches, templates, recently used items, and customizable toolbars.
The key is that accelerators do not interfere with the basic experience. A novice should never need to use a keyboard shortcut. An expert should never be forced to use the menu. Both paths coexist without one degrading the other.
Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility.
This is not about making things "look nice." It is about signal-to-noise ratio. A dashboard with 50 metrics competes for attention in ways that make it harder to find the 3 metrics that actually matter. A form with 20 fields when only 5 are required creates unnecessary cognitive load.
The principle suggests progressive disclosure: show the essential information first, and make additional details available on demand. A product listing shows price, image, and title. Detailed specifications are one click away for users who need them.
Error messages should be expressed in plain language (not codes), precisely indicate the problem, and constructively suggest a solution.
"Error 500" violates this heuristic completely. "Your password must be at least 8 characters" is better because it states the problem and implies the solution. "Your password is 6 characters. Add at least 2 more characters to continue" is best because it states the problem, quantifies the gap, and tells the user exactly what to do.
Error messages are a critical part of the user experience, especially because users encounter them during moments of frustration. A helpful error message can turn a negative moment into a neutral or even positive one. A cryptic error message compounds the frustration.
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
The ideal is that users never need help documentation because the interface is self-explanatory. The reality is that complex systems require some documentation, especially for advanced features. When documentation is needed, it should be contextual (available at the point where the user needs it), task-oriented (organized around what users want to do, not how the system is structured), and concise.
A heuristic evaluation is a structured review where evaluators examine an interface against the 10 heuristics and document violations. It is one of the most cost-effective usability methods because it requires no users and can be done with existing team members.
Heuristic evaluation fits most naturally into the Test stage, but it can be applied at any point where you have a design to evaluate:
Heuristic evaluation and user testing are complementary. Heuristic evaluation catches violations of established principles. User testing reveals problems that heuristics miss, particularly issues related to users' domain knowledge, task context, and real-world workflows. Use both.
Heuristic evaluation is a fast, expert-driven complement to empirical testing. Pair it with user testing methods to catch the issues that heuristic review misses, and ground your evaluation criteria in accessibility-first principles so that inclusivity is part of every review rather than an afterthought. The Prototype stage is where heuristic evaluation delivers the most value, catching structural problems before user testing begins. Once you have shipped improvements, measuring design impact will help you quantify whether your heuristic fixes translated into real usability gains.
Related guides: design brief · dot voting prioritization · problem statement examples
Design Thinker Labs Home · All Guides · How It Works · Pricing