Nielsen's 10 usability heuristics

Live demo: violating and fixed states

You understand a heuristic fastest when you see a screen that breaks it. Below I've put two states of the same small screen for four heuristics.

Under each state I've written why the screen counts as a violation or what changed. Without JavaScript, both states of all four examples show one under the other.

Try it

1. Visibility of system status

Violation

Money transfer

To: Anna S. · $2,500.00

Send

You pressed the button. The screen stays the same for six seconds.

Why it's a violation: the user doesn't know whether the transfer started. With that uncertainty they may press the button a second time.

Fixed

Money transfer

To: Anna S. · $2,500.00

Sending. Step 2 of 3: waiting for your bank's approval.

What changed: the screen gives feedback the moment the button is pressed. The step and the progress are visible, so there's no need to press again.

3. User control and freedom

Violation

My cart (2 items)

Item removed.

You removed the wireless headphones by mistake. To get them back you have to search for them again.

Why it's a violation: a wrong tap can't be undone. The user can only fix their mistake by searching for the item again.

Fixed

My cart (2 items)

Wireless headphones removed from your cart.

Undo

What changed: an "Undo" button appears the moment the item is removed. One tap fixes the mistake.

5. Error prevention

Violation

Send by account number

IBAN: GB29NWBK60161331926819

Amount: $25,000.00

Send

Why it's a violation: one wrong character and the money can go to someone else. The screen sends a large amount without asking for confirmation.

Fixed

Confirm the transfer

Recipient: A*** S***

Amount: $25,000.00

Is this the account holder you expect?

Confirm and send

What changed: there's a summary and a confirmation step before the risky action. The user sees the mistake before the money leaves.

9. Help users recognise, diagnose and recover from errors

Violation

Tax ID number

[ empty field ]

Error: ERR_VAL_1043. Operation failed.

Why it's a violation: the message gives a code, not the problem. And the value that was entered has been wiped.

Fixed

Tax ID number

12345678

The number has 9 digits and you entered 8. Check for a missing digit.

What changed: the message is in plain language, points to the exact problem and suggests a fix. The entered value stays in place.

The same small screen in a violating and a fixed state, for four heuristics. Pick the heuristic first, then the state. The examples are illustrative and don't belong to any particular app.

Origin: 1990, 1994 and 2020

Jakob Nielsen drew up the first list with Rolf Molich in 1990. It was written for an inspection method called heuristic evaluation.

In 1994 Nielsen revisited the list. He ran a factor analysis on 249 usability problems and refined the heuristics. The NN/g article was first published on 24 April 1994.

The article was updated in 2020. Kate Moran and Feifei Liu refreshed the names, descriptions and examples of the heuristics and added new examples.

That update refined the wording of the definitions a little. According to NN/g, the ten heuristics themselves have stayed the same since 1994. The page was last reviewed on 30 January 2024.

Why "heuristic"? Because they're broad rules of thumb. They don't tell you "put this button there"; they make you ask "does the user know what's going on?"

The 10 heuristics, one by one

For each heuristic I've written what it means, an interface example and a question to check against. The examples are illustrative and don't target any particular bank or shop.

1. Visibility of system status

What it means: the system tells users what is going on, through appropriate feedback within a reasonable amount of time.

Example: on an online shop, someone has pressed "Complete order". If the screen freezes, they can't tell whether the payment went through. The button changing to "Taking payment" and then a confirmation screen with the order number meets this heuristic.

Check: can the user always see where they are and what state their task is in?

2. Match between the system and the real world

What it means: the interface speaks the user's language and follows the order they're used to. The company's internal jargon stays off the screen.

Example: writing "In fulfillment" in order tracking is a violation. "Getting ready to ship" gives the same information in the user's words. This heuristic is about matching the screen to the mental model in the user's head.

Check: would a customer understand every word on the screen without asking anyone at the company?

3. User control and freedom

What it means: people do things by mistake. They need a clearly marked way out of an action they didn't want: undo or cancel.

Example: if a five-step loan application has no "Back" button, the user has to start over to fix a single mistake. Every step should let them go back with what they entered kept.

Check: after a wrong tap, can the user go back without losing anything?

4. Consistency and standards

What it means: the same thing has the same name and behaves the same way everywhere. The usual conventions of the platform and the industry are followed.

Example: if an app calls the same feature "Cart" on one screen and "My bag" on another, users may think they're two different places.

Check: does the same thing carry the same name and sit in the same place on every screen?

5. Error prevention

What it means: better than a good error message is a design that prevents the error in the first place. Risky actions ask for confirmation first.

Example: asking for a date of birth as free text invites invalid entries such as "31/02/1990". Separate fields for day, month and year, or a date picker, stop the error before it happens. The transfer confirmation in the demo is the same heuristic in banking.

Check: before an action that's hard to undo, does the user see once more what they're doing?

6. Recognition rather than recall

What it means: options and the information needed are visible. Users don't have to rely on memory to carry information from one screen to the next.

Example: making people type an order number to track a parcel relies on recall. Tapping the order in "My orders" to see its tracking relies on recognition. A "Recent recipients" list in banking does the same job.

Check: does the user have to keep anything in mind from the previous screen?

7. Flexibility and efficiency of use

What it means: shortcuts that novices don't see speed up experienced users. Frequent tasks can be personalised.

Example: for someone who sends rent to the same person every month, a "Repeat this transfer" button or a standing order cuts the task to seconds. A first-time user can ignore the shortcut and follow the normal flow.

Check: does someone who does this every day go through as many steps as someone doing it for the first time?

8. Aesthetic and minimalist design

What it means: the interface doesn't contain information that is irrelevant or rarely needed. Every extra element competes with the relevant information for attention.

Example: if a banking app's home screen shows six promotion cards before the balance, users have to hunt for the thing they look at most. Moving the promotions back brings the balance forward.

Check: which element could you remove from this screen without anyone noticing?

9. Help users recognise, diagnose and recover from errors

What it means: error messages are written in plain language without codes, point to the exact problem and suggest a solution.

Example: "Transaction declined (05)" at card payment leaves the user stuck. "Your card seems to have expired. Check the date on the card or choose another card." says what happened and what to do.

Check: does the person reading the message know what to do without calling support?

10. Help and documentation

What it means: it's best if the system needs no explanation. If help is needed, it's easy to search and focused on the user's task at that moment.

Example: a government application form that asks for a "Tax ID number" can put a "Where do I find this?" link next to the field. That link helps more than sending people to a long, general FAQ page.

Check: is the help where the user gets stuck, or on a separate page?

Using the heuristics in an evaluation

The heuristics are most useful in a heuristic evaluation. In this method each evaluator reviews the interface on their own and notes every violation with the related heuristic. Users don't take part.

Moran and Gordon's 2023 NN/g guide suggests three steps. First everyone reads the heuristics and the scope is narrowed to a single task, section or device. Then each evaluator works independently, and finally the team groups the findings and discusses the most harmful problems.

How many people do you need? According to Nielsen's 1994 article, averaged over six projects, a single evaluator found only 35% of the problems. That's why Nielsen recommends three to five evaluators.

An evaluation session usually takes an hour or two. For large interfaces it's better to split it into several shorter sessions than to make one session longer.

I recommend writing the heuristic number next to every finding. That way the team doesn't get stuck for long on "is this a matter of taste, or is a heuristic broken?"

For a step-by-step method, see the UX audit guide.

Limits and misunderstandings

It doesn't replace user testing. NN/g's evaluation guide says so plainly. The heuristics point to likely problems. You only see where real users get stuck in a test with a prototype or the live product.

Not every violation is a problem. According to the same guide, a design decision that breaks a heuristic isn't always wrong; the right answer depends on the context. Deliberate violations should be rare and justified by user research first.

It doesn't produce solutions. Nielsen's 1994 article says the method doesn't produce a systematic way to fix problems. The list of findings shows where the problem is. The fix is still a separate design job.

Severity is a separate job. A violation that stops the checkout shouldn't sit on the list with the same weight as an inconsistent label. That's why the list of fixes I hand over in an audit is prioritised.

"Minimalist" doesn't mean flat design. According to NN/g, heuristic 8 doesn't require flat design; it asks you to remove irrelevant information. A grey, icon-free screen full of irrelevant information is still a violation.

It isn't an accessibility audit. Because the ten heuristics are general, they don't cover measurable checks such as contrast ratios or screen reader labels. Those need their own checklist.

Related concepts

The ten heuristics are part of a wider approach. The definition of usability says what we're measuring. User-centred design shows where these checks sit in the process.

If a problem caught by heuristic 2 or 6 comes from the menu or the page structure, look at the information architecture page. Other laws and effects are listed under Laws of UX.