Nielsen's ten usability heuristics, applied
The cheapest useful thing you can do to a product nobody is happy with is inspect it against ten principles that have held up for thirty years. It finds defects fast, and the fixes come from the plan we build on it.
01Overview
Ten rules of thumb, and the inspection built on them
They are ten principles for interface design, published by Jakob Nielsen in 1994, from earlier work with Rolf Molich. A heuristic evaluation is the method built on them: several evaluators inspect an interface independently, record every violation, rate its severity, then merge the findings. No users take part, which is both its speed and its limit. It opens most of our UX audits.
02Capabilities
The ten, grouped by the question each answers
The principles are abstract by design, which is why they get quoted more often than used. This is the version we work from: each one next to the failure we see most often in real products.
- Status
Can people tell what is happening?
Visibility of system status: a bulk import that shows nothing for ninety seconds, so people click it again and create duplicates. Help users recognize, diagnose and recover from errors: a bare error code, with no statement of what happened and no next step. Help and documentation: a sixty-page PDF nobody opens, and no guidance at the exact point where people get stuck.
- Control
Can people act without fear?
User control and freedom: a five-step wizard with no way back, or a destructive action with no undo. Error prevention: a free-text field where a picker belongs, or Delete beside the primary action, which matters most in healthcare and financial products. Flexibility and efficiency of use: no shortcuts, no bulk actions and no saved filters, in a tool dispatchers use for eight hours a day.
- Language
Does the product speak their language?
Match between the system and the real world: labels taken from database tables, so users read entity type where the business says shipment. Consistency and standards: Save here, Apply there, Submit on a third screen, all doing the same thing. Recognition rather than recall: carrying a reference number between screens from memory. Aesthetic and minimalist design: forty metrics on one dashboard with no hierarchy, so the number that decides something is invisible.
03Fit
Six situations, and whether inspection answers them
The method is cheap because it skips the users, and everything it gets wrong comes from that trade. Two rows are the cases it was built for. Three name the situation where a different instrument answers the question, and one moves the review into the design work already underway.
| Your situation | What we recommend |
|---|---|
| You know the product frustrates people and cannot say where | Run the reviewThe fastest route from a complaint to a located list of defects, and the front end of a UX audit. |
| Everyone agrees it is broken and nobody agrees on priority | Run the reviewSeverity ratings from an evaluator with no stake in the roadmap. This is the political value of the method, and it is real. |
| You need to know whether users understand your domain | Different methodUsability testing, with real people attempting real tasks. No expert inspection reveals a wrong mental model. |
| You need to know which of two designs performs better | Different methodInstrument it and measure. Two experts with heuristics will produce two confident opinions and no evidence. |
| You need accessibility conformance for a contract or an audit | Different standardAn audit against WCAG 2.2, which is the standard we build to. The principles overlap with it, and passing one says nothing about the other. |
| The redesign is already approved and the budget is committed | Review the new workRun the review against the new work while it is still cheap to change, inside product design, where the findings can still be acted on. |
Scope
What we own is the step the method leaves out. Forty violations is not a deliverable, so we rate severity, group the findings into the few causes behind them, and say what we would change and in what order. Where the fix is structural it becomes design system work. Our published UX audit of a school-meal catering app is what that deliverable looks like. unicrew has been doing this since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system. We build to WCAG 2.2 AA.
04Stack
What we reach for around it
The three tools that turn up on either side of a review, each with a page of its own.
05Questions
Questions about running one
Answered the way we would answer them live. If yours is not here, it is a good first message.
No, they answer different questions. A heuristic evaluation is experts inspecting an interface against known principles: fast, cheap, good at catching defects that break well-understood rules. Usability testing is real people attempting real tasks, and it is the only way to discover that your users hold a different model of the domain than your product assumes. Run the evaluation first, because it clears the noise that would otherwise consume your sessions.
More than one. Nielsen's own research put a single evaluator at roughly a third of the problems in an interface, with three to five finding most of them and the returns flattening after that. Different evaluators notice different things, so the merged list is much longer than any individual one. One person with a checklist beats nothing and is not a review.
Yes, because they describe human attention and memory rather than the widgets of any era. The newer surfaces break the same ones hardest. A model that streams for twenty seconds with no sign it is working fails visibility of system status exactly as a slow desktop dialog did, and a generated answer that is wrong with no way to see why or correct it fails error recovery.
Yes, against a prototype, and it is worth doing because these defects are far cheaper to fix before the code exists. The limit is that some violations only appear with real data, real latency and real error conditions, so a prototype review is a first pass rather than a substitute for reviewing the built product.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and only after the first read, because a fixed number on a product nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Know the product frustrates people, not sure where?
A structured review answers that in days rather than quarters. Send us the product and the complaint you keep hearing, and we will say what a UX audit would cover.