Heuristics & evaluation methods

Scope: every heuristicprinciplemethod below is reframed as a discrete, scorable criterion suitable for a JUDGE tier (AI scores a screenformiconlayout against the governing spec, 0–100). Measurability tags: [AUTO] = deterministically checkable from DOMmarkupstate machinetokens; [AI-JUDGE] = an AI evaluates the rendered screen + specevidence; [HUMAN] = needs a real userempirical session.

---

1. Nielsen's 10 Usability Heuristics (NN/G, 1994, unchanged)

Broad rules of thumb (not specific guidelines), distilled from factor analysis of 249 usability problems.

H1 — Visibility of System Status

• Meaning: The design always keeps users informed about what is going on through timely, appropriate feedback.
• Checkable criterion: Does every asyncstate-changing action expose a loading + empty + error + success state? Is current locationselectionprogress always visible (breadcrumbs, active nav, step indicator, spinnerskeleton within ~1s)?
• Tag: [AUTO] for presence of the 4 async states + active-nav markers; [AI-JUDGE] for "timely & appropriate."

H2 — Match Between System and the Real World

• Meaning: Speak the users' language; follow real-world conventions; natural/logical order.
• Checkable criterion: Are labelsmessages free of internal jargon, error codes, and DBfield names? Do icons + ordering follow real-world conventions (e.g., trash=delete)? Is the i18n string set human-readable (en-US floor)?
• Tag: [AI-JUDGE] (jargon/idiom detection against domain glossary); [AUTO] for raw error-code leakage regex.

H3 — User Control and Freedom

• Meaning: Provide a clearly marked "emergency exit"; support undo/redo.
• Checkable criterion: Does every destructiveirreversible action offer undo OR confirm? Is there a visible CancelClose/Back on every modal, multi-step flow, and form? Can the user exit an unwanted state without dead-ends?
• Tag: [AUTO] for undocancelclose affordance presence; [AI-JUDGE] for "clearly marked."

H4 — Consistency and Standards

• Meaning: Same wordssituationsactions mean the same thing; follow platform + industry conventions.
• Checkable criterion: Do components use shared design-token values (no off-palette colorsspacings)? Are identical actions labeled identically across screens? Platform conventions honored (Verge v2 tokens, topbarbadge placement, back-behavior)?
• Tag: [AUTO] (tokenlint conformance — strongest deterministic signal; ties to Vergespec audits); [AI-JUDGE] for cross-screen label/iconography consistency.

H5 — Error Prevention

• Meaning: Prevent problems before they occur (better than good error messages).
• Checkable criterion: Are error-prone inputs constrained (pickers over free-text, input masks, disabled-until-valid submit, sensible defaults)? Are slips/mistakes blocked by confirmation on high-cost actions?
• Tag: [AUTO] for constraint/validation presence; [AI-JUDGE] for adequacy.

H6 — Recognition Rather Than Recall

• Meaning: Make elementsactionsoptions visible; minimize memory load.
• Checkable criterion: Are required options visibleselectable rather than memorized across steps? Is context (entered data, prior selections) carried forward and shown? Are helphints in-context, not in a separate manual?
• Tag: [AI-JUDGE]; [AUTO] for placeholder/inline-help presence.

H7 — Flexibility and Efficiency of Use

• Meaning: Accelerators (hidden from novices) speed expert use; allow tailoring of frequent actions.
• Checkable criterion: Are there keyboard shortcuts, bulk actions, recents/favorites, or macros for power users without harming the novice path?
• Tag: [AUTO] for shortcut/accelerator presence; [AI-JUDGE] for appropriateness.

H8 — Aesthetic and Minimalist Design

• Meaning: No irrelevant/rarely-needed information; every extra unit competes with the relevant.
• Checkable criterion: Is each screen focused on one primary task with a clear visual hierarchy? Information density within budget (no competing CTAs, no redundant copy)?
• Tag: [AI-JUDGE] (signal-to-noise, hierarchy); [AUTO] for primary-CTA count.

H9 — Help Users Recognize, Diagnose, and Recover from Errors

• Meaning: Plain-language errors, no codes, precisely state the problem, suggest a solution.
• Checkable criterion: Does every error message (a) avoid raw codes, (b) name what went wrong, and (c) offer a constructive next steprecovery action? (Maps to `specserrors/user-facing-messages.kmd`.)
• Tag: [AUTO] for code-leak + "no recovery action" detection; [AI-JUDGE] for plain-language quality.

H10 — Help and Documentation

• Meaning: Ideally none needed; if needed, it's findable, task-focused, concise.
• Checkable criterion: Is contextual help reachable from the screen? Is it scoped to the user's concrete task with actionable steps (not generic)?
• Tag: [AI-JUDGE]; [AUTO] for help-affordance presence.

Severity / weighting (Nielsen's 0–4 scale) — applied per finding, then used to weight rubric deductions:

Severity = frequency × impact × persistence (common-vs-rare × hard-vs-easy-to-overcome × one-time-vs-repeated), combined into one rating. For scoring, deduct points proportional to max severity per heuristic; any severity-4 should cap the section score (release gate).

---

2. Shneiderman's 8 Golden Rules of Interface Design (1985)

GR1 — Strive for Consistency

• Criterion: Identical sequencesterminologylayout for analogous situations; standard coloriconmenu usage. [AUTO] (token + label audit).

GR2 — Enable Frequent Users to Use Shortcuts (Cater to Universal Usability)

• Criterion: Accelerators, abbreviations, macros present as interaction scales. [AUTO]/[AI-JUDGE].

GR3 — Offer Informative Feedback

• Criterion: Every action yields system feedback (modest for frequent/minor, substantial for major). Overlaps H1. [AUTO] state presence; [AI-JUDGE] proportionality.

GR4 — Design Dialogs to Yield Closure

• Criterion: Action sequences have beginning/middle