Heuristic Design Critique

Heuristic design critique applies Jakob Nielsen's 10 usability heuristics to wireframes or early layouts and produces a ranked list of issues. An LLM inspects the provided screens (or structured screen descriptions), maps findings to specific heuristics, and orders those findings by estimated severity and user impact. The output is a critique checklist, not a redesign.

This page is for UX designers who already run heuristic reviews and want a consistent first pass before peer critique or moderated testing. The model accelerates coverage across many screens and states. The designer still decides which issues are real, which are false positives, and which changes ship.

Related reading: Accessibility Auto-Audit for WCAG-oriented checks on the same artifacts, Usability Feedback Synthesizer for clustering later study notes, and API Contract Generator when interaction flows need stable request and response shapes before build.

The review only runs when wireframes are present. Acceptable inputs include linked Figma frames, exported screen images with labels, or a structured inventory that lists each screen, primary user goal, key controls, and empty or error states. Without at least one inspectable wireframe (or an equivalent screen-level description the model can score), the process must return empty output: no invented issues, no placeholder rankings, and no generic heuristic essay.

Useful context improves ranking quality but does not replace wireframes:

• Product surface (web app, mobile, admin console)
• Primary user and job to be done for the flow under review
• Constraints already decided (platform patterns, brand, legal copy)
• Known risky states (permissions, empty data, long latency, destructive actions)

If screens are partial, scope the run to what exists. Partial coverage is fine; fabricating missing screens is not.

The model walks each provided screen against Nielsen's heuristics, including visibility of system status, match between system and the real world, user control and freedom, consistency and standards, error prevention, recognition rather than recall, flexibility and efficiency of use, aesthetic and minimalist design, help users recognize and recover from errors, and help and documentation. Each finding should name the heuristic, the screen or component, and a short rationale grounded in what is visible.

Ranking should prefer user impact and likelihood over neatness of the write-up. A missing confirmation on a destructive action usually outranks a mild label inconsistency. Duplicate findings across screens should collapse into one issue with affected screens listed, so the designer is not drowning in repeats.

A practical ranked item looks like:

1. Heuristic and severity (for example: Error prevention, high)
2. Where it appears (screen name and control)
3. Why it fails the heuristic in this layout
4. Optional: a concrete check the designer can verify in the file

Severity labels are suggestions for triage order. They are not product requirements. Designers should re-rank when domain risk, legal exposure, or research evidence disagrees with the model.

The LLM ranks issues. Design still decides. Treat the ranked list as a structured draft critique: accept, edit, merge, demote, or discard each item before it enters a critique doc, ticket, or design review agenda.

A short review loop that fits most teams:

1. Confirm every issue points at a real screen element in the current wireframes.
2. Drop findings that ignore platform conventions already chosen for the product.
3. Promote issues that affect task completion, data integrity, or irreversible actions.
4. Demote style preferences that are not heuristic failures.
5. Hand the cleaned list into peer critique or a test plan, not straight into engineering tickets without design ownership.

Human review also catches heuristic misfires. Models sometimes over-weight visual minimalism, under-weight domain jargon that experts need, or flag intentional progressive disclosure as "recognition rather than recall" failures. Those calls need a designer who knows the audience.

Run heuristic design critique when wireframes are stable enough to critique but still cheap to change: early mid-fidelity flows, redesigns of high-traffic paths, or pre-handoff passes before a formal review. It is especially useful when one designer owns many screens and wants a consistent checklist before inviting others.

Skip or delay the run when there are no wireframes yet, when only mood boards or brand explorations exist, or when the question is purely visual polish without interaction structure. Also skip when the team already has fresh usability evidence that contradicts a generic heuristic pass; evidence from users should lead, and the model should not overwrite it.

Empty-output rule, restated: missing wireframes means empty output. Do not fill the gap with textbook summaries of the ten heuristics. Those belong in training material, not in a project critique.

Heuristic critique is a design-quality aid in the software design stage. It does not replace moderated usability testing, accessibility conformance work, or engineering validation. Severity ranks are estimates. They can drift when screenshots omit hover states, keyboard paths, or responsive breakpoints.

Pair this use case with Accessibility Auto-Audit when the same frames need contrast, focus order, and name/role/value checks. Pair with Usability Feedback Synthesizer after studies, when interview notes need themes rather than heuristic labels. Use API Contract Generator when critique reveals missing states that must be represented in API payloads before implementation.

Keep ownership clear: the model proposes and ranks; the UX designer edits the list, chooses fixes, and records what was deferred. That separation keeps critique fast without turning model output into silent design authority.