Do a Heuristic Review Before You Test
Some problems are obvious enough to catch without users. A structured expert walkthrough clears them away, so your test sessions can focus on the problems you could not predict.
What a heuristic evaluation is
A heuristic evaluation is a usability inspection method in which evaluators examine an interface and judge it against recognised usability principles, the "heuristics". It is cheap and fast, but it reflects the reviewers' judgement, so it complements testing with users rather than replacing it.
Principles worth checking
Different lists exist, and most overlap. In practice, these questions cover a lot of ground:
- Can people tell what is happening? After a click, does something visibly respond? Are loading states and errors shown?
- Does it speak the visitor's language? Internal jargon in menus is one of the most common problems.
- Can people undo? A clear way back or a cancel button lowers anxiety.
- Is it consistent? The same action should look and behave the same everywhere.
- Does it prevent errors? Good forms stop mistakes before submission, not after.
- Is help findable? Not everyone reads it, but the people who need it should not have to hunt.
How to run one
- Pick two or three key journeys, such as signing up, finding a price and contacting support.
- Ask two or more people to review separately; each reviewer finds different things.
- Each reviewer notes the problem, where it is and which principle it breaks.
- Merge the lists and rate each problem by how often visitors would hit it and how badly it would stop them.
Watch for dark patterns
While reviewing, note anything that pushes people against their own interest. A dark pattern is a user interface designed to trick or manipulate users into choices they would not otherwise make, such as a pre-ticked box that signs people up for extras, or a cancel link hidden in small grey text. These often look like conversion wins in the short term and show up later as complaints and lost trust.
Report findings so they get fixed
A review is only as useful as the changes it causes. Group findings by journey rather than by principle, because the people fixing them think in screens and flows. Put the most severe problems first, include a screenshot for each, and suggest a direction rather than a finished design. Leave the final solution to the people who will build it; they often know constraints the reviewer does not.
Know the limits
Reviewers are not your visitors. They know where things usually are, and they may miss problems caused by unfamiliar vocabulary or different goals. Treat the review as a way to clean up obvious issues, then test with real people to find the rest.
Write each finding as "where, what, why it matters". A list that just says "navigation is confusing" cannot be fixed.
By Iris Calloway · last checked 2026-11-09