The distinction
UI review vs visual testing
Code, pixels, and product behavior each tell you something different. Know what you’re reviewing.
A closer look
Different questions. Complementary evidence.
Code checks structure
Pixels reveal differences
UI review follows behavior
At a glance
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 building in the third category. When live, it is designed to find aberrations: verified product‑experience failures with evidence. We are not a visual testing tool, and we are not a source‑only PR comment bot. Adjacent practices are useful for what they cover. They do not replace experiencing the product. Start here for the category: What is UI review?. Definitions: glossary.
| Approach | The question | The evidence |
|---|---|---|
| Code review | Is the implementation sound? | Source, contracts, and tests |
| Visual testing | Did the appearance change? | Baseline and current screenshots |
| UI review | Can the user still complete the task? | Browser steps, states, and recordings |
A shared vocabulary
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: Pixel baselines can pass when the UI looks right and still fail the user: wrong defaults, broken flows, misleading copy, and logic errors often leave screenshots looking fine.
Aberration (Diffraction): An aberration is 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.
What visual testing / pixel baselines do well
Pixel baselines earn their keep. If a deploy accidentally nukes spacing, theme tokens, or a critical component's layout, a visual regression suite can catch it. That lane is strong at intended look vs actual look: unintended visual drift, layout regressions, and “this screen no longer matches the approved baseline.”
Teams that invest in stable baselines get a real signal on cosmetic and layout risk without asking a human to eyeball every PR. That is a clear, valuable job.
Where pixel baselines stop
- The screen looks right and the path is wrong
- A default is silently dangerous
- A button is present but the post‑click flow fails later
- Copy, permissions, or conditional UI change outcomes without a dramatic visual delta
- The failure is “user cannot complete the job,” not “two pixels shifted”
That gap is why Diffraction does not claim visual testing as our category. We discuss it as an adjacent practice we are not. UI review / product experience review starts where lookalike screenshots stop being enough.
What source‑only PR review does well
LLM and rule‑based PR reviewers that stay in the diff can speed human review. They are good at spotting risky patterns in source, naming style and structure issues, and keeping review throughput up when the change is mostly code‑shaped. If your stack already uses source‑oriented PR assistants, keep them for that job.
Where source‑only review stops
They do not experience the product. A bot can praise a clean component refactor while the PR head still breaks signup on mobile Safari. Code smell ≠ product smell.
Product failures that look “fine” in pixels and source
Citibank / Flexcube silent defaults: interface defaults and confirmations that invited catastrophe.
HealthCare.gov launch: a national signup flow that functionally failed at scale.
The button costing $300 million a year: a login wall that blocked purchases.
Thesis again: source correctness ≠ product correctness. Pixel sameness ≠ product correctness either.
What Diffraction means by aberrations
In Diffraction language, an aberration is a verified product‑experience failure found against a running UI, with evidence a reviewer can trust. Not a vibe. Not an unconfirmed LLM guess. Not “this screenshot looks 3% different.”
UI review is the practice. Aberrations are the findings. Product experience review is the framing for eng leads who care about shipping web apps via GitHub without discovering the bug in production analytics. More on terms: glossary. Category explainer: UI review.
How to choose (without a tool holy war)
Use visual testing when your risk is unintended visual drift and you have stable baselines. It is strong at look vs baseline.
Use source‑only PR review when your risk is code quality and review throughput. It is strong at diff‑shaped risk.
Use UI review when your risk is “users cannot complete the job after this PR,” including defaults, flows, and states that screenshots and diffs under‑sample.
Many teams will want more than one. The mistake is assuming one adjacent category already covers product experience.
Where Diffraction fits
Diffraction is aimed at UI review for UI‑affecting GitHub PRs on web apps. When live, it is designed to exercise the PR head with agent‑driven browser review and return verified aberrations with evidence. Tagline: See the full spectrum of every diff. Explore our projects on GitHub or email hello@diffraction.sh.
From a diff.
To a clearer picture.
Explore a checkout review in the actual Diffraction viewer.
Explore the example