# Audit UI Design > Audit existing UI designs and implemented interfaces using evidence from screenshots, images, Figma exports, live URLs, local frontends, or multi-screen flows. Use when Codex needs to critique visual interface quality, find and prioritize design problems, compare UI variants, review hierarchy/layout/color/typography/consistency, reduce interaction cost, recommend concrete fixes, or recheck a design after changes. This is a UI design audit, not a substitute for user research or a complete accessibility conformance review. - Skill: `yysun/audit-ui-design` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add yysun/audit-ui-design` - Raw SKILL.md: https://api.skillmd.com/api/skills/yysun/audit-ui-design/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: yysun (https://skillmd.com/u/yysun) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/yysun/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](references/ui-design-rules.md) for the applicable visual and interaction principles. For a comprehensive audit, read it fully. - Read [references/evaluation-rubric.md](references/evaluation-rubric.md) before assigning severity, confidence, or any score. - Use [references/report-template.md](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.