Journey-first

Given both contracts, testing the visual matters less than testing the user journey.

This is the most easily misread claim on the site, so it is worth stating what it is not. It is not “screenshots are useless”. It is not “design does not matter”. It is a claim about where the remaining risk is, once two specific things are already true.

The contracts do not reduce the total risk. They move it — out of the pixels, which are now decided in one place, and into the composition, which is still decided per screen.

The argument

Premise one. The design system is enforced. Colours, type, spacing and states come from tokens; raw values fail a lint rule; contrast is checked per role pairing. So a screen cannot be visually wrong in the ways screens are usually visually wrong.

Premise two. The component library is enforced. Every component has a story per state, interaction tests against those stories, and an accessibility scan per story. So a component cannot be behaviourally wrong in isolation without something failing.

Therefore. What remains untested is not how any single thing looks — that is decided once and checked centrally — but whether the assembly works for a person: whether the steps are in a survivable order, whether the error someone actually hits tells them what to do, whether the thing they need next is reachable from where they are.

That is a property of the journey, and no amount of pixel comparison can observe it. A screenshot suite is perfectly happy with a beautiful screen that dead-ends.

What each level can and cannot tell you

Level	Answers	Cannot answer	Cost of a false alarm
Interaction tests	Does this component behave as specified?	Is it the right component here?	Low — the failure has an address
Visual regression	Did something change that nobody meant to change?	Is the change wrong?	High — every intended change is a diff someone must triage
Accessibility scans	Are the mechanical guarantees intact?	Is it usable by a person with a disability?	Low
Journey tests	Can a person get from intent to outcome?	Which line of code broke	Medium — but the failure is the one that matters
Usability testing	Does a real person, who did not build it, get through?	Anything statistical	None — a finding is never a false alarm

The fourth column is the part that decides real-world behaviour. A visual regression suite is a change detector, not a correctness oracle: it reports that pixels moved, and a human decides whether that was intended. Once the design system is enforced, most of what it reports is intended — a token changed and three hundred snapshots moved with it.

That is how large screenshot suites die. Not from a decision, but from a slow accumulation of triage nobody has time for, until “approve all” becomes the ritual and the suite is decorative. Keeping it small is what keeps it honest.

What this changes in practice

• Budget by journey, not by screen. Name the five or ten journeys the product exists for and test those end to end. A journey nobody named is a journey nobody owns.
• Put a person on the journey too. Automation proves a path is passable; usability testing is the only instrument that says whether anyone follows it. Five participants, several times a year.
• Snapshot components, not pages. A component snapshot has one owner and a small diff. A full-page snapshot changes whenever anything on the page changes, which is constantly.
• Let the failure carry an address. Interaction tests fail at a component; journey tests fail at a step. Between them, “the checkout page looks different” is the least useful sentence a suite can produce.
• Review the design, do not diff it. Design correctness is a critique question answered by a person looking at the real thing, not by a tolerance threshold.

When this claim is false

It is conditional, and the conditions fail often. Be honest about which case you are in.

The contracts are not enforced. If tokens are copied by hand and components are forked per screen, the pixels really are risky and the screenshots really are load-bearing. Fix the cause; the test suite is treating a symptom, expensively.

The visual is the product. A charting library, a design tool, a document renderer, a game — for these, rendering fidelity is the behaviour, not a presentation of it. Visual testing is functional testing here, and this whole argument is off-topic.

Brand compliance is contractual in the legal sense. Regulated disclosures, licensed marks, mandated layouts. Then a visual check is evidence for an obligation, and it is worth its cost for reasons that have nothing to do with finding bugs.

You are mid-migration. Rewriting a design system, changing a framework, re-theming — a broad snapshot net is the right temporary instrument for a change whose blast radius you cannot predict. Delete it when the migration lands, and put a date on that deletion, because this is the net that most often becomes permanent by accident.

Where it connects

• Testing works the budget out level by level.
• Journey tests is how the top level is written.
• Visual regression is the demoted level, described in its own terms rather than dismissed.
• Usability testing is the level above the automation, and the one this attitude is ultimately serving.
• Contract-first is the premise this whole attitude rests on. Without it the argument does not run.