What is UI review?

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 building toward agent‑driven UI review designed to find verified aberrations with evidence when live. See the full spectrum.

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

Product experience review: Product experience review is 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: An aberration is a verified product‑experience failure found while reviewing a running UI: something a user would hit that source correctness alone did not catch.

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.

The thesis is blunt: source correctness ≠ product correctness. You can ship green checks and still ship a broken product. Three public cautionary tales make the point:

Three checkboxes almost cost a billion dollars (Citibank Flexcube silent defaults)

Six people and a national signup flow (HealthCare.gov launch)

The button costing $300 million a year (Jared Spool / login wall)

• 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.

1. Source‑only PR bots summarise code and comment on diffs. Useful for review speed. Weak at whether the product works when clicked.
2. Visual testing / pixel baselines catch unintended visual drift against a baseline. Useful for layout regressions. Weak at flow failures, logic in the UI, and “correct pixels, wrong product.”
3. UI review / product experience review exercises the running experience and looks for aberrations: verified failures with evidence that a user would hit.

Longer comparison: UI review vs visual testing. Short definitions: glossary.

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.

That is the job Diffraction is aimed at: when live, agent‑driven browser review of PR heads designed to return verified aberrations with evidence a reviewer can trust. Tagline: See the full spectrum of every diff.

Explore our open-source projects on GitHub or email hello@diffraction.sh.

In most orgs, ownership is foggy. 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 usually feel the pain first: merge velocity is high, UI surface area is large, and post‑merge bugs are expensive. UI review is a way to put a named practice on that gap without pretending pixel baselines or LLM PR summaries already closed it. Role-specific framing: executives, designers and QA, engineers, and engineering leads.

• 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. See aberration.

Diffraction is building UI review for UI‑affecting GitHub PRs on web apps. The product is designed to exercise the PR head in a browser, run agent‑driven review, and return verified aberrations with evidence when live. Explore our projects on GitHub or email hello@diffraction.sh.