---
title: "How to Update Every Screenshot After a Redesign"
canonical: https://supportpages.io/guides/update-every-screenshot-after-a-redesign
updated: 2026-08-13
---

You will finish with a ranked list of the screenshots a redesign actually broke, re-captured the ones that matter, and left the rest alone deliberately rather than by accident. The method assumes you cannot re-shoot everything, because you cannot.

## Before you start

You need a list of your published articles with traffic figures, access to the product in a state you can screenshot, and a note of roughly when the redesign shipped. Traffic data is the important one - without it you are guessing at priority, and the whole method is about priority.

## Steps

1. **Establish what the interface says now.**
   Walk your five most important flows in the product and write down the literal button labels, the order of steps, and anything that moved. This takes about an hour and becomes the reference you check every image against. Skipping it means comparing screenshots to your memory of the product, which is out of date in exactly the places you will not notice.

2. **List every article containing an image.**
   Filter your help centre by articles with images. In most help centres this is a smaller set than expected - typically the getting-started and setup articles carry the majority.

3. **Sort that list by traffic, descending.**
   Traffic in a help centre is heavily concentrated, so the top handful of articles usually account for most of what anybody reads. Those are the only ones where a wrong screenshot does real damage.

4. **Mark each image against the redesign date.**
   An image captured before the redesign is suspect. An image captured after it is probably fine. You do not need to open the article to know this - the file's date tells you.

5. **Open the top ten suspects and compare them to your reference notes.**
   For each, decide: still correct, cosmetically dated but followable, or actively wrong. Only the third category is urgent. A screenshot showing an old accent colour is cosmetically dated; one showing a button that no longer exists is wrong.

6. **Re-capture the actively wrong ones first.**
   Match your existing conventions - same browser width, same zoom, same theme, same demo account. Consistency across the set matters more than any individual image being perfect.

7. **Decide explicitly about the rest.**
   Write down which images you are choosing not to update and why. An undocumented decision to skip something is indistinguishable in six months from having forgotten it.

8. **Record the capture settings you used.**
   Browser width, zoom level, theme, account. Next time this happens, that note turns a day of archaeology into an afternoon of work.

![A two-by-two grid. Rows are high and low traffic; columns are probably wrong and probably fine. The high-traffic, probably-wrong cell is highlighted and labelled fix first.](/images/guides/figures/update-every-screenshot-after-a-redesign.webp)

*Work the top-left cell. It is smaller than you fear and it holds all the damage.*

## Common mistakes

**Starting at article one and working down.** Alphabetical or chronological order spends your first and best hours on pages nobody reads. Traffic order puts the damage first.

**Re-capturing everything for consistency.** Tempting, and it is how a one-day job becomes a one-week job that gets abandoned halfway, leaving a help centre in two visual styles - worse than the state you started in.

**Changing the capture conventions mid-pass.** If you switch browser width or theme partway through, you have created a new inconsistency while fixing an old one. Decide the settings first, write them down, do not revisit them.

**Treating cosmetic drift as urgent.** Users follow instructions, not colour palettes. An image with the old brand colour but the right buttons in the right places costs you nothing measurable.

**Forgetting images inside videos.** A walkthrough video shows the old interface for its entire duration and is far more visibly wrong than a still. If you have videos, they need their own pass.

## When this stops scaling

This method works when a redesign is a rare event and your help centre is small enough that the top ten articles really are most of the readership. Two things break it.

The first is frequency. If the interface changes materially every few weeks - a fast-moving product, or a design system being rolled out gradually - you are not doing this once, you are doing it continuously, and the manual pass never finishes before the next change starts it again.

The second is volume. Past roughly forty articles carrying images, "the top ten" stops being most of the readership, and the tail you are deliberately ignoring becomes large enough that customers notice.

At that point the arithmetic changes: maintaining a screenshot library by hand costs more than the screenshots contribute, and teams respond by quietly removing images from their documentation, which is the wrong fix.

The alternative is not to capture screenshots at all, but to render them - generating each image from the product's own interface code so that "the design changed" [triggers a re-render rather than a re-shoot](/blog/screenshots-rot-ours-regenerate). That is what [SupportPages](https://supportpages.io) does: mockups built from your repository's real stylesheet and design tokens, regenerated when the code moves. If you are on your second redesign pass this year, it is worth an afternoon of your attention.