Experience Design Validate

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:

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

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.