---
name: product-ui-review
description: Load when an existing Web product, especially a dashboard, dense-data view, or multi-step app, needs a deep evidence-backed experience review; report findings only, and use design-taste-frontend for marketing-page direction, code-review for source diffs, web-design-guidelines for checklist compliance, or frontend-design for implementation.
license: MIT
---

# Product UI Review

Diagnose an existing Web product experience from available evidence. Report only: do not edit product files, submit forms, publish, delete, or perform other state-changing actions while reviewing.

## Evidence Boundary

Use rendered UI, supplied screenshots or recordings, relevant source, and explicit user facts. Anchor each finding to the most precise evidence available: route, viewport, state, control, screenshot, requirement, or `file:line`.

Keep observation separate from interpretation. Do not invent analytics, research findings, hidden states, performance measurements, or accessibility results. Mark unavailable evidence as unknown; leave any check that would require a remote mutation unverified.

Read `references/review-lenses.md` before reviewing. Apply only lenses relevant to the product and task.

## Finding Contract

Consolidate related symptoms under their likely root cause. For each material finding, report:

- **Observed**: what the evidence directly shows.
- **Inferred**: the likely cause or user consequence, clearly marked as interpretation.
- **Impact**: affected task, user, frequency, and severity where evidence supports them.
- **Confidence**: high, medium, or low, with the evidence gap that limits certainty.
- **Recommendation**: the smallest coherent product or interaction change, preserving useful existing patterns.
- **Verification**: the completed check and result; otherwise `Not run — <specific observable check>`.

Order findings by user impact and confidence. Do not collapse unlike concerns into a total score. Preserve strengths and intentional constraints so the review does not become a redesign-by-default exercise.

## Boundaries

- Use `design-taste-frontend` for visual direction on landing pages, portfolios, and marketing redesigns.
- Use `web-design-guidelines` for current guideline compliance and terse rule findings.
- Use `code-review` for implementation defects in a source diff.
- Use `effective-interact` only when the resulting review needs richer presentation or comparison.
- Use `frontend-design` when the user authorizes production UI changes; this skill does not implement them.

Treat common AI-generated visual patterns as diagnostic clues only. A pattern becomes a finding only when evidence connects it to task clarity, hierarchy, trust, accessibility, responsiveness, or another product outcome.