---
title: "How to Re-record a Walkthrough After a UI Change"
canonical: https://supportpages.io/guides/re-record-a-walkthrough-after-a-ui-change
updated: 2026-08-13
---

By the time you finish you will have a list of the walkthroughs a UI change has invalidated, a rule for which of them need a full re-shoot rather than a patch, and a recording setup that matches the original closely enough that the replacement is invisible.

## Before you start

Find the original recording project: the script, the source footage, the demo account, and the export settings. If the script has gone missing, transcribe the click path from the published video before you touch anything. Transcribing four minutes of video takes ten minutes; reconstructing a flow from memory takes an afternoon and still misses a step.

Check whether the change has actually shipped to everyone. Re-recording against a feature flag that is on for staff and off for customers produces a video that is wrong for most viewers.

## Steps

1. **List every video that shows the screen that changed.**
   Search your video source files by the name of the screen, not the name of the feature. A billing redesign shows up in the onboarding walkthrough as well as the billing one.

2. **Classify the change as cosmetic, label, or flow.**
   Cosmetic is colour, spacing and iconography. Label is renamed buttons and menu items. Flow is a step that moved, merged or disappeared. The class decides the work, and nothing else does.

3. **Leave cosmetic changes alone until something else forces a re-shoot.**
   A video showing last quarter's button radius costs a viewer nothing. A video showing a button that no longer exists costs them the task.

4. **Patch a label change only when it is contained in one shot.**
   If the renamed control appears in a single continuous take with no narration over it, replace that take. If it recurs across the video or the narration says the old name aloud, re-record the segment.

5. **Recover the original capture settings before you record.**
   Browser width, zoom level, display scaling, theme, cursor size, and the export resolution. A patch recorded at a different device pixel ratio reads as a jump cut even when the framing matches.

6. **Reseed the demo account to the state the original showed.**
   Same fictional customer names, same record counts, same dates where they are visible. Mismatched demo data between two takes of the same flow is more noticeable than the interface change you are fixing.

7. **Re-record whole segments rather than seconds.**
   Cutting into the middle of a mouse movement produces a visible teleport. Start the take from the previous natural pause and end it at the next one.

8. **Re-cut the narration only for the sentences that changed.**
   If the narration was recorded in segments, this is a two-minute job. If it was recorded as one continuous take, re-record the whole thing rather than splicing - the room tone will not match.

9. **Republish at the same URL.**
   Whatever hosts the video, replace the file in place. A new URL orphans every embed, every support macro and every link somebody bookmarked.

10. **Update the subtitle file, transcript and thumbnail in the same pass.**
    All three are copies of the video's content, and all three are now stale. The transcript is the one people forget, and it is the one search engines read.

![Three video entries ranked by how visibly outdated each is, with the most-watched flagged for re-recording first.](/images/guides/figures/re-record-a-walkthrough-after-a-ui-change.webp)

*Re-record by visibility, not by age.*

## Common mistakes

**Patching at a different resolution or zoom.** The replaced shot is sharper or softer than the footage either side of it, which viewers register as a glitch without being able to name it.

**Fixing the video and leaving the captions.** The subtitles keep saying the old button name over footage showing the new one, which is worse than either version alone.

**Uploading the new take to a new URL.** Every article embed now points at the outdated version, and the article authors have no reason to notice.

**Re-recording only the video someone complained about.** The complaint is a sample, not a survey. Work the list from step one, or the same message arrives next week about a different video.

**Leaving the old thumbnail in place.** The still frame is usually taken from the screen that changed, so the preview advertises the interface you have just finished removing.

## When this stops scaling

Re-recording works while the number of videos is small enough that one person can hold the list in their head. The threshold is lower than it looks: roughly ten published walkthroughs, or any library where interface changes ship more often than monthly.

Past that point, the arithmetic turns against you. Each re-shoot costs setup, recording, narration, subtitles and transcript regardless of how small the change was, so a single renamed menu item can cost a day across a library. Videos also fail silently. Nobody files a ticket saying the walkthrough is out of date - they watch it, fail to follow it, and open a support ticket about the feature instead, which is how a stale video shows up as a product problem.

The structural fix is to [stop treating a walkthrough as footage and start treating it as output](/blog/video-walkthroughs-without-a-screen-recorder). Where the video is generated from the application's own interface code, a UI change means regenerating rather than re-shooting, and the whole library updates in one pass. [SupportPages](https://supportpages.io) produces walkthroughs that way, from your repository. If your current answer to "which videos does this release break" is a guess, that is the thing worth fixing before the library grows.