How to Create a Before-and-After Website Redesign Presentation with Screenshots

A useful before-and-after redesign presentation makes it easy to see what changed, why it changed, and what evidence supports the result. Capture the same pages under the same conditions, label each state, explain the key design decisions, and report measured outcomes separately from what the screenshots show.

This guide covers planning, capturing, comparing, annotating, and presenting the evidence. It also includes practical browser-automation code for repeatable screenshots. A static screenshot documents appearance at a particular moment; it does not by itself prove that a page is accessible, fast, or usable with a keyboard or touch.

1. Decide what the presentation needs to do

Start by writing down the decision the audience should make. A client review may ask for approval of a design direction. A project retrospective may record completed work and remaining measurement. A portfolio case study may explain the problem, decisions, and evidence to prospective clients.

State the redesign goal before collecting results. Examples include making the primary task easier to find, improving the navigation path, or addressing a mobile layout problem. If the goal concerns business or user outcomes, identify the baseline and the measure you will use after launch. HubSpot’s redesign checklist recommends setting goals and metrics before work, protecting marketing assets during a redesign, and measuring against the goals afterward: website redesign checklist.

Keep three kinds of statements distinct:

Observed visual change: “The main action is now above the fold at this viewport.”
Tested behavior: “Keyboard testing confirmed that the menu can be opened and navigated.” Name the test or evidence.
Measured outcome: “The completion rate changed from the baseline to the post-launch value over the stated period.” Include the source and measurement window.

A redesigned appearance is not evidence by itself that conversion, revenue, accessibility, or performance improved.

2. Preserve the original before it changes

Capture the existing site before launch, migration, or content changes make the old state unavailable. For each capture, keep a small record alongside the image:

Original URL and, if relevant, the route or query parameters.
Capture date and time, including timezone if timing matters.
Viewport width and height, browser zoom, and device pixel ratio.
Page state: logged-in or logged-out, selected tab, open menu, consent choice, or other relevant interaction.
Whether the image shows the initial viewport, a full page, or a focused component.
Any known limitation, such as a blocked asset or personalized content.

Keep untouched originals in a read-only archive. Make working copies for crops, callouts, or redaction so annotations never obscure the evidence. If a site includes private user information, capture a safe test state or redact it in a working copy before sharing.

3. Choose screenshots that answer a question

Use the view that supports the point you are making. W3C WAI recommends designing for different viewport sizes; include relevant responsive states when layout behavior is part of the redesign: WAI tips for designing for different viewport sizes.

Capture	Best for	Watch for
Initial viewport	First impression, hierarchy, headline, navigation, and primary action visibility.	It does not show content below the fold or behavior after interaction.
Full page	Page structure, section order, repeated patterns, and content length.	Very tall images can be difficult to read on a slide. Pair them with focused crops.
Focused component or crop	A specific menu, form, card, pricing block, or other decision.	Keep enough surrounding context that the component’s location and purpose remain clear.
Mobile or tablet viewport	Responsive navigation, content reflow, touch targets, and mobile-specific hierarchy.	Use the same viewport dimensions and page state for before and after.
Interaction state	An open menu, validation message, expanded panel, or other state that matters.	Record how the state was reached; a still image does not prove that the control works.

Choose a small, representative set that covers the decisions and important states. There is no universally correct number of screenshots: use enough to make the case understandable without forcing the audience to inspect every page.

4. Capture before and after under matching conditions

Keep the comparison fair. For each before-and-after pair, use the same URL when possible, viewport dimensions, zoom, device scale, scroll position or full-page boundary, and page state. Use the same browser and capture method when practical. If a route or state has changed, say so and explain the difference rather than presenting the pair as directly equivalent.

Wait for fonts, images, and dynamic content to settle. Carousels, timestamps, ads, personalization, lazy-loaded media, and animations can change the apparent layout or capture at different moments. Disable or pause motion when it is not part of the point being evaluated. Capture important interactive states deliberately and record the steps used to reach them.

For repeatable browser captures, Playwright can set a viewport, navigate to a URL, wait for a page condition, and save a screenshot. Install it with npm install -D playwright and install a browser with npx playwright install chromium. Save the following as capture.mjs, set TARGET_URL, and run TARGET_URL=https://example.com node capture.mjs:

import { chromium } from 'playwright';

const url = process.env.TARGET_URL;
if (!url) throw new Error('Set TARGET_URL to the page to capture');

const browser = await chromium.launch({ headless: true });
try {
  const page = await browser.newPage({
    viewport: { width: 1440, height: 1000 },
    deviceScaleFactor: 1,
  });
  await page.goto(url, { waitUntil: 'networkidle', timeout: 60000 });
  await page.screenshot({ path: 'page.png', fullPage: true });
} finally {
  await browser.close();
}

networkidle is a useful starting point, but it is not a universal sign that a page is ready: analytics, streaming requests, or long polling may keep the network active. If that happens, wait for a meaningful selector or a known page-specific readiness condition instead. For content below the fold, full-page capture may trigger lazy loading differently from normal browsing; verify that the resulting image includes the expected content.

5. Build a comparison people can scan

For each example, show the before and after side by side when space allows. Put “Before” and “After” labels close to the images, and include the page name and viewport. Keep image dimensions or display scale consistent within a pair. A controlled reveal can help viewers inspect small differences, but it should not replace plainly labeled states in a slide deck or exported document.

Choose comparison axes that match the stated goal:

Content hierarchy and clarity of the primary message.
Navigation structure and path to a task.
Visibility and context of a call to action.
Page structure, content grouping, and scanning order.
Responsive behavior at specified viewport widths.
A specific accessibility repair, supported by separate evaluation evidence.

Do not compare different pages, page states, or viewport sizes without making that difference visible. A mismatched comparison can exaggerate or hide the redesign. For long pages, show a readable overview plus focused, same-scale crops of the relevant sections.

6. Annotate decisions, not decoration

Use annotations sparingly. A concise callout should connect the visible change to a reason: what changed, what evidence or constraint informed it, and which goal it serves. For example: “Moved delivery details next to the price after support feedback showed shoppers looked for shipping cost before adding an item.” Use that wording only if the feedback actually exists.

Give each major decision a short explanation near its screenshot or in a consistent caption. Avoid covering important content with callouts. Use a legend if colors or symbols carry meaning, and do not rely on color alone to distinguish before from after. The W3C WAI accessibility demonstration pairs before-and-after examples and annotations with evaluation reports; it also notes that its examples illustrate selected barriers and repairs rather than every accessibility requirement: WAI before-and-after accessibility demonstration.

A vendor presentation template is one possible way to order titled screens and attach notes to screenshot points, but the presentation software is an implementation choice, not evidence that a redesign succeeded: i3Dify presentation example.

7. Validate claims that screenshots cannot establish

A screenshot is a static record of appearance at one moment. It cannot establish that controls work, keyboard focus is usable, a screen reader receives meaningful names, a page loads quickly, or a touch interaction behaves correctly. If the presentation makes those claims, show the relevant test results separately and identify the method, conditions, and date.

For accessibility claims, use an appropriate evaluation process and report what was checked. For performance claims, use a repeatable measurement with comparable conditions. For business results, compare post-launch measurements with the recorded baseline and state the time period. If data is not available yet, say measurement is pending. W3C’s demonstration is explicit that its selected examples do not cover every barrier or requirement: WAI demonstration scope.

8. Use a clear slide sequence

Opening: project, audience or business context, and purpose of the review.
Goals and baseline: the problem addressed and the measures selected before redesign.
Before: dated original captures with page and device labels.
Design decisions: a few annotated examples tied to user needs, evidence, or constraints.
After: corresponding views captured under the same conditions.
Comparison: side-by-side or reveal comparisons with concise explanations.
Validation and outcomes: what was tested, what results are measured, and what remains unmeasured.
Decision or next step: the approval, feedback, follow-up work, or portfolio takeaway requested.

This is a practical sequence, not a formal standard. Adjust it to the decision and the changes that need explanation.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request can capture a URL as an image; see the ScreenshotNeo API documentation for the request options and formats. Replace the example URL and API key with your own:

cURL

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

Use the same URL, viewport, and relevant page state for both sides of a comparison. ScreenshotNeo can capture full pages, a selected element, device or custom viewport sizes, and other states; each capture still represents a point in time, so record the conditions with the image.

Cookie and consent banners are accepted as a visitor and more than 60 known consent platforms, newsletter popups, and chat widgets are removed before capture; each step can be turned off. Bot checks and CAPTCHAs, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 shots per month without a card; paid plans start at $5 for 3,000 shots.

Troubleshooting screenshot comparisons

Symptom	Likely cause	Fix
Before and after appear to have different scale	Viewport, zoom, device scale, or slide image sizing differs.	Record and match capture dimensions and display both images at the same scale.
Fonts or images are missing	Capture occurred before resources loaded, or a remote resource failed.	Wait for the specific font or image, inspect the browser console/network errors, then recapture. Note any resource that remains unavailable.
Full-page image omits lazy-loaded content	Content loads only after scrolling or entering the viewport.	Scroll through the page before capture or use the capture tool’s full-page/lazy-content handling, then inspect the output.
Automated navigation times out	Long-lived network connections prevent an idle condition, or the page is slow/unreachable.	Check the URL and connectivity; wait for a specific selector or use a deliberate timeout and document when the page was captured.
Images differ because content changes between captures	Personalization, timestamps, rotating promotions, or animation.	Use a stable test state, pause motion where appropriate, and disclose unavoidable differences.
A callout makes a claim the image cannot support	Visual evidence is being used to imply behavior, accessibility, speed, or business impact.	Rephrase as an observed visual change or provide separate test/measurement evidence.
Audience cannot tell what changed	Labels, page names, viewport details, or the reason for the change are missing.	Add clear before/after labels and one short explanation tied to a goal.

Performance, reliability, and cost considerations

Browser captures consume time and compute, especially at large viewport sizes, full-page dimensions, and high device scale. Capture only the representative pages and states you need, reuse archived originals, and avoid rerunning a full set after a minor slide edit. For automated runs, set navigation and overall job timeouts, close browser contexts reliably, and retain failures with enough context to reproduce them.

Dynamic websites make exact pixel equality difficult: personalized content, external assets, font rendering, animation, and browser updates can vary. Keep capture conditions in a manifest or filename and treat screenshots as evidence of a documented state, not as a universal rendering guarantee. Never present a missing or failed capture as a blank design without verifying the page itself.

DIY browser automation has no per-shot API charge, but does require browser setup, maintenance, and execution resources. A hosted screenshot API trades that setup for a service charge and its own request limits and behavior. ScreenshotNeo’s published tiers are Free: 1,000 shots/month; Starter: $5 for 3,000; Growth: $15 for 15,000; Pro: $39 for 60,000; Scale: $99 for 250,000; Business: $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan. Confirm the current options in its documentation before building an integration around a particular request configuration.

FAQ

How many before-and-after screenshots should a presentation include?

Use as many as needed to explain the decision and representative changes. There is no evidence-based universal count; prioritize coverage and readability over volume.

Can I use a screenshot to claim the redesign improved accessibility?

A screenshot can illustrate a visible change, but it cannot establish accessibility on its own. Pair the example with a documented evaluation of the relevant requirements and interactions.

What if the old site is already gone?

Use archived captures, approved design files, or other dated records if available, and label their source and date. Do not reconstruct an old screenshot and present it as an original capture.

Should the before and after use exactly the same URL?

Use the same URL when the pages correspond. If routing or content changed, identify each route and explain the mapping so readers understand what is being compared.