Experience Design Validate

Evaluate the visual craft of rendered software: what the eye sees and the felt quality those visible decisions create. Judge relationships, hierarchy, restraint, consistency, and care rather than CSS, tokens, or implementation technique.

This is a visual-craft-only audit. It does not establish WCAG conformance, keyboard or screen-reader support, behavioral usability, implementation quality, or production release readiness. Route accessibility compliance to experience-accessibility-validate and SLDS compliance to design-systems-slds-validate.

Use and boundaries

Use this skill to:

• Critique visual craft at a design checkpoint.
• Explain why a rendered design feels considered, cramped, calm, fragmented, or delightful.
• Compare the craft of two or more designs solving the same brief.
• Identify design moves that would lift a visible experience from good to great.

Do not use this skill for:

• Implementation or code review. For LWC generation or security review, use experience-lwc-generate or experience-lwc-security-validate as appropriate.
• Accessibility compliance, including WCAG, screen-reader, keyboard, or focus-order validation. Use experience-accessibility-validate.
• SLDS design-token compliance. Use design-systems-slds-validate.
• Claims about real-user behavior. Recommend a usability study when impact depends on behavior rather than visible evidence.

Visual evidence contract

Rendered pixels are mandatory. Prefer screenshots because they preserve the exact evidence reviewed.

1. Screenshots: use supplied full-page or region captures directly.
2. Live URL: if browser capability is available, open the URL, exercise only the relevant paths, capture screenshots, and retain the URL and viewport as evidence. Otherwise ask for screenshots.
3. Figma: if Figma capability is available, fetch or export the named rendered frames. Treat a frame as static unless prototype behavior is actually exercised. Otherwise ask for frame exports or screenshots.
4. Screen recording or interactive prototype: inspect observable transitions and capture representative frames when tooling supports it.
5. Source code, design descriptions, or inaccessible links: do not infer the rendered result. Render with available capability; otherwise request screenshots.

If no rendered pixels are available:

• Interactive run: ask the user for screenshots or another rendered artifact and pause the audit.
• Non-interactive run: return status INSUFFICIENT_VISUAL_EVIDENCE with a short statement of the missing artifact. Do not score, assign a verdict, create findings, or imply readiness.

Evidence modes

Declare one mode before analysis:

Mode	What it can support	What it cannot support
STATIC_VISUAL	Visible hierarchy, spacing, typography, color, density, composition, consistency, and the visible treatment of the captured moment	Interaction behavior, transitions between states, responsive adaptation beyond captured viewports, latency, runtime performance, or unseen states
MULTI_VIEW_STATIC	Static visual evidence across supplied screens, states, or viewport captures, including cross-screen coherence	The behavior connecting captures, timing, input response, runtime performance, or states not shown
DYNAMIC_VISUAL	Static qualities plus behavior directly exercised or recorded: interaction feedback, transitions, state changes, and perceived performance	Unexercised paths, unrecorded states, accessibility compliance, or measured performance beyond what was observed

A static screenshot of a loading, error, or empty state supports critique of that state's visible treatment only. It does not substantiate state coverage, transition behavior, or performance. Never lower a score because an unobserved state or behavior was not supplied; mark that coverage INSUFFICIENT_EVIDENCE instead.

Five dimensions

Dimension	Felt question
Useful	Does the visible content earn the space and attention it occupies?
Usable	Does the visible hierarchy and affordance make the intended path feel obvious?
Reliable	Do the observed states and feedback make the experience feel predictable?
Coherent	Does the visible experience feel made by one team with one taste?
Well-Crafted	Does the visible design feel precise, considered, and delightful?

Use a 1-10 score only when the available evidence adequately covers a dimension. Use INSUFFICIENT_EVIDENCE when an applicable dimension cannot be supported. Use N/A only when the dimension or topic genuinely does not apply, never merely because evidence is missing.

Read references/scoring-rubric.md for scoring anchors, verdict rules, severity definitions, and the complete report contract.

Craft lens

Ask whether the rendered experience feels:

• Breathable: space structures the composition and gives the eye room.
• Approachable: the intended path is visually obvious without explanation.
• Inviting: visible states encourage exploration rather than present dead ends.
• Considered: repeated decisions form a system rather than an accumulation.
• Quiet: hierarchy is calm; few elements compete to be primary.
• Delightful: detail and personality are purposeful, not ornamental noise.
• Confident: the design has a point of view and avoids unnecessary hedging.

Audit workflow

Follow this order:

1. Establish the evidence mode and inventory every supplied or captured artifact.
2. If no rendered pixels exist, follow the insufficient-visual-evidence behavior and stop.
3. Look before consulting rules. Record up to three honest first impressions for each design.
4. Build the coverage and relevance ledger. For every dimension and reference topic, record SCORED, N/A, or INSUFFICIENT_EVIDENCE, the evidence mode, and a concise reason.
5. Load references/craft.md, references/scoring-rubric.md, and references/visual-system.md. Load only conditional references whose topic is both relevant and observable in the evidence mode.
6. Score only supported dimensions. Select the highest anchor whose applicable, observable criteria are fully supported; use an odd score only when evidence clearly exceeds that anchor without fully supporting the next.
7. Write findings. Cap findings at five per dimension and deduplicate cross-dimensional root causes.
8. Write the Craft Report, including the ledger and evidence limitations.

Progressive disclosure

Always load:

• references/scoring-rubric.md: scoring, coverage, severity, verdict, and report schema.
• references/craft.md: felt qualities of considered work.
• references/visual-system.md: visible layout, typography, color, and surfaces.

Load only when relevant and observable:

Reference	Evidence needed
references/components.md	Visible buttons, inputs, modals, lists, tables, or feedback components
references/navigation.md	Visible navigation, tabs, breadcrumbs, search, or wayfinding
references/responsive.md	Captures from multiple viewports or directly exercised resizing
references/forms-flows.md	Multiple visible steps or directly exercised form behavior
references/data.md	Visible charts, dashboards, metrics, filters, results, or tables
references/records.md	Visible records, detail pages, status, metadata, or collaboration
references/ai.md	Visible AI, agent, chat, citations, or model output
references/trust.md	Visible auth, privacy, consent, permissions, or destructive settings
references/usability.md	Visible task structure; do not infer behavioral usability
references/interaction.md	DYNAMIC_VISUAL evidence of interaction or motion
references/state.md	DYNAMIC_VISUAL state transitions; static state captures support appearance only
references/performance.md	DYNAMIC_VISUAL evidence of timing, latency, or layout stability

Finding voice

Speak at the felt level and anchor claims to visible evidence.

Good: "The toolbar feels overworked; too many controls compete for attention, so the eye cannot find the primary action."

Wrong scope: "Three button classes use inconsistent spacing tokens." That belongs in implementation or SLDS review.

Each finding must include severity, primary_dimension, optional related_dimensions, location, problem, why_it_weakens_craft, what_better_looks_like, and fix. When one problem appears in three or more places, create one finding with a count and representative location.

Comparative audits

Audit each design independently with the same evidence requirements and rubric. The report must include:

• Per-design evidence mode, coverage ledger, first impressions, dimension scores, evidence, and gap to the next supported level.
• A side-by-side comparison table that preserves N/A and INSUFFICIENT_EVIDENCE rather than forcing numeric comparisons.
• A result of A_HIGHER_CRAFT, B_HIGHER_CRAFT, TIE, or MIXED. Use MIXED when leadership varies by dimension or evidence coverage prevents an overall ranking.
• Differentiating dimensions, concrete craft moves each design makes better, and improvements each could borrow without copying.

Do not crown a winner when the evidence supports a tie or mixed outcome.

Output

If the user explicitly supplies an output path, write there exactly; that path overrides the naming convention. Otherwise use YYYY-MM-DD-<target-slug>-craft-audit-<VERDICT>.md, with uppercase PASS, WARN, FAIL, or LIMITED.

The report must make its scope explicit: verdicts and readiness implications cover visual craft only, not accessibility, functional correctness, measured performance, or production release approval.

Recommendations and cross-cutting patterns each contain zero to five items. Include only evidence-backed, useful entries; never add filler to reach a quota. End with the fix prompt defined in references/scoring-rubric.md only when at least one actionable recommendation exists.

Core principles

1. Pixels first. No rendered evidence means no visual-craft audit.
2. Eye first, rules second. Record first impressions before rubric analysis.
3. Evidence bounds claims. Unobserved behavior is unknown, not defective.
4. Felt level, not implementation level. Describe visual experience, not code.
5. Teach while auditing. Explain why each finding matters and what better feels like.
6. Severity over volume. A few sharp findings beat a padded checklist.