Audit UI Design

Audit UI Design

Evaluate whether an interface makes the user's task clear, efficient, readable, and visually coherent. Produce evidence-backed decisions, not generic design advice or taste presented as fact.

Load the references

• Read references/ui-design-rules.md for the applicable visual and interaction principles. For a comprehensive audit, read it fully.
• Read references/evaluation-rubric.md before assigning severity, confidence, or any score.
• Use references/report-template.md to structure the result. Adapt the headings to the artifact; do not output empty sections.

Set the audit depth

Adapt depth instead of asking the user to choose a named mode.

• Default to the complete artifact in scope, but report only the highest-value findings, usually 5-10.
• Treat requests such as "full," "comprehensive," "every screen," or "design-system review" as systematic audits. Include coverage, strengths, cross-screen patterns, and every material issue without padding the report with trivial observations.
• Follow explicit limits such as "top three issues" or "only review typography."
• When the artifact is too large for the requested depth, state the sampled screens and the evidence gap.

Audit workflow

1. Establish the job of the interface

Identify or reasonably infer:

• the primary user and task;
• the screen's intended decision or next action;
• the platform, viewport, and relevant state;
• known product, brand, or design-system constraints.

Ask a question only when missing context would materially change the judgment. Otherwise state the assumption and proceed.

2. Acquire direct evidence

• Inspect the actual screenshot, design, rendered page, or running interface before judging it.
• For a live URL or local frontend, capture the relevant viewport and states. Inspect responsive behavior when it is in scope.
• For a flow, inspect the transition points, decision states, empty states, validation, errors, completion, and recovery where available.
• For variants, compare them against the same user task and constraints.
• Do not infer hidden behavior from a static image. Mark it Not assessable or lower confidence.
• Treat source code as supporting evidence, not a substitute for inspecting the rendered UI.

3. Review in five passes

1. Task comprehension: clarity, hierarchy, primary action, navigation, content order, and misleading cues.
2. Spatial system: proximity, alignment, whitespace, layout, balance, consistency, and responsive fit.
3. Visual language: contrast, color, typography, icons, imagery, depth, texture, and state differentiation.
4. Interaction cost: choices, steps, target placement, recognition, input effort, feedback, error prevention, recovery, and mobile reach.
5. System behavior: repeated components, cross-screen consistency, empty/error/success states, and design-system causes.

Evaluate principles in context. A deliberate exception is acceptable when it improves the task and preserves readability, predictability, and access.

4. Build an evidence chain

Every finding must connect:

observed evidence -> applicable principle -> user or business consequence -> severity -> concrete fix -> verification

For each finding:

• name the exact screen, region, component, or state;
• describe what is visible without exaggeration;
• cite the relevant playbook page range from the rules reference;
• explain the effect on task completion, comprehension, error risk, efficiency, access, or trust;
• propose the smallest fix that addresses the cause, not merely the symptom;
• state how to verify the fix.

Merge repeated symptoms into one systemic finding. Do not manufacture one finding per checklist item.

5. Prioritize with judgment

• Use Blocker, Major, Minor, or Polish from the rubric.
• Add High, Medium, or Low confidence when evidence is incomplete or interpretation is material.
• Rank severity before ease of implementation. A cheap cosmetic change does not outrank a difficult task failure.
• Identify systemic causes when one token, component, or layout rule creates several defects.
• Do not assign a numeric score unless the user requests one. If requested, show dimension ratings and unknowns; do not hide them in an arbitrary composite.

6. Report and, when requested, recheck

• Lead with the overall judgment and the decisions that matter most.
• Include strengths only when direct evidence supports them.
• Separate rule violations from optional stylistic improvements.
• If the user asks for implementation, audit first, change the interface, capture the affected states again, and verify each material finding.
• If the user asks only for evaluation, do not modify the design or code.

Guardrails

• Do not claim the playbook covers complete UX research, information architecture, localization, inclusive design, or accessibility conformance.
• Flag obvious readability and accessibility risks, but recommend a dedicated standards-based audit for compliance claims.
• Do not enforce heuristics mechanically when platform conventions, localization, user needs, or product constraints justify a different solution.
• Do not call a design "confusing," "clean," "intuitive," or "modern" without visible evidence and a consequence.
• Do not prescribe exact pixels or colors unless the artifact, design system, or applicable standard supports them.
• Do not reward visual novelty when it increases task cost or hides meaning.