01 / UNDERSTAND
What is a heuristic evaluation?
A heuristic evaluation is an inspection of an interface against a defined set of usability principles. Reviewers identify potential problems, explain their likely consequences and document where they occur. Jakob Nielsen’s ten usability heuristics are a widely used reference.
The result is an expert assessment. It does not demonstrate what users actually do. Keep observed interface behaviour separate from predictions about user difficulty, then use research to investigate consequential uncertainties.
Why use Heuristic Evaluation?
An interface can look complete while leaving important states unexplained: whether a submission succeeded, why an action is unavailable or how to recover from an error. A structured inspection makes these questions harder to overlook.
The method is useful for finding issues to address before a study and for sharpening the questions in Usability Testing. It is not a substitute for that study, an accessibility audit or an assessment of whether people need the product.
When to use it
USE IT WHEN
You have an interface or prototype and want to identify likely usability problems.
The team needs a structured review before testing with participants.
A changed flow needs inspection across success, error and recovery states.
When to choose another method
Use User Interviews when the underlying goals and context are unclear.
Use Usability Testing to observe whether people can complete the task.
Arrange a dedicated accessibility evaluation when you need to assess conformance and assistive technology behaviour.
What you’ll need
Define the task, audience, device, version and states in scope. Choose and name the heuristic set before inspecting. Provide reviewers with the same brief and access, while keeping their initial findings independent.
Use test data and a safe environment. Include a way to reproduce error and empty states. Record any prototype limitations so a missing implementation is not mistaken for a finished design decision.
What an evaluation record needs
Keep the elements that help answer your question and support a decision.
The task, device, starting state and build examined.
The screen and actions needed to reproduce the issue.
What the interface actually displays or does.
The relevant principle and why the behaviour raises a concern.
What a person may misunderstand or be unable to complete.
The proposed response, uncertainty, owner and verification needed.
02 / PUT IT INTO PRACTICE
How to conduct a heuristic evaluation
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Agree the inspection brief
Choose a bounded task and the heuristic reference. Record what cannot be assessed.
Inspect changing a delivery address on a mobile checkout, including an unsuccessful save.
02
Explore the flow
Become familiar with its sequence before recording findings. Note available branches and recovery paths.
Find the edit action, change the address, save it and return to checkout.
03
Inspect independently
Reviewers examine the same scope separately, recording specific observations rather than general preferences.
After a failed save, the edited address remains visible with no message about its status.
04
Explain each concern
Connect the observation to a heuristic and a plausible consequence. Keep the evidence boundary explicit.
Under visibility of system status, the concern is that someone may assume the address was saved.
05
Consolidate and prioritise
Merge duplicate reports by underlying issue. Keep distinct causes separate and discuss uncertainty.
A missing status message and an unclear retry action may need related but separate changes.
06
Assign a response and verify
Specify a proposed improvement and the evidence needed to evaluate it. Retest the affected states.
Add explicit save feedback and a recovery route, then observe how participants interpret the result.
Example: an address change with no clear result
This is a fictional inspection example, not a finding from a live product. A shopper edits a delivery address during checkout. The save request fails, but the screen continues to show the new address without a warning or confirmation.
The record distinguishes the observation, ‘edited address remains visible after the failed request’, from the prediction, ‘the shopper may believe the change is confirmed’. The reviewer links the concern to visibility of system status and records the failed request as the reproduction condition.
The team treats this as a high priority investigation because an incorrect delivery address could have a meaningful consequence. It does not invent a failure rate. A proposed revision keeps the confirmed address identifiable, explains that saving failed and offers a retry. A task based study should examine whether people understand which address will be used.
03 / BELOW THE SURFACE
Below the surface: severity is not certainty
A potentially serious consequence can be supported by weak evidence about how often it occurs. Combining consequence and confidence into one score hides that distinction.
CONSEQUENCE
What could this prevent or put at risk?
Describe the affected task without inventing a frequency.
CONFIDENCE
Which part is observed and which is predicted?
Separate reproducible interface behaviour from interpretation.
NEXT CHECK
What evidence could change the priority?
Identify the smallest useful verification or user study.
For the address example, the interface behaviour is reproducible, but the prediction about a shopper’s interpretation still needs testing. Record these as different claims. The possibility of a misdirected parcel justifies attention; it does not justify saying that most shoppers will make that mistake.
A useful review discussion asks two separate questions: how consequential would the problem be, and how confident are we in the proposed explanation? A severe concern with low confidence may call for urgent investigation, not immediate implementation of the reviewer’s preferred fix.
Agreement between reviewers is not user evidence. They may share the same assumptions. Keep contrary interpretations and specify what would change the recommendation. These prompts are editorial guidance for using inspection results, not a validated severity scale.
Heuristic Evaluation working canvas
Use page one for one reproducible issue, with its heuristic, evidence and predicted consequence. Duplicate that page for additional issues. Use page two to separate severity from confidence and plan a response. This is an issue recording canvas, not a replacement for the full heuristic reference.
Practical tips
Record the version and reproduction steps with every issue.
Capture successful states as well as failures to understand the full interaction.
Explain why a heuristic matters in this context instead of attaching a label alone.
Common mistakes
Reporting personal taste as a usability problem.
Counting heuristic violations as a product quality score.
Treating a prototype limitation as an implemented behaviour.
Presenting predicted user behaviour as observed research.
What you’ll get
A prioritised set of reproducible concerns, explicit assumptions and next checks. Use Paper Prototyping to explore a revision and Usability Testing to investigate how people use it.