Impeccable

Purpose

Resolve one stable target, run two independent assessments, synthesize a design critique, persist a snapshot, and ask the user what to improve next. The chat response is the primary deliverable; the snapshot is an archive of that run.

Hard Invariants

• Assessment A (design review) and Assessment B (detector/browser evidence) are both required, except on a native platform (see Assessment Orchestration).

• Assessment A and B MUST run as two isolated sub-agents whenever a sub-agent/Task tool is exposed. Running them inline in this context is "possible" but is NOT permitted; it is a degraded run. Inline is allowed ONLY when no sub-agent tool exists (or the user declined, on harnesses that ask). Native platforms run A alone (see Assessment Orchestration).

• If you degrade for any reason, the report's first line MUST be a banner: ⚠️ DEGRADED: single-context (<reason>). A silent degraded critique is a failed critique.

• Assessment A must finish before detector findings enter the parent synthesis context. Detector output is deterministic, but it still anchors judgment.

• A skipped detector is a failed critique run unless impeccable detect is missing or crashes after a real attempt, or the platform is native (see Assessment Orchestration).

• Viewable targets require browser inspection when available.

• Any local server started only for critique visualization must run in the background, have a recorded stop method, and be stopped before final reporting unless the user asks to keep it.

• Do not claim a user-visible overlay exists unless script injection succeeded and the detector ran in the page.

• The question is the LAST thing in the response. Write the entire report out first, then ask; nothing follows the question. Prose emitted after a structured question is withheld until the user answers it, so a report written after the question reads as if the critique never ran.

• A run that ends with neither the targeted questions nor a literal Questions skipped: <reason> line is an incomplete run. The report is not the finish; the close is.

Setup

1. Resolve the target to a concrete file path or URL. Prefer a source path over a dev-server URL when both identify the same surface; ports drift, paths do not.

   • "the homepage" -> site/pages/index.astro or index.html

   • "the settings modal" -> the primary component file

   • "this page" -> the current URL or source file

2. Confirm the target slugs cleanly:

   Copy

   "<skill-base-dir>/scripts/impeccable" critique-storage slug "<resolved-path-or-url>"

   Every later command also accepts the resolved target directly and derives the same slug internally; never hand-write a slug. If this exits non-zero, skip persistence and trend for this run, but continue the critique.

3. Read .impeccable/critique/ignore.md if it exists. Drop matching findings silently; it is the only prior-run input critique consumes.

Assessment Orchestration

Native platforms (ios / android / adaptive): Assessment B does not apply, because impeccable detect and the browser overlay read only web markup. Run Assessment A alone in this context and skip both sub-agent gates below, the Codex permission question included: with no B there is nothing to isolate A from, so this is the complete native method and carries no degraded banner. Do not run impeccable detect on native source; its empty result reads as clean.

Delegate Assessment A and Assessment B to separate sub-agents. They must not see each other's output. Do not show findings to the user until synthesis.

Sub-agent gate (all harnesses):

• Unless a harness-specific gate below overrides this, spawn A and B as two isolated, parallel sub-agents whenever a sub-agent/Task tool is exposed. This is the default and is mandatory; do not run them inline because it is faster.

• Desktop apps (see Desktop apps under Assessment B) are the one exception to parallel: both sub-agents would drive the app's single window at once. Seed the window, spawn A, wait until it has finished and put the window back, then spawn B. They are still two isolated sub-agents, so this is not the degraded path.

• "Unavailable" means exactly one thing: no sub-agent/Task tool is exposed in this session (or, on harnesses that ask, the user declined). It does not mean inconvenient.

• If and only if sub-agents are unavailable, fall back sequentially: finish and record Assessment A, then run Assessment B, then synthesize, and emit the degraded banner.

• Whichever path you take, declare it in the report header (see Report header provenance). Skipping sub-agents without the banner is the most common failure of this command.

If browser automation is available, each assessment creates its own new tab. Never reuse an existing tab, even if it is already at the right URL. Desktop apps are the exception (see Desktop apps under Assessment B).

Assessment A: Design Review

Read relevant source files and visually inspect the live page when browser automation is available. Think like a design director.

Evaluate:

• Design specificity: Is the composition, interaction, and visual language grounded in this product, or could an unrelated product use it unchanged? Make this judgment before seeing detector output.

• Holistic design: hierarchy, IA, emotional fit, discoverability, composition, typography, color, accessibility, states, copy, and edge cases.

• Cognitive load: consult the Cognitive Load Assessment section below; report checklist failures and decision points with >4 visible options.

• Emotional journey: peak-end rule, emotional valleys, reassurance at high-stakes moments.

• Nielsen heuristics: consult the Heuristics Scoring Guide section below; score all 10 heuristics 0-4, marking any heuristic the mode-applicability rule allows as n/a instead of forcing a number.

Return: design-specificity verdict, heuristic scores, cognitive load, emotional journey, 2-3 strengths, 3-5 priority issues, persona red flags, minor observations, and provocative questions.

Assessment B: Detector + Browser Evidence

Run the bundled detector and browser visualization evidence. On web, Assessment B is mandatory and must remain isolated from Assessment A until both are complete.

CLI scan:

"<skill-base-dir>/scripts/impeccable" detect --json [target]

• Pass markup files/directories as [target]; do not pass CSS-only files.

• For URLs, skip CLI scan and use browser visualization.

• For very large trees (500+ scannable files), narrow scope or ask.

• Exit code 0 = clean; 2 = findings.

• If the detector entrypoint is missing or fails to load, report deterministic scan unavailable and continue with browser/manual review.

Browser visualization is required for a viewable target when browser automation is available. Use a localhost dev/static URL for local files; avoid file:// unless the available browser explicitly supports this workflow. Overlay flow:

1. Create a fresh tab and navigate. Prefer the harness's native/browser-canvas screenshot path before hand-rolling a Playwright/Puppeteer script; only fall back to a custom script when no native browser tool is exposed.

2. Preflight mutable injection by setting document.title and appending a <script> tag. Read-only evaluate APIs do not count.

3. If mutation is unavailable, skip live server, browser presentation, and injection; report fallback signal.

4. If mutation is available, start "<skill-base-dir>/scripts/impeccable" live-server --background, present the browser if supported, label [Human], scroll top, inject http://localhost:PORT/detect.js, wait 2-3 seconds, read impeccable console messages, then run "<skill-base-dir>/scripts/impeccable" live-server stop --keep-inject. The overlay went in through the browser, so the project's HTML has no script tag to strip; a bare stop also runs live-inject --remove against the project's entry file, an edit a read-only critique should not make.

5. For multi-view targets, inject on 3-5 representative pages.

Desktop apps (Electron, NW.js, CEF, WebView2): there is no URL to open, so Assessment B attaches to the running app instead.

1. Launch the app with a local DevTools port: --remote-debugging-port=9222 (Electron, NW.js, CEF), or WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=9222 for WebView2. Keep the port on 127.0.0.1 and never expose it beyond this machine; prefer a test profile and test data.

2. Seed the state under review (route, open panel, theme, data). The scan reads the window as it stands. Keep the window on screen: a minimized or hidden window scans without the pixel contrast reads.

3. Run "<skill-base-dir>/scripts/impeccable" detect --cdp 9222 --target <part of the page URL or title> --json. It returns the same JSON as a URL scan and leaves the page as found. With several pages open it fails and lists them; rerun with a --target that names one.

4. Take screenshots through the harness's CDP tooling (Page.captureScreenshot on the same target). Skip the live-server overlay: there is no [Human] tab.

The app has one window, so the assessments take turns in it instead of opening tabs (A, then B; see the sub-agent gate), and each must leave it as found: put back any route, scroll, theme, or panel it changed. Tauri on macOS (WKWebView) and on Linux (WebKitGTK) expose no CDP: run Assessment A and the source scan only, and say so in Run Notes.

Return: CLI findings JSON/counts, browser console findings if applicable, false positives, and skipped/failed browser steps with concrete reasons.

After Assessment B returns usable CLI findings, reuse them. Do not rerun impeccable detect in the parent unless Assessment B failed, was truncated, or omitted count, rule names, or file locations.

Generate Combined Critique Report

Synthesize both assessments into a single report. Do not simply concatenate. Weave the findings together, noting where the LLM review and detector agree, where the detector caught issues the LLM missed, and where detector findings are false positives.

The chat response is the primary user-facing deliverable. Present the full structured critique below in chat; do not replace it with a summary and a link. The persisted snapshot is an archive of that run.

Structure your feedback as a design director would:

Report header provenance

The report's first line MUST declare how the assessments were run, so a degraded run is never silent:

• Dual-agent: Method: dual-agent (A: <agent-id> · B: <agent-id>)

• Degraded: ⚠️ DEGRADED: single-context (<reason, e.g. no sub-agent tool exposed>)

• Native: Method: design review only (detector not applicable, native platform)

Design Health Score

Consult the Heuristics Scoring Guide section below.

Present the Nielsen's 10 heuristics scores as a table:

The applicable maximum is 4 times the number of heuristics you actually scored: /40 when all ten apply, /32 when two are n/a. Never print /40 over a partial set.

Be honest with scores. A 4 means genuinely excellent. Most real interfaces score 20-32 out of 40.

Mode applicability: heuristics 7 (Flexibility and Efficiency) and 10 (Help and Documentation) may be scored n/a on Persuade and Experience surfaces (landing pages, campaigns, portfolios, bodies of work), as may any other heuristic that genuinely cannot apply to the surface under review. Write n/a in the Score cell with a one-line reason, and renormalize the total to the applicable maximum (e.g. 24/32 when two heuristics are n/a) so the rating band stays proportional. The persisted snapshot must record the applicable maximum and which heuristics were scored n/a.

Design Specificity Verdict

Start here. Does the result feel authored for this product, or category-interchangeable?

LLM assessment: Your unanchored evaluation of design specificity. Cover overall coherence, structural sameness, category-interchangeable choices, and missed opportunities for product character.

Deterministic scan: Summarize what the automated detector found, with counts and file locations. Note any additional issues the detector caught that you missed, and flag any false positives. On a native platform, write not applicable (native platform) instead.

Visual overlays (if injection succeeded): Tell the user that overlays are now visible in the [Human] tab in their browser, highlighting the detected issues. Summarize what the console output reported. If browser visualization was attempted but injection failed, say that no reliable user-visible overlay is available and report the fallback signal instead.

Overall Impression

A brief gut reaction: what works, what doesn't, and the single biggest opportunity.

What's Working

Highlight 2-3 things done well. Be specific about why they work.

Priority Issues

The 3-5 most impactful design problems, ordered by importance.

For each issue, tag with P0-P3 severity (see Issue Severity below for definitions):

• [P?] What: Name the problem clearly

• Why it matters: How this hurts users or undermines goals

• Fix: What to do about it (be concrete)

• Suggested command: Which command could address this (from: /impeccable adapt, /impeccable animate, /impeccable audit, /impeccable bolder, /impeccable clarify, /impeccable colorize, /impeccable critique, /impeccable delight, /impeccable distill, /impeccable document, /impeccable harden, /impeccable layout, /impeccable onboard, /impeccable optimize, /impeccable overdrive, /impeccable polish, /impeccable quieter, /impeccable shape, /impeccable typeset)

Persona Red Flags

Consult the Personas reference below.

Auto-select 2-3 personas most relevant to this interface type (use the selection table in the reference). If CLAUDE.md contains a ## Design Context section from impeccable init, also generate 1-2 project-specific personas from the audience/brand info.

For each selected persona, walk through the primary user action and list specific red flags found:

Alex (Power User): No keyboard shortcuts detected. Form requires 8 clicks for primary action. Forced modal onboarding. High abandonment risk.

Jordan (First-Timer): Icon-only nav in sidebar. Technical jargon in error messages ("404 Not Found"). No visible help. Will abandon at step 2.

Be specific. Name the exact elements and interactions that fail each persona. Don't write generic persona descriptions; write what broke for them.

Minor Observations

Quick notes on smaller issues worth addressing.

Questions to Consider

Provocative questions that might unlock better solutions:

• "What if the primary action were more prominent?"

• "Does this need to feel this complex?"

• "What would a confident version of this look like?"

Remember:

• Be direct. Vague feedback wastes everyone's time.

• Be specific. "The submit button," not "some elements."

• Say what's wrong AND why it matters to users.

• Give concrete suggestions. Cut "consider exploring..." entirely.

• Prioritize ruthlessly. If everything is important, nothing is.

• Don't soften criticism. Developers need honest feedback to ship great design.

Deliver the Report

Write the full report into the chat response now, before any persistence work. This is the deliverable; everything below it is bookkeeping.

Do this first because the alternative is the most common way this command fails: the report gets composed once, straight into the persistence heredoc, and the run ends with a perfect archive nobody has read. Composing it into a file is not delivering it. If the report exists only in .impeccable/critique/, the run produced nothing.

Persistence is not the end of the run. After it, the response continues with the trend line and the close.

Persist the Snapshot

Once the report above is finalized, write it to .impeccable/critique/ so the user can refer back, and so /impeccable polish can pick up the priority issues without a copy-paste.

Skip this step if the Setup slug was null (vague or root-level target).

1. Write the body to a temp file so you can pipe it to the helper. Use the full critique report (heuristic table, design-specificity verdict, priority issues, persona red flags, minor observations, and questions), but stop before the "Ask the User" / "Recommended Actions" sections that come later.

   This is a copy of the report you already delivered above, for later commands to read. It is not delivery. If you find yourself composing the report for the first time inside this heredoc, you have skipped Deliver the Report; go back and send it.

2. Pass the structured metadata through IMPECCABLE_CRITIQUE_META (JSON), then run the write command:

   Copy

   IMPECCABLE_CRITIQUE_META='{"target":"<user phrasing>","total_score":<n>,"max_score":<n>,"na_heuristics":"<comma-separated numbers, or empty>","p0_count":<n>,"p1_count":<n>}' \
     "<skill-base-dir>/scripts/impeccable" critique-storage write "<resolved target>" <body-file>

   max_score is the applicable maximum from the heuristic table (40 when every heuristic applied), so a later run can tell a renormalized total from a full one. For a local file target, the helper also records an exact content fingerprint so polish can distinguish the assessed bytes from later edits without relying on Git state or timestamps. The helper prints the absolute path it wrote. Leave that file on disk. Polish closes it; this run does not.

3. Delete the temp body file after the write attempt completes, whether the write succeeded or failed. If deletion fails, mention temp-file cleanup failed: <reason> briefly in the final output, but do not block the critique.

4. Read the trend for context:

   Copy

   "<skill-base-dir>/scripts/impeccable" critique-storage trend "<resolved target>" 5

   This returns a JSON array of the last 5 frontmatter entries (including the one you just wrote).

5. Append a single line to the user-visible output, after the report and before the questions:

   Trend for <slug> (last 5 runs): 24 → 28 → 32 → 29 → 32 (out of 40) Wrote .impeccable/critique/<filename>.

   Read max_score on each trend entry. When every entry shares one maximum, state it once as above. When they differ, print each score with its own denominator (24/32 → 30/40) and note that the runs scored different heuristic sets, so the line is not a like-for-like comparison. Treat a missing max_score on an older entry as 40.

   If this is the first run for the slug, the trend is just one score; say so: "First run for this target, no trend yet."

6. Close the run. Go to Ask the User below and emit the questions, or the Questions skipped: <reason> line when the count allows it. The run is not complete until you do. Persistence is bookkeeping and cleanup is not an ending; stopping here leaves the user with a report and no way forward, and leaves /impeccable polish with no priorities to inherit.

This is fire-and-forget. Do not show the user the helper's JSON output; only the human-readable trend line and the written path. Failures here should not block the rest of the flow; print the error and move on.

Ask the User

After presenting findings, use targeted questions based on what was actually found. Ask with the AskUserQuestion tool and wait for the answer before continuing. These answers will shape the action plan.

Ask in the same message that carries the report, with the report written out first and the question last. Do not split the two across turns: a turn that ends on the report is a turn that ends, and the questions never arrive. Order within the message is what matters, because prose emitted after a structured question is withheld until the user answers.

Ask questions along these lines (adapt to the specific findings; do not ask generic questions):

1. Priority direction: Based on the issues found, ask which category matters most to the user right now. For example: "I found problems with visual hierarchy, color usage, and information overload. Which area should we tackle first?" Offer the top 2-3 issue categories as options.

2. Design intent: If the critique found a tonal mismatch, ask whether it was intentional. For example: "The interface feels clinical and corporate. Is that the intended tone, or should it feel warmer/bolder/more playful?" Offer 2-3 tonal directions as options based on what would fix the issues found.

3. Scope: Ask how much the user wants to take on. For example: "I found N issues. Want to address everything, or focus on the top 3?" Offer scope options like "Top 3 only", "All issues", "Critical issues only".

4. Constraints (optional; only ask if relevant): If the findings touch many areas, ask if anything is off-limits. For example: "Should any sections stay as-is?" This prevents the plan from touching things the user considers done.

Rules for questions:

• Every question must reference specific findings from the report. Never ask generic "who is your audience?" questions.

• Keep it to 2-4 questions maximum. Respect the user's time.

• Offer concrete options, not open-ended prompts.

• Skipping is allowed only when the report listed fewer than 3 Priority Issues. Count them; do not judge the findings "straightforward" by feel. At 3 or more, the questions are required.

Final-question gate. The user-visible response must either include the targeted questions or carry the literal line Questions skipped: <reason> naming the count that permitted the skip. Each question must include 2-3 concrete answer options tied to the actual critique findings. Do not end with only open-ended questions, and do not end with neither: stopping after the report, having asked nothing and printed no skip line, is the most common way this command fails.

Recommended Actions

After receiving the user's answers, present a prioritized action summary reflecting the user's priorities and scope from Ask the User.

Action Summary

List recommended commands in priority order, based on the user's answers:

1. /command-name: Brief description of what to fix (specific context from critique findings)

2. /command-name: Brief description (specific context) ...

Rules for recommendations:

• Only recommend commands from: /impeccable adapt, /impeccable animate, /impeccable audit, /impeccable bolder, /impeccable clarify, /impeccable colorize, /impeccable critique, /impeccable delight, /impeccable distill, /impeccable document, /impeccable harden, /impeccable layout, /impeccable onboard, /impeccable optimize, /impeccable overdrive, /impeccable polish, /impeccable quieter, /impeccable shape, /impeccable typeset

• Order by the user's stated priorities first, then by impact

• Each item's description should carry enough context that the command knows what to focus on

• Map each Priority Issue to the appropriate command

• Skip commands that would address zero issues

• If the user chose a limited scope, only include items within that scope

• If the user marked areas as off-limits, exclude commands that would touch those areas

• End with /impeccable polish as the final step if any fixes were recommended

After presenting the summary, tell the user:

You can ask me to run these one at a time, all at once, or in any order you prefer.

Re-run /impeccable critique after fixes to see your score improve.

Reference Material

The sections below were previously separate reference files (cognitive-load.md, heuristics-scoring.md, personas.md). They live inline now so the critique flow has all its deep context in one place.

Cognitive Load Assessment

Cognitive load is the total mental effort required to use an interface. Overloaded users make mistakes, get frustrated, and leave. This reference helps identify and fix cognitive overload.

Three Types of Cognitive Load

Intrinsic Load: The Task Itself

Complexity inherent to what the user is trying to do. You can't eliminate this, but you can structure it.

Manage it by:

• Breaking complex tasks into discrete steps

• Providing scaffolding (templates, defaults, examples)

• Progressive disclosure: show what's needed now, hide the rest

• Grouping related decisions together

Extraneous Load: Bad Design

Mental effort caused by poor design choices. Eliminate this ruthlessly. It's pure waste.

Common sources:

• Confusing navigation that requires mental mapping

• Unclear labels that force users to guess meaning

• Visual clutter competing for attention

• Inconsistent patterns that prevent learning

• Unnecessary steps between user intent and result

Germane Load: Learning Effort

Mental effort spent building understanding. This is good cognitive load; it leads to mastery.

Support it by:

• Progressive disclosure that reveals complexity gradually

• Consistent patterns that reward learning

• Feedback that confirms correct understanding

• Onboarding that teaches through action, not walls of text

Cognitive Load Checklist

Evaluate the interface against these 8 items:

• [ ] Single focus: Can the user complete their primary task without distraction from competing elements?

• [ ] Chunking: Is information presented in digestible groups (≤4 items per group)?

• [ ] Grouping: Are related items visually grouped together (proximity, borders, shared background)?

• [ ] Visual hierarchy: Is it immediately clear what's most important on the screen?

• [ ] One thing at a time: Can the user focus on a single decision before moving to the next?

• [ ] Minimal choices: Are decisions simplified (≤4 visible options at any decision point)?

• [ ] Working memory: Does the user need to remember information from a previous screen to act on the current one?

• [ ] Progressive disclosure: Is complexity revealed only when the user needs it?

Scoring: Count the failed items. 0–1 failures = low cognitive load (good). 2–3 = moderate (address soon). 4+ = high cognitive load (critical fix needed).

The Working Memory Rule

Humans can hold ≤4 items in working memory at once (Miller's Law revised by Cowan, 2001).

At any decision point, count the number of distinct options, actions, or pieces of information a user must simultaneously consider:

• ≤4 items: Within working memory limits, manageable

• 5–7 items: Pushing the boundary; consider grouping or progressive disclosure

• 8+ items: Overloaded; users will skip, misclick, or abandon

Practical applications:

• Action buttons: 1 primary, 1–2 secondary, group the rest in a menu

• Navigation menus: ≤5 top-level items (group the rest under clear categories)

• Long-form articles: one reading path; gather related links into a single block at the end instead of scattering them mid-flow

• Documentation sidebars: ≤4 sibling choices visible per level before grouping kicks in

• Portfolio and gallery indexes: one decision per screen (which piece to open), not filter, sort, and tag controls all at once

Common Cognitive Load Violations

1. The Wall of Options

Problem: Presenting 10+ choices at once with no hierarchy. Fix: Group into categories, highlight recommended, use progressive disclosure.

2. The Memory Bridge

Problem: User must remember info from step 1 to complete step 3. Fix: Keep relevant context visible, or repeat it where it's needed.

3. The Hidden Navigation

Problem: User must build a mental map of where things are. Fix: Always show current location (breadcrumbs, active states, progress indicators).

4. The Jargon Barrier

Problem: Technical or domain language forces translation effort. Fix: Use plain language. If domain terms are unavoidable, define them inline.

5. The Visual Noise Floor

Problem: Every element has the same visual weight; nothing stands out. Fix: Establish clear hierarchy: one primary element, 2–3 secondary, everything else muted.

6. The Inconsistent Pattern

Problem: Similar actions work differently in different places. Fix: Standardize interaction patterns. Same type of action = same type of UI.

7. The Multi-Task Demand

Problem: Interface requires processing multiple simultaneous inputs (reading + deciding + navigating). Fix: Sequence the steps. Let the user do one thing at a time.

8. The Context Switch

Problem: User must jump between screens/tabs/modals to gather info for a single decision. Fix: Co-locate the information needed for each decision. Reduce back-and-forth.

Heuristics Scoring Guide

Score each of Nielsen's 10 Usability Heuristics on a 0–4 scale. Be honest: a 4 means genuinely excellent, not "good enough."

Nielsen's 10 Heuristics

1. Visibility of System Status

Keep users informed about what's happening through timely, appropriate feedback.

Check for:

• Loading indicators during async operations

• Confirmation of user actions (save, submit, delete)

• Progress indicators for multi-step processes

• Current location in navigation (breadcrumbs, active states)

• Form validation feedback (inline, not just on submit)

Scoring:

2. Match Between System and Real World

Speak the user's language. Follow real-world conventions. Information appears in natural, logical order.

Check for:

• Familiar terminology (no unexplained jargon)

• Logical information order matching user expectations

• Recognizable icons and metaphors

• Domain-appropriate language for the target audience

• Natural reading flow (left-to-right, top-to-bottom priority)

Scoring:

3. User Control and Freedom

Users need a clear "emergency exit" from unwanted states without extended dialogue.

Check for:

• Undo/redo functionality

• Cancel buttons on forms and modals

• Clear navigation back to safety (home, previous)

• Easy way to clear filters, search, selections

• Escape from long or multi-step processes

Scoring:

4. Consistency and Standards

Users shouldn't wonder whether different words, situations, or actions mean the same thing.

Check for:

• Consistent terminology throughout the interface

• Same actions produce same results everywhere

• Platform conventions followed (standard UI patterns)

• Visual consistency (colors, typography, spacing, components)

• Consistent interaction patterns (same gesture = same behavior)

Scoring:

5. Error Prevention

Better than good error messages is a design that prevents problems in the first place.

Check for:

• Confirmation before destructive actions (delete, overwrite)

• Constraints preventing invalid input (date pickers, dropdowns)

• Smart defaults that reduce errors

• Clear labels that prevent misunderstanding

• Autosave and draft recovery

Scoring:

6. Recognition Rather Than Recall

Minimize memory load. Make objects, actions, and options visible or easily retrievable.

Check for:

• Visible options (not buried in hidden menus)

• Contextual help when needed (tooltips, inline hints)

• Recent items and history

• Autocomplete and suggestions

• Labels on icons (not icon-only navigation)

Scoring:

7. Flexibility and Efficiency of Use

Accelerators, invisible to novices, speed up expert interaction.

Check for:

• Keyboard shortcuts for common actions

• Customizable interface elements

• Recent items and favorites

• Bulk/batch actions

• Power user features that don't complicate the basics

Scoring:

8. Aesthetic and Minimalist Design

Interfaces should not contain irrelevant or rarely needed information. Every element should serve a purpose.

Check for:

• Only necessary information visible at each step

• Clear visual hierarchy directing attention

• Purposeful use of color and emphasis

• No decorative clutter competing for attention

• Focused, uncluttered layouts

Scoring:

9. Help Users Recognize, Diagnose, and Recover from Errors

Error messages should use plain language, precisely indicate the problem, and constructively suggest a solution.

Check for:

• Plain language error messages (no error codes for users)

• Specific problem identification ("Email is missing @" not "Invalid input")

• Actionable recovery suggestions

• Errors displayed near the source of the problem

• Non-blocking error handling (don't wipe the form)

Scoring:

10. Help and Documentation

Even if the system is usable without docs, help should be easy to find, task-focused, and concise.

Check for:

• Searchable help or documentation

• Contextual help (tooltips, inline hints, guided tours)

• Task-focused organization (not feature-organized)

• Concise, scannable content

• Easy access without leaving current context

Scoring:

Score Summary

Total possible: 40 points (10 heuristics × 4 max)

When heuristics were scored n/a, the maximum is lower than 40; read the band off the percentage instead of the raw number (90%+ Excellent, 70%+ Good, 50%+ Acceptable, 30%+ Poor, below that Critical). 24/32 is 75%, so Good.

Issue Severity (P0–P3)

Tag each individual issue found during scoring with a priority level:

Tip: If you're unsure between two levels, ask: "Would a user contact support about this?" If yes, it's at least P1.

Persona-Based Design Testing

Test the interface through the eyes of 5 distinct user archetypes. Each persona exposes different failure modes that a single "design director" perspective would miss.

How to use: Select 2–3 personas most relevant to the interface being critiqued. Walk through the primary user action as each persona. Report specific red flags, not generic concerns.

1. Impatient Power User: "Alex"

Profile: Expert with similar products. Expects efficiency, hates hand-holding. Will find shortcuts or leave.

Behaviors:

• Skips all onboarding and instructions

• Looks for keyboard shortcuts immediately

• Tries to bulk-select, batch-edit, and automate

• Gets frustrated by required steps that feel unnecessary

• Abandons if anything feels slow or patronizing

Test Questions:

• Can Alex complete the core task in under 60 seconds?

• Are there keyboard shortcuts for common actions?

• Can onboarding be skipped entirely?

• Do modals have keyboard dismiss (Esc)?

• Is there a "power user" path (shortcuts, bulk actions)?

Red Flags (report these specifically):

• Forced tutorials or unskippable onboarding

• No keyboard navigation for primary actions

• Slow animations that can't be skipped

• One-item-at-a-time workflows where batch would be natural

• Redundant confirmation steps for low-risk actions

2. Confused First-Timer: "Jordan"

Profile: Never used this type of product. Needs guidance at every step. Will abandon rather than figure it out.

Behaviors:

• Reads all instructions carefully

• Hesitates before clicking anything unfamiliar

• Looks for help or support constantly

• Misunderstands jargon and abbreviations

• Takes the most literal interpretation of any label

Test Questions:

• Is the first action obviously clear within 5 seconds?

• Are all icons labeled with text?

• Is there contextual help at decision points?

• Does terminology assume prior knowledge?

• Is there a clear "back" or "undo" at every step?

Red Flags (report these specifically):

• Icon-only navigation with no labels

• Technical jargon without explanation

• No visible help option or guidance

• Ambiguous next steps after completing an action

• No confirmation that an action succeeded

3. Accessibility-Dependent User: "Sam"

Profile: Uses screen reader (VoiceOver/NVDA), keyboard-only navigation. May have low vision, motor impairment, or cognitive differences.

Behaviors:

• Tabs through the interface linearly

• Relies on ARIA labels and heading structure

• Cannot see hover states or visual-only indicators

• Needs adequate color contrast (4.5:1 minimum)

• May use browser zoom up to 200%

Test Questions:

• Can the entire primary flow be completed keyboard-only?

• Are all interactive elements focusable with visible focus indicators?

• Do images have meaningful alt text?

• Is color contrast WCAG AA compliant (4.5:1 for text)?

• Does the screen reader announce state changes (loading, success, errors)?

Red Flags (report these specifically):

• Click-only interactions with no keyboard alternative

• Missing or invisible focus indicators

• Meaning conveyed by color alone (red = error, green = success)

• Unlabeled form fields or buttons

• Time-limited actions without extension option

• Custom components that break screen reader flow

4. Deliberate Stress Tester: "Riley"

Profile: Methodical user who pushes interfaces beyond the happy path. Tests edge cases, tries unexpected inputs, and probes for gaps in the experience.

Behaviors:

• Tests edge cases intentionally (empty states, long strings, special characters)

• Submits forms with unexpected data (emoji, RTL text, very long values)

• Tries to break workflows by navigating backwards, refreshing mid-flow, or opening in multiple tabs

• Looks for inconsistencies between what the UI promises and what actually happens

• Documents problems methodically

Test Questions:

• What happens at the edges (0 items, 1000 items, very long text)?

• Do error states recover gracefully or leave the UI in a broken state?

• What happens on refresh mid-workflow? Is state preserved?

• Are there features that appear to work but produce broken results?

• How does the UI handle unexpected input (emoji, special chars, paste from Excel)?

Red Flags (report these specifically):

• Features that appear to work but silently fail or produce wrong results

• Error handling that exposes technical details or leaves UI in a broken state

• Empty states that show nothing useful ("No results" with no guidance)

• Workflows that lose user data on refresh or navigation

• Inconsistent behavior between similar interactions in different parts of the UI

5. Distracted Mobile User: "Casey"

Profile: Using phone one-handed on the go. Frequently interrupted. Possibly on a slow connection.

Behaviors:

• Uses thumb only; prefers bottom-of-screen actions

• Gets interrupted mid-flow and returns later

• Switches between apps frequently

• Has limited attention span and low patience

• Types as little as possible, prefers taps and selections

Test Questions:

• Are primary actions in the thumb zone (bottom half of screen)?

• Is state preserved if the user leaves and returns?

• Does it work on slow connections (3G)?

• Can forms use autocomplete and smart defaults?

• Are touch targets at least 44×44pt?

Red Flags (report these specifically):

• Important actions positioned at the top of the screen (unreachable by thumb)

• No state persistence; progress lost on tab switch or interruption

• Large text inputs required where selection would work

• Heavy assets loading on every page (no lazy loading)

• Tiny tap targets or targets too close together

Selecting Personas

Choose personas based on the interface type:

Project-Specific Personas

If CLAUDE.md contains a ## Design Context section (generated by impeccable init), derive 1–2 additional personas from the audience and brand information:

1. Read the target audience description

2. Identify the primary user archetype not covered by the 5 predefined personas

3. Create a persona following this template:

##### [Role]: "[Name]"

**Profile**: [2-3 key characteristics derived from Design Context]

**Behaviors**: [3-4 specific behaviors based on the described audience]

**Red Flags**: [3-4 things that would alienate this specific user type]

Only generate project-specific personas when real Design Context data is available. Don't invent audience details; use the 5 predefined personas when no context exists.