# UI review vs visual testing

> UI review checks the running product experience on GitHub PRs. Visual testing catches pixel baseline drift. Source-only PR bots review code. Why those miss product failures Diffraction calls aberrations.

Canonical: https://www.diffraction.sh/ui-review-vs-visual-testing

## TL;DR

Visual testing (pixel baselines) asks: did the pixels change vs a known good screenshot?

Source-only PR bots ask: does the diff look risky in code?

UI review / product experience review asks: does the running product still work for a user after this PR?

Diffraction is designed for the third category and will, when live, surface aberrations with evidence.

Start here: https://diffraction.sh/ui-review — Definitions: https://diffraction.sh/glossary

## Quotable definitions

UI review vs visual testing: UI review evaluates whether a running product experience still works after a change; visual testing evaluates whether rendered pixels drifted from a baseline.

Why pixel baselines miss product failures: pixels can pass when the UI looks right and still fails the user (defaults, flows, copy, UI logic).

Aberration: a verified product-experience failure found while reviewing a running UI, not a pixel delta alone.

## Three jobs people confuse

Source-only PR bots — catches: style/patterns; misses: runtime flows and UX traps.

Visual testing / pixel baselines — catches: unintended layout/visual drift; misses: correct-looking wrong product behaviour.

UI review / product experience review — catches: flow breaks, bad defaults, state lies; ignores: purely aesthetic pixel noise.

## Visual testing is useful. It is a different job.

Pixel baselines help when deploys nuke spacing, theme tokens, or a critical component’s layout. They are good at intended look vs actual look.

They are weaker when the screen looks right and the path is wrong; a default is silently dangerous; or the failure is “user cannot complete the job,” not “two pixels shifted.”

This is why Diffraction does not claim visual testing as our category.

## Source-only PR bots are useful. Also a different job.

LLM PR reviewers speed human review but do not experience the product. Code smell ≠ product smell.

## Product failures that look fine in pixels and source

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

Thesis: source correctness ≠ product correctness. Pixel sameness ≠ product correctness either.

## What Diffraction means by aberrations

An aberration is a verified product-experience failure found against a running UI, with evidence a reviewer can trust.

UI review is the practice. Aberrations are the findings. More on terms: https://diffraction.sh/glossary

## How to choose

Use visual testing when your risk is unintended visual drift and you have stable baselines.

Use source-only PR review when your risk is code quality and review throughput.

Use UI review when your risk is users cannot complete the job after this PR, including defaults, flows, and states screenshots and diffs under-sample.

## Soft product bridge

Diffraction is designed for UI review of UI‑affecting GitHub PRs on web apps. Explore our projects on GitHub or email hello@diffraction.sh.