Visual release review: from screenshots to useful decisions

Most release review still happens as a folder of screenshots, a Slack thread, or a screen-share: someone looks at what changed, types a reaction, and the context evaporates by the next release. None of that is wrong, exactly — it's just not continuous. The feedback doesn't stay attached to the version it was about, and the next release doesn't know what the last round of review decided.

The useful unit isn't "a screenshot." It's a screen state, from a known release, with enough context to make a decision.

Start with a small review contract

Before collecting images, write down the decision the review supports. "Look at the app" is too broad. A practical contract names the release, the environment, the screen states in scope, the reviewer, and what's explicitly excluded. For example:

Review the invite form, validation message, pending invitation, and accepted-invitation screen in a synthetic workspace, at one declared desktop viewport and one declared mobile viewport. Review layout and wording. Email delivery and server authorization are outside this visual review and need separate checks.

That's an illustrative contract, not a report of a review UIProof ran — a stated intention to capture four states isn't evidence that four states were captured. Keep missing, blocked, and skipped states visible in the scope, too: three available images and one missing one is partial coverage, not four checks.

Give each screen a stable identity

Filenames like final-new-2.png make comparison impossible. A useful identity names the app or board, the route, the state, and the relevant role — invitations / pending / administrator can stay the same logical screen across releases even as its 390×844 and 1440×900 captures change. This is exactly what a private board is built around: each release keeps its own immutable record of evidence and a separate record of what was in scope to check, so a changed screenshot and a changed agreement about what to check are never confused with each other.

Judge the state, then classify it

A changed image doesn't automatically mean a defect — a correct new feature, different fixture data, or a different rendering environment can all change what's on screen. Playwright's own visual-comparison docs specifically warn that screenshots can vary with OS, browser, and fonts, so keep comparable captures in a controlled environment when the comparison matters. For each state, classify the observation in plain language: intended change, needs clarification, possible defect, or not enough evidence — a visual concern shouldn't become a functional-failure claim just because it looks serious.

Write feedback someone can act on

"Mobile is broken" creates another round of questions instead of a fix. A useful observation names: the release and screen, what was observed, what was expected, the affected scope, supporting evidence, and what a recheck would need to look at. Consider this hypothetical:

On the pending-invitation screen in release R2 at 390×844, the primary action extends beyond the captured viewport. Expected: the action stays fully visible without horizontal scrolling. Recheck the same state at this width and the adjacent supported widths. This observation does not establish whether invitation delivery works.

Attach feedback to a screen and a version, and invite reviewers with scoped roles instead of a shared inbox. Public-view comments from non-collaborators or viewer-role collaborators require owner approval before appearing publicly. Owner, editor, and commenter feedback is approved immediately. Viewer invitations do not permit private comments. Don't mark something "fixed" because a developer says it is — record the patch claim separately from the recheck result.

A supplied commit is an assertion, not a proof

A recorded commit value needs an honest label too: a supplied commit identifier is an assertion about origin unless a trusted process verifies it. A digest helps identify an artifact — it doesn't prove the application behind it is correct.

Share the smallest useful packet

Before publishing, review the actual images and labels — not just the board title — and keep working notes private. UIProof supports publishing a specific release or screen to a review link when you're ready, while private collaborator notes stay private even after publishing. Revoking a link denies new access, but can't retrieve copies someone already downloaded or that a third-party service has cached.

Recheck against an explicit expectation

The next release should answer the original feedback: the same logical state, the same declared environment, fresh evidence, and the expected outcome. A new screenshot can demonstrate the corrected layout at that state and viewport — it can't establish unrelated behavior. When behavior matters, attach the result of a separately defined assertion; "the button is visible" and "the server rejected an unauthorized action" are different claims with different evidence requirements.

See it worked through

Three specific, executed, reproducible synthetic fixtures make this concrete:

• A mobile card that clips its own action button — invisible on desktop, invisible in a design tool, and only visible at a real mobile viewport with a full member list.
• A zero-data state that doesn't say what "zero" means — a blank box is consistent with "no data yet," "still loading," and "the request failed."
• One long label evicting a whole nav item — a nav bar only ever tested with short labels can look correct for a product's entire life.

Each page shows the actual before/after screenshots from that one executed run, the exact assertion that was checked, and what it deliberately doesn't prove — an inspectable receipt, not a claim.

Make it a habit, not a one-off

The discipline behind all of this — what counts as "captured," "reported," or "reviewed" — is written out on the evidence levels page. The practical version is the release-review checklist, which works whether or not you use UIProof for it.

Want to see the loop before running it on your own app? Explore the synthetic example, or create a private board and bring your own release.

Sources and limitations

Playwright, "Visual comparisons": playwright.dev/docs/test-snapshots. See also product status and evidence levels. This is a review method, not a comprehensive test strategy or certification standard — the invitation example above is hypothetical, and no customer results or time-saving measurements are claimed.