ui-review

# UI Review Review any concrete UI target without requiring project context files, a detector, persistence, or a larger workflow. ## Resolve the target Identify the exact surface: URL, screenshot, route, component, source path, or flow. Narrow vague requests to the smallest useful target and state the chosen scope. Use the strongest available evidence: - inspect the rendered interface when it is available; - exercise the primary path rather than judging a still frame alone; - inspect relevant source and shared conventions when code is available; - evaluate representative desktop, intermediate, and mobile sizes; - distinguish observed behavior from inference. Do not start a server, install tooling, or mutate a browser session unless the user authorized that operation. ## Run two passes Keep the first pass independent of mechanical findings so lint-like output does not anchor visual judgment. When permitted and useful, separate agents may run the two passes in parallel using self-contained context. They are not required. Without them, complete and record Pass A before beginning Pass B. Independence of judgment matters; dependence on a particular orchestration tool does not. ### Pass A: experience and design Evaluate: - product specificity versus category-interchangeable design; - primary task, reading order, hierarchy, and information architecture; - discoverability, feedback, control, consistency, and recovery; - typography, color, layout, density, imagery, and motion; - cognitive load and decision complexity; - emotional fit and high-stakes moments; - loading, empty, error, success, disabled, and permission states; - relevant user perspectives. Read `references/experience-rubric.md` for the complete heuristic, cognitive-load, persona, and severity rubrics. For a full review, score all applicable Nielsen heuristics from 0–4, mark truly inapplicable items `n/a`, and calculate the result against the applicable maximum. ### Pass B: implementation evidence Evaluate only what the available evidence supports: - accessibility; - responsive behavior and input methods; - theming and token consistency; - performance risks; - implementation integrity and repeated shortcuts. Read `references/technical-rubric.md` for the technical dimensions and scoring anchors. For a full web review with source or runtime evidence, score the five applicable technical dimensions from 0–4. For a screenshot-only or deliberately scoped review, mark dimensions that cannot be verified `not assessed`; do not guess scores. Use existing project checks when they are already available and relevant. Automated findings are evidence to verify, not proof. Do not require or install a proprietary detector. ## Synthesize Do not concatenate two reports. Explain: - where visual judgment and technical evidence agree; - which issues are visible only in behavior or source; - which automated findings are false positives or uncertain; - which strengths should be preserved. Prioritize by user impact, frequency, reach, and remediation cost. A short list of high-confidence problems is better than padded output. ## Output For a full review, use this structure: 1. **Method and evidence**: target, rendered states, source, checks, and limitations. 2. **Experience health**: Nielsen table, total against applicable maximum, cognitive-load result, and product-specificity verdict. 3. **Technical health**: five-dimension table and total against applicable maximum. 4. **Overall verdict**: clearest judgment and largest opportunity. 5. **What works**: two to four specific strengths worth preserving. 6. **Priority findings**: three to seven issues ordered by severity. 7. **Persona red flags**: exact failures from two or three relevant perspectives. 8. **Systemic patterns**: recurring causes rather than isolated symptoms. 9. **Recommended actions**: ordered, concrete next steps. 10. **Evidence limits**: what could not be verified and any assumptions. For a scoped review, include only applicable sections, but keep the same finding format and evidence standards. For each finding include: - **Severity**: P0, P1, P2, or P3; - **Evidence**: element, state, behavior, file, or line; - **Impact**: the user harm or product cost; - **Recommendation**: a specific correction; - **Confidence**: include only when evidence is incomplete. Do not combine the experience and technical totals into a false universal score. Mark inapplicable items `n/a`, mark unverified dimensions `not assessed`, and adjust each denominator. Never inflate a score to be polite. ## Boundaries - Remain read-only unless implementation was explicitly requested. - Do not create report history, hidden state, or project files unless asked. - Do not require `PRODUCT.md`, `DESIGN.md`, subagents, browser injection, or a detector. - Use context documents when present, but treat the rendered product and code as evidence too. - Do not report generic advice without tying it to the target. - Do not report an issue without explaining why it matters. - Do not call a visual preference an accessibility or correctness defect.