A website before-and-after report is a compact evidence package. It should let someone who was not in the implementation thread understand what was reviewed, under which conditions, and what conclusion the reviewer reached. The screenshots are central, but the context around them is what makes the report reusable.
1. Define the decision the report should support
Start with one sentence that names the page, change, and decision. For example: “Confirm that the July pricing-page release matches the approved desktop design and does not alter the purchase CTA.” This keeps the report from becoming a gallery of loosely related observations.
Common report purposes include:
- release QA for a known UI change;
- client approval of a design revision;
- handoff evidence between an agency and an internal team;
- documentation of a CMS or dependency update;
- a visual regression attached to a bug report.
One report can contain several findings, but it should have one owner and one requested decision. Split unrelated routes or approval questions into separate reports.
2. Collect the minimum credible evidence
Capture the images using the same route, viewport, zoom, content, and state. The screenshot comparison guideexplains the full setup. Alongside the files, record:
- page or feature name;
- baseline and changed version identifiers, if available;
- capture date;
- viewport width and height;
- signed-in state, test data, locale, and feature flags that matter;
- known dynamic regions that were ignored;
- the person or team responsible for the decision.
3. Use a five-part report structure
A. Scope
Name the page, version, viewport, user state, and intended change. Add a one-line exclusion for anything a reader might reasonably assume was tested but was not.
B. Before and after
Show both source images at a readable scale. Keep the labels unambiguous and use the same crop. A slider is useful for exploration, but a static side-by-side view is easier to preserve in a ticket or PDF.
C. Difference view
Include the visual diff and the sensitivity used. The difference view is an index of where to look. It should not replace the source images.
D. Findings
Number each meaningful region and classify it as expected, unexpected, or environmental. Describe visible impact before implementation theory. “The tax label wraps and moves the total down 18 pixels” is more useful than “CSS is broken.”
E. Decision and next action
End with a status such as approved, approved with follow-up, changes requested, or inconclusive. Add an owner and a concrete next step for unresolved findings.
Worked example: pricing-page release
A software company updates the annual-plan card and asks its agency to confirm the change. The report uses the following scope: public pricing page, English locale, desktop viewport 1440 × 900, signed out, static sample prices, Chrome browser. Mobile and the checkout flow are excluded.
| Finding | Observation | Assessment | Action |
|---|---|---|---|
| 01 | Annual badge changed from gray to blue | Expected, matches approved mockup | Accept |
| 02 | CTA label changed from “Start” to “Start annual plan” | Expected copy update | Accept |
| 03 | Feature list begins 12 pixels lower on the changed card | Unexpected spacing drift | Designer to confirm before approval |
| 04 | Customer-logo carousel shows different brands | Environmental, rotating content | Exclude and retest with carousel paused |
The report status is “changes requested” because finding 03 affects the approved alignment. Findings 01 and 02 do not need to be revisited. This is more actionable than a red diff image with no classification.
Write findings a future reader can verify
Use a simple pattern: location, observation, impact, action.
Location: Checkout summary, tax row.
Observation: The label wraps to two lines at the tested desktop viewport and moves the total below the card fold.
Impact: The total is no longer visible with the payment button in the initial viewport.
Action: Shorten the label or preserve the previous label width, then recapture this state.
Avoid certainty that the evidence cannot support. Write “visible in this 1440-pixel capture” instead of “broken on desktop.” Use “no visible difference detected in the reviewed area” instead of “nothing changed.”
State limitations and handle screenshots carefully
A report based on one pair of images covers one rendered state. Record untested viewports, themes, locales, browsers, and interactions. If the page contains video, live data, randomized modules, or third-party widgets, note how those regions were controlled or excluded.
Screenshots may contain names, email addresses, customer records, account balances, internal URLs, or unreleased product information. Use test data where possible and crop or redact unrelated information before sharing. SiteReceipt processes selected images in the browser, but the report you export or paste into another service is then governed by how that service handles files. Read the SiteReceipt privacy noticefor current details.
Frequently asked questions
How long should a before-and-after report be?
Keep it as short as the decision allows. One stable page state may need a single screen and three findings. A multi-viewport release needs more evidence. Remove implementation history that does not help the reader verify or decide.
Should every highlighted pixel become a finding?
No. Group related pixels by visible cause. A shifted heading can move an entire section, and a rotating banner can create thousands of differences that belong to one environmental note.
Can I report “no change”?
Prefer “no visible difference detected under the recorded conditions.” That wording respects the limited viewport, state, and sensitivity of the comparison.
Who should approve the report?
The person responsible for the requirement should approve expected changes. A developer can confirm implementation details, while a designer, product owner, or client may own the visual decision.