A complete heuristic evaluation, run on the worst app we could imagine

A heuristic evaluation checks an interface against ten research-backed usability principles, scores each violation by severity, and outputs a ranked list of fixes. Most explanations stop at the definitions. This one runs the whole method, end to end, on an app that deserves it.

Meet Driftly, a project tracker for busy teams. Driftly is fictional. Every one of its problems is not: each screen below reproduces a failure pattern that ships in real SaaS products every day. Inventing the app lets us roast at full temperature without dragging a real team, which is also ClapBack policy: punch at products, never at people.

How a heuristic evaluation works

An evaluator walks through the product screen by screen, comparing what they see against the 10 usability heuristics Jakob Nielsen published in 1994. Every mismatch becomes a finding: which heuristic it violates, where, how bad, and what to do about it. No users are recruited. That is the method’s superpower (it takes hours, not weeks) and its known limit: Nielsen’s research found single evaluators catch only about 35% of usability problems on average, which is why evaluations use multiple evaluators, or multiple passes.

For severity, NN/g rates problems on a 0 to 4 scale combining frequency, impact, and persistence. We collapse that into the three tiers a ticket queue understands: Blocker (severity 4: users fail or lose work), Major (severity 3: users struggle, some give up), and Minor (severity 1 to 2: friction and irritation). Ratings 3 and 4 are where NN/g says your fix budget should go.

Now the fun part. Ten heuristics, ten Driftly screens, ten findings.

#1 · Visibility of system status

The system should always tell users what is going on, through timely feedback. Driftly’s data import has been running for four minutes. The progress bar is a gray rectangle. It is not loading. It is just gray.

#2 · Match between system and the real world

Speak the user’s language, not yours. Driftly greets new users with an empty state that asks them to “instantiate a workstream artifact.” The button that creates a project does not contain the word project.

#3 · User control and freedom

Users need an emergency exit: undo, redo, cancel. Driftly’s archive action fires instantly, permanently, and from a button one row away from “Rename.” The toast proudly announces the board is gone forever.

#4 · Consistency and standards

Same action, same words, same place. Driftly’s three settings tabs commit changes with three different verbs (“Save”, “Apply changes”, “Commit”) in three different colors, one of which is the same red the app uses for destructive actions.

#5 · Error prevention

The best error message is the one you made impossible. Driftly’s sprint form happily accepts an end date two weeks before the start date, waits for submit, then rejects the whole form with “Submission failed. Please review your input.” Review what? It does not say.

#6 · Recognition rather than recall

Minimize memory load: options should be visible, not memorized. Driftly’s board toolbar is seven unlabeled glyphs. No text, no tooltips. One of them archives things (see finding #3 for how that goes).

#7 · Flexibility and efficiency of use

Experts should have accelerators. Driftly has 41 completed tasks to archive and exactly one way to do it: 41 individual clicks, each with its own page reload. No multi-select, no “archive all done,” no keyboard path.

#8 · Aesthetic and minimalist design

Every extra element competes with the ones that matter. Driftly’s dashboard loads with four stacked banners (a conference ad, an upsell, a beta announcement, and a plea for G2 reviews) before any actual work is visible.

#9 · Help users recognize, diagnose, and recover from errors

Error messages should say what happened, in plain language, and how to recover. Driftly’s save failure produces “ERR_SAVE_FAILED 0x80040154 (REGDB_E_CLASSNOTREG)” and a single button: OK. It is not OK. The user’s edits are gone.

#10 · Help and documentation

Ideally the product needs no manual; when it does, help should be searchable and contextual. Driftly’s Help page contains one artifact: a 214-page PDF, last updated 14 months ago, with “FINAL(2)” in the filename.

The Driftly report card

Ten findings: 2 Blockers, 5 Majors, 3 Minors, and 7 of the 10 fixes are roughly an hour of work. That distribution is the punchline of most real audits too: the scary part is rarely the effort, it is that nobody had receipts before.

How to run this on your own product

You just watched the whole method. To repeat it on your app: pick your three money flows (signup, onboarding, the core loop), walk each one against the 10 heuristics above, and write every violation down with a severity and a fix before you touch any code. Two practical notes from the field:

• Fresh eyes matter more than expertise. You have gone blind to your own product’s rough edges; anyone who has never seen it will find things you cannot. Nielsen’s multi-evaluator data exists precisely because single familiar evaluators miss most problems.
• A violation that never becomes a ticket never gets fixed. Write each one with severity, evidence, and effort so it can go straight into the sprint. We wrote up the exact format in how to turn UX findings into tickets devs actually fix.

If you want the checklist version of this method, scoped to what a founder can do in an afternoon, that is the founder’s UX audit checklist. And if you would rather an agent run the walk-through for you, that is the entire reason ClapBack exists.