# Heuristic Evaluation And Design Critique

> Use when an existing interface or flow needs an expert, no-users inspection against Nielsen/Tognazzini heuristics with screen evidence and 0–4 severity. Do not use for empirical usability testing or a broad 0–100 visual audit; route those to research or design-audit.

- Skill: `peterbamuhigire/heuristic-evaluation-and-design-critique` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add peterbamuhigire/heuristic-evaluation-and-design-critique`
- Raw SKILL.md: https://api.skillmd.com/api/skills/peterbamuhigire/heuristic-evaluation-and-design-critique/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: peterbamuhigire (https://skillmd.com/u/peterbamuhigire)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/peterbamuhigire/heuristic-evaluation-and-design-critique

---


# Heuristic Evaluation & Design Critique

Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.

<!-- dual-compat-start -->
## Use When

- You need an **expert usability inspection** of a built or prototyped UI **without recruiting
  users** — the "discount usability" method: 3–5 evaluators independently walk the interface
  against a shared set of heuristics, then merge findings.
- You want a **structured design critique** that is defensible — every comment tied to a named
  heuristic and a severity rating, not to taste or "I'd have done it differently."
- You have screens, a flow, a Figma file, or a live URL and want a **prioritised list of
  usability violations** with locations, evidence, and 0–4 severities to feed a fix backlog.
- You are reviewing early, before usability testing, to **cheaply remove the obvious violations**
  so user tests spend their budget on the subtle, behaviour-only problems.

## Do Not Use When

- You need a **scored 0–100 quality rubric** across visual hierarchy, slop, performance,
  typography, etc. → use `design-audit` (the scored artifact audit; this skill is the
  heuristic-walkthrough method, not a numeric grade).
- You need a **ship go/no-go gate** with spec/pixel parity → use `design-qa-and-pre-launch-review`.
- You need to **observe real users** completing tasks → use
  `ux-research-and-usability-testing` (inspection finds *suspected* problems; testing finds
  *actual* ones — they are complementary, not substitutes).
- You have an audit's findings and need to **redesign, re-validate, and measure the uplift** →
  use `ux-remediation-and-redesign` (the fix side).

## Required Inputs

| Input | Source | Evidence |
|---|---|---|
| Stable interface/flow and task scope | Product owner or test build | Versioned screens, routes, and critical tasks |
| Target users and context | Research or approved assumptions | Experience, device, environment, and constraints |
| Known business/platform rules | Product and engineering | Constraints that distinguish defect from intended behaviour |

- **The artifact** — screens, screenshots, a prototype, a flow, or a URL, ideally covering the
  product's red-route tasks (sign-up, core task, checkout) end to end.
- **Context** — who the users are, their tech literacy, the platform (web / iOS / Android /
  desktop), the design system if any, and the brand personality. Heuristics are interpreted
  *against* the user's mental model, so this is not optional.
- **Evaluator count** — ideally 3–5 independent evaluators (Nielsen: ~5 evaluators surface
  ~75% of usability problems; one finds only ~35%). A single evaluator pass is still valuable
  but state the coverage limitation in the report.

## Workflow

The evaluation is a **structured walkthrough**, not a free-form opinion. Run it in seven steps.

1. **Frame the evaluation.** State the user, task, platform, and brand context. List the
   **red-route tasks** to be walked (the critical paths). Confirm the heuristic set:
   Nielsen's 10 + Tognazzini's first principles (`references/heuristics-catalog.md`).
2. **Two-pass walkthrough (Nielsen's recommendation).** Walk each screen/flow **twice**: pass
   one to get a feel for the flow and scope; pass two to inspect each element slowly against
   every heuristic. Walk the red routes as tasks, not just static screens — a violation often
   only appears mid-flow (a missing "you are here", a silent save, a dead end).
3. **Detect against the heuristic catalogue.** For each screen/element, check it against all of
   Nielsen's 10 and the relevant Tognazzini principles. Cross-walk the behavioural
   anti-patterns in `doctrine/references/interaction-anti-patterns.md` (A1–E3) — any match is a
   heuristic violation (e.g. an interrupting "Done" modal = C1 Idiot Box = breaks Nielsen #8
   *Aesthetic & minimalist design* and Tognazzini *Efficiency of the user*).
4. **Capture evidence for every finding.** A finding is not a finding without: **(a) location**
   (screen + element), **(b) the heuristic violated** (by name/number), **(c) what is wrong**
   (observed, specific), **(d) evidence** (the screenshot, the measured value, the
   reproduction step — never "feels off"). See "Evidence capture" below.
5. **Rate severity 0–4** independently per finding using the three factors — **frequency ×
   impact × persistence** — per `references/severity-scoring.md`. In a multi-evaluator
   evaluation, evaluators rate **independently first**, then the facilitator merges and the
   panel re-rates the merged list (independent-then-aggregate removes single-rater bias).
6. **Merge & deduplicate.** Combine evaluators' lists; collapse duplicates (keep the clearest
   wording); note how many evaluators independently caught each issue (multi-catch issues are
   higher-confidence). Order by **severity descending**, then by red-route position.
7. **Write the critique report.** Use the report structure (Section 2): per-finding cards +
   a severity-ordered table + positive findings (what works — always name strengths, a critique
   that only lists faults is not credible). Tie each finding to its fix / right-pattern.

## Decision Rules

| Condition | Choice | Wrong-choice failure |
|---|---|---|
| Issue blocks task or risks severe loss | Severity 4 with immediate escalation | Averaging it into a score hides urgent harm |
| Issue is repeated but recoverable | One systemic finding plus instances | Duplicate findings inflate volume and fragment remediation |
| Observation depends on user behaviour | Convert to research hypothesis | Expert opinion is misrepresented as user evidence |

## Capability Contract

- Must inspect the actual interface and capture reproducible screen/step evidence; evaluation is read-only by default.
- May annotate findings, but may not edit the product, contact users, or claim empirical validation unless separately authorised.

## Degraded Mode

- If the interface or critical tasks are inaccessible, stop scoring and return the missing evidence request.
- With screenshots only, limit findings to observable states and mark interaction claims unverified. Recover disputed findings by reproducing the path, clarifying the violated principle, or downgrading to a testable hypothesis.

## Quality Standards

- Every finding has location, evidence, violated heuristic, user consequence, severity rationale, and actionable correction.
- The report separates observations, inference, and assumptions and avoids certification claims.

## Anti-Patterns

- **Opinion dressed as evaluation.** "I'd use a different colour" with no heuristic and no
  severity is a preference, not a finding. Every comment cites a heuristic.
- **No severity, or severity by gut.** Skipping the 0–4 scale, or rating on annoyance rather than
  frequency × impact × persistence, makes the list un-prioritisable. Use the rubric.
- **Single static screen.** Inspecting only the hero screen and not walking the red-route *flow*
  misses the feedback, recovery, and "where am I" violations that only appear in motion.
- **Critique with no strengths.** A report that only attacks reads as adversarial and loses the
  room; name what works and why (it also tells the team what *not* to break).
- **Confusing inspection with testing.** Heuristic evaluation predicts *suspected* problems from
  expert judgement; it does **not** replace observing real users. Say so in the report.
- **Cosmetic = trivial reflex.** Frequency and persistence can push a "cosmetic" issue up the
  scale; do not auto-floor visual issues to severity 1.

## Outputs

| Output | Consumer | Evidence and acceptance |
|---|---|---|
| Heuristic findings register | Product and design | Reproducible evidence, heuristic, severity, consequence, and fix per issue |
| Prioritised critique summary | Decision owner | Systemic themes, top risks, quick wins, and research hypotheses are separated |

- A **heuristic evaluation / design critique report**: framing, the heuristic set used, per-finding
  cards (location · heuristic · issue · evidence · severity · fix), a **severity-ordered findings
  table**, positive findings, and an evaluator-coverage note.
- A **prioritised violation list** (severity 4 → 0) ready to hand to `ux-remediation-and-redesign`
  as a fix backlog, or to feed `design-audit`'s triage queue.

## Examples

- `examples/heuristic-evaluation-worked.md` — a full worked heuristic evaluation of a real
  screen-and-flow (a mobile bank transfer flow), with findings tied to specific Nielsen/Tognazzini
  heuristics, evidence, and 0–4 severities, ordered into a fix backlog.

## References

- `references/heuristics-catalog.md` — the heuristic set: **Nielsen's 10 usability heuristics**
  (full definitions + what each looks like when violated) and **Tognazzini's first principles of
  interaction design** (Anticipation, Autonomy, Consistency, Defaults, Efficiency, Fitts's Law,
  Latency reduction, Learnability, Protect the user's work, Visible navigation, and the rest).
- `references/severity-scoring.md` — the **0–4 severity scale** (0 = not a problem … 4 =
  usability catastrophe) and the **frequency × impact × persistence** rating method, with the
  independent-then-aggregate multi-evaluator protocol and gate floors.
- `doctrine/design-doctrine.md` — the Anti-Slop Charter and the Mission ("the moat is looking
  human-made"); a heuristic critique also flags convergent/slop choices as findings.
- `doctrine/references/interaction-anti-patterns.md` — the behavioural detection checklist
  (A1–E3: navigation, forms, feedback/control, hierarchy/legibility, novelty/platform-fit). Walk
  the UI against it; each match maps to a violated heuristic and is severity-rated here.
- `doctrine/references/wcag-2.2-criteria.md` — accessibility violations are heuristic violations
  (#5 *Error prevention*, #7 *Flexibility*) and are rated on the same scale; certify with WCAG.
<!-- dual-compat-end -->

## Plugins (Load Alongside)

| Companion Skill | When to Load |
|---|---|
| `design-audit` | The **paired** scored artifact audit (0–100 rubric, slop/WCAG/CWV gates). Run heuristic evaluation as the inspection method; run design-audit when a defensible *number* is needed. They share the same anti-pattern checklist. |
| `ux-research-and-usability-testing` | When the suspected problems this inspection surfaces need confirming with **real users** (inspection predicts; testing proves). |
| `ux-remediation-and-redesign` | **Downstream** — hand the severity-ordered violation list over to redesign, re-validate, and measure the uplift. |
| `ux-psychology` | When a finding's *why* is cognitive (Hick's/Miller's/Fitts's load, recognition-over-recall) and the critique should explain the mechanism, not just the symptom. |

---

## 1. The method in one paragraph

Heuristic evaluation is a **discount usability inspection**: a small set of evaluators judge an
interface against recognised usability principles (Nielsen's 10 + Tognazzini's first principles),
independently, then merge. It is fast and cheap, finds the *obvious* violations a user test would
waste money rediscovering, and is **not** a substitute for testing real users — it predicts
*suspected* problems. Its discipline is what makes it more than opinion: **named heuristic +
located evidence + a 0–4 severity per finding.** This skill is the inspection/critique half of the
evaluation pair; `design-audit` is the scored-rubric half. (Provenance: Jakob Nielsen & Rolf
Molich's heuristic-evaluation method and Nielsen's 10 heuristics, 1994/refined; Bruce Tognazzini's
*First Principles of Interaction Design*, revised — both updated here to WCAG 2.2 and the Chwezi
doctrine.)

## 2. Report structure

```
# Heuristic Evaluation / Design Critique
**Date:** [date]   **Evaluator(s):** [n evaluators — names/roles]
**Target:** [screen / flow / product]   **Platform:** [web / iOS / Android / desktop]
**Context:** [users, tech literacy, brand personality]
**Heuristic set:** Nielsen 10 + Tognazzini first principles (+ interaction-anti-patterns A1–E3)
**Red routes walked:** [the critical-path tasks inspected]
```

### Findings (per-finding card)

```
### F[n] — [short title]
- **Location:** [screen + element]
- **Heuristic violated:** [Nielsen #N name] / [Tognazzini principle] (+ anti-pattern code if any)
- **Issue:** [specific, observed — what is wrong]
- **Evidence:** [screenshot ref / measured value / reproduction step]
- **Severity:** [0–4] — [frequency × impact × persistence, one line]
- **Caught by:** [k of n evaluators]   (multi-catch ⇒ higher confidence)
- **Fix / right pattern:** [the target heuristic-satisfying state]
```

### Severity-ordered table

| # | Title | Heuristic | Location | Severity | Caught by |
|---|---|---|---|---|---|
| F1 | … | #1 Visibility of status | … | 4 | 4/5 |

### What works (positive findings)

Name the decisions that *satisfy* the heuristics and should be preserved — strengths to protect,
not just faults to fix.

### Coverage note

State evaluator count and the inspection-not-testing caveat: "These are expert-predicted suspected
problems; confirm the borderline ones with `ux-research-and-usability-testing`."

---

## 3. How this differs from `design-audit` (the pair)

| | **Heuristic evaluation (this skill)** | **`design-audit`** |
|---|---|---|
| **Method** | Expert walkthrough against principles | Scored scan across 10 dimensions |
| **Output** | Findings, each tied to a heuristic + 0–4 severity | A defensible **0–100 number** + gates |
| **Question** | *Which usability principles does it violate?* | *How good is it, on a scale, and does it pass the gates?* |
| **Evaluators** | 3–5 independent, then merged | One scored pass against the rubric |
| **Best for** | Cheap pre-test removal of obvious violations; structured critique | A comparable score, slop/WCAG/CWV gating, exec reporting |

They are **complementary**: run the heuristic evaluation to find and name violations; run
`design-audit` when the work needs a graded score and the three hard gates. Both walk the same
`interaction-anti-patterns.md` checklist, so a finding from one feeds the other.

---

*Sources: Nielsen & Molich heuristic evaluation; Nielsen's 10 Usability Heuristics; Tognazzini,
First Principles of Interaction Design — all aligned to WCAG 2.2 AA and `doctrine/design-doctrine.md`
(the Anti-Slop Charter). Companion to the scored `design-audit`.*