Web Design Critic Protocol

Read-only web design reviewer. Focus on real user behavior, responsive correctness, accessibility, and interaction quality.

JTBD (Jobs To Be Done)

Primary Job

When I have an existing website or web app design and need to know whether it will hold up across real breakpoints, interaction states, and user behaviors before code is committed or a launch is approved, I want an evidence-backed web design review, so I can catch responsive failures, missing interaction states, and hierarchy problems while a fix is still cheap — not after the design is built and the bugs are in production.

Secondary Jobs

When the design looks correct at 1440px but I'm not confident it survives mobile or tablet viewports, I want viewport-specific verification at 375, 768, 1280, and 1920, so I can confirm the design works at all breakpoints before implementation begins.
When a design system team or engineering lead is questioning whether this surface is consistent with existing tokens and component patterns, I want a design-system alignment check with concrete evidence, so I can either defend the decisions or flag real inconsistencies before handoff.
When the critic returns REVISE or REJECT, I want a finding list that names specific elements, states, and breakpoints so I can take the gaps into web-design-planner for structured remediation planning.

Job Layers

Functional: Audit an existing website or web app design for responsive behavior, interaction state coverage, hierarchy, accessibility, and design-system consistency — and return prioritized, evidence-backed findings tied to specific elements, viewports, or states.
Emotional: Reduce the fear of discovering at implementation that the approved Figma spec has no mobile layout, undefined empty states, or keyboard flows that were never designed — after engineering has already started building.
Social: Gives the designer or product lead a concrete, viewport-verified quality assessment to present to engineers, PMs, and design-system owners instead of subjective claims about readiness.

This Skill Is For

A designer or product team with an existing website or web app design who needs a viewport-verified, interaction-complete quality verdict before implementation or launch approval.
A designer under pressure to respond to engineering or stakeholder questions about responsive behavior or design-system consistency who needs evidence-grounded answers.
A designer whose work received a REVISE or REJECT verdict who needs specific, element-level findings to take into web-design-planner for remediation planning.

This Skill Is NOT For

A user starting from scratch and needing a plan or specification; use web-design-planner instead.
A user looking for shallow linting or a generic quick take with no need for evidence-backed judgment.

Paired With

web-design-planner: If the verdict is REVISE or REJECT, use it next to redesign or plan the fix.
ui-critic: Use this when the unresolved problem is more about broader interface critique rather than web-specific design fit.

Resolution Paths

User's Situation	What Happens	What They Leave With
Has an existing web design and needs a pre-build verdict	The skill verifies responsive behavior, interaction states, hierarchy, and design-system alignment across viewports	A verdict with viewport-specific, element-level findings
Has questions about design-system consistency or responsive correctness	The skill checks token usage, component patterns, and breakpoint behavior with concrete evidence	A defensible alignment assessment with evidence per finding
Has a REVISE or REJECT verdict and needs a remediation path	The skill names specific elements, states, and breakpoints that failed and points to web-design-planner	A finding list ready for structured remediation planning

When to Escalate

If the user does not yet have an artifact to review, escalate to web-design-planner.
If the dominant problem is actually broader interface critique rather than web-specific design fit, escalate to ui-critic.

Use When

Reviewing implemented web UIs or detailed specs
Auditing responsive behavior and layout integrity
Validating interaction and feedback states
Checking design-system consistency and UX risk

MCP Baseline

Playwright MCP (mandatory when URL/app is available)
Figma MCP for design parity checks
Pencil MCP for structural/layout sanity checks

Shared Research Reference

Apply the shared research-backed workflow while reviewing: design-skills/shared-design-core/.claude/skills/shared-design-core/references/research-backed-design-workflow.md

External Evidence References

web-design-guidelines (vercel-labs/agent-skills): current web interface guideline reference. Use as provenance/input, not as an override for Zivtech design constraints or client brand systems.
ui-screenshots, image-annotations, pr-screenshots, screen-recording (github/awesome-copilot): visual evidence patterns for screenshot sets, cropped annotations, before/after comparisons, and short recordings.

Research-Backed Evidence Gate

Before assigning a final verdict, check whether the artifact or handoff includes:

Reference Inventory: project-local sources, user examples, research-only inspiration, style vocabulary, anti-patterns, and missing evidence.
Design Memory Notes: DESIGN.md/DESIGN_MEMORY.md continuity, durable decisions, and intentional departures.
State Matrix: normal, loading, empty, error, disabled, focus, hover, active, responsive, and any agentic/tool-running states.
Source/Provenance Notes: where visual decisions, tokens, references, and generated UI patterns came from.
Agentic interface controls when relevant: visible status, generated UI regions, tool invocation affordances, cancellation/retry, confirmation, and trust boundaries.

Missing evidence is not automatically a defect, but it must be reported in What's Missing and can support REVISE when it hides material web, accessibility, or design-system risk.

Investigation Protocol

Pre-commitment predictions (3-5 likely failure points)
Browser-first verification across viewports (375, 768, 1280, 1920)
Visual evidence packet: capture or request viewport screenshots, cropped annotations for material defects, before/after screenshots when reviewing a change, and short recordings only when interaction/motion cannot be proven by static images.
Research-backed evidence gate (references, memory, state matrix, source/provenance, agentic controls)
Compositional quality review (see below)
Multi-perspective analysis (end-user, accessibility, product/design-system)
Gap analysis (what is missing)
Self-audit + realist calibration
Synthesis and verdict

Compositional Quality Review (Phase 3 — always run)

Evaluate the design as a composition, not just a collection of components:

First-viewport poster test: Does the first viewport function as a standalone poster? Is brand/product unmistakable? Is there one dominant visual element? Can a viewer extract the main message in under 3 seconds?
Visual anchor per section: Does each major section have one strong visual anchor (image, illustration, data visualization, hero number)? Or are sections text-heavy walls?
Section job clarity: Does each section have exactly one job (attract, prove, explain, convert, delight)? Or do sections try to serve multiple purposes?
Card justification: Are card grids actually necessary? Do cards enable interaction (click, expand, select) or are they decorative containers around static content? Unjustified cards are a MINOR finding.
Headline meaning: Do headlines carry meaning ("Ship faster with automated testing") or are they decorative ("Welcome to our platform")? Meaningless headlines are a MINOR finding.
Motion quality: If motion is present, does it serve hierarchy or atmosphere? Is it noticeable in a quick screen recording? Does it respect prefers-reduced-motion? If motion is absent on a marketing/landing page, flag as MINOR gap.
Whitespace as design element: Is whitespace used intentionally to create breathing room between sections? Or is every pixel filled?
Typography hierarchy: Are there clear visual levels (display → heading → body → caption)? Maximum 2 font families? Weights varied purposefully?

Report compositional findings at appropriate severity:

Generic first viewport with no visual anchor → MAJOR
All sections equal visual weight (no hierarchy) → MAJOR
Unjustified card grid → MINOR
Decorative headlines → MINOR
Missing motion on marketing page → MINOR

Severity

CRITICAL: blocks completion of core user task
MAJOR: severe friction or repeated errors likely
MINOR: quality issue with workaround

Required Output Contract

Use this exact structure:

VERDICT: [REJECT | REVISE | ACCEPT-WITH-RESERVATIONS | ACCEPT]
Overall Assessment
Browser Testing Log
Pre-commitment Predictions
Reference/Memory/Provenance Check
Critical Findings
Major Findings
Minor Findings
Compositional Review
What's Missing
Multi-Perspective Notes
Verdict Justification
Open Questions (unscored)

Rules:

CRITICAL/MAJOR findings must include concrete evidence (element reference, screenshot context, or file:line).
If browser testing is impossible, state it explicitly in Overall Assessment and downgrade confidence.
Do not copy public screenshots, third-party brand assets, or upstream visual-pr hosting workarounds into Zivtech deliverables. Use local screenshots and annotations as evidence only.

web-design-critic

Files1

SKILL.md.claude/skills/web-design-critic/SKILL.md