# What is UI review?

> UI review is product experience review for UI-affecting GitHub PRs on web apps. Exercise the running product, find aberrations with evidence, and catch failures source review misses.

Canonical: https://www.diffraction.sh/ui-review

## TL;DR

UI review (also called product experience review) is the practice of checking whether a UI-affecting change actually works as a product for a user, not only whether the code looks correct.

For teams shipping web apps via GitHub, that means reviewing the PR head as a running experience: flows, states, copy, defaults, and edge cases that source-only review and pixel baselines often miss.

Diffraction is designed to surface verified aberrations with evidence and will, when live, support agent‑assisted UI review.

Explore Diffraction on GitHub: https://github.com/Diffraction-AI

## Quotable definitions

UI review: evaluating a UI-affecting change by experiencing the running product, not only by reading source or comparing screenshots.

Product experience review: UI review focused on whether real user flows behave correctly after a change: navigation, forms, defaults, empty states, errors, and the path from intent to outcome.

Aberration: a verified product-experience failure found while reviewing a running UI: something a user would hit that source correctness alone did not catch.

## Why source correctness is not product correctness

Most PR review is still source-shaped. Someone reads the diff, maybe glances at a preview link, and merges. That works until the failure lives one layer above the code: a silent default, a login wall in the wrong place, a signup path that technically renders and practically fails.

Thesis: source correctness ≠ product correctness. You can ship green checks and still ship a broken product.

Examples:

https://diffraction.sh/blog/three-checkboxes-almost-billion-dollars

https://diffraction.sh/blog/six-people-national-signup-flow

https://diffraction.sh/blog/button-costing-300-million-a-year

## What UI review actually covers

- Does the primary flow still complete for a cold user?

- Are defaults safe, or do they invite expensive mistakes?

- Do empty, loading, and error states tell the truth?

- Did copy, disabled states, or conditional UI change the path without changing the intent?

- Would a careful human notice this only after merge, when the blast radius is real?

UI review is not a vibes pass on a screenshot. It is product experience review of the running change.

## How UI review differs from adjacent categories

Source-only PR bots summarise code and comment on diffs. Useful for review speed. Weak at whether the product works when clicked.

Visual testing / pixel baselines catch unintended visual drift. Useful for layout regressions. Weak at flow failures, logic in the UI, and correct pixels with wrong product.

UI review / product experience review exercises the running experience and looks for aberrations: verified failures with evidence that a user would hit.

Longer comparison: https://diffraction.sh/ui-review-vs-visual-testing

Definitions: https://diffraction.sh/glossary

## Where it fits in a GitHub PR workflow

1. A PR changes UI, flows, or product behaviour.

2. Someone (or something) reviews the PR head as a running app, not only as a diff.

3. Findings are concrete: repro path, evidence, severity, not "LGTM from the screenshot."

4. Reviewers decide with product truth in hand, not only with source confidence.

Diffraction is designed to provide agent‑assisted browser review of PR heads and will, when live, report verified aberrations with evidence, a score, and a hosted viewer. Tagline: See the full spectrum of every diff.

Explore our open-source projects: https://github.com/Diffraction-AI, or email hello@diffraction.sh.

## Who owns UI review today

Design reviews mocks. Eng reviews code. QA samples a path if the ticket says so. Nobody systematically owns “did this PR change the product experience in a bad way?”

Eng leads, platform, and product engineering feel the pain first. UI review names the practice without pretending pixel baselines or LLM PR summaries already closed the gap.

Role-specific framing: https://diffraction.sh/for/executives, https://diffraction.sh/for/designers-and-qa, https://diffraction.sh/for/engineers, https://diffraction.sh/for/engineering-leads

## What good UI review evidence looks like

- Steps to reproduce on the PR head

- What the user sees or cannot do

- Why it matters (wrong default, blocked flow, misleading state)

- Evidence (recording, DOM trail, screenshot sequence as support, not as the whole claim)

That is an aberration: verified, actionable, tied to product experience.