---
title: "How to Script a Screencast Before You Record"
canonical: https://supportpages.io/guides/script-a-screencast-before-you-record
updated: 2026-08-13
---

A two-column script - what happens on screen on one side, what the voice says on the other - that you can record from in a small number of takes, hand to a colleague, or use to re-shoot the video a year from now.

## Before you start

Know the exact task the video covers and the state the demo account needs to be in before the first frame. A script that opens with "from the dashboard" is not a script until somebody has written down how the dashboard got that data in it.

Have the product open in front of you while writing. Scripts written from memory describe an interface that is one release out of date, which surfaces halfway through the recording session.

![A script laid out as paired columns: what is said, and what is on screen at that moment.](/images/guides/figures/script-a-screencast-before-you-record.webp)

*Write both columns. Narration written alone always outruns the cursor.*

## Steps

1. **Write the outcome sentence first, and make it the opening line of the narration.**
   "In the next two minutes you will invite a teammate and set their permissions." A viewer who cannot tell in the first five seconds whether this video is for them will leave.

2. **List the click path as numbered on-screen actions.**
   One row per action, in the order the mouse performs it, with the literal control names. This column is the recording plan, and it is what makes rehearsal possible.

3. **Write the narration beside the actions, not underneath them.**
   Each spoken line sits next to the action it describes. Narration written as continuous prose always drifts out of sync with the screen, and you find out during recording.

4. **Write the narration in spoken English, not written English.**
   Short sentences, contractions, no subordinate clauses. Anything you stumble over reading aloud will be stumbled over on the take.

5. **Estimate the running time from the word count.**
   A comfortable narration pace is around 150 words a minute, so a 450-word script is roughly three minutes of finished video before you add pauses. If the number surprises you, the script is too long, not the pace too slow.

6. **Mark the pauses explicitly.**
   Note where the voice stops so the viewer can read a new screen, and where the screen waits for a slow operation. Unmarked pauses become the awkward silences you edit out later.

7. **Name every control exactly as the interface names it.**
   If the button says **Add member**, the narration says "add member". Approximate labels are the single most common reason a viewer gets lost while watching somebody else do the task correctly.

8. **Cut every sentence that explains why.**
   A screencast is a demonstration, and rationale belongs in the article around it. Justification is where a two-minute demonstration turns into a ten-minute video nobody finishes.

9. **Write the closing line verbatim.**
   State what the viewer has now achieved and the one next thing to do. Videos that stop when the task finishes feel truncated; videos that ramble past it get closed early.

10. **Read the whole thing aloud against the live product.**
    Perform the clicks as you read. This is the rehearsal, and it finds the missing step, the modal you forgot, and the sentence that is two seconds too long for the animation it covers.

## Common mistakes

**Writing prose and hoping to perform it.** Written sentences are longer and more clause-heavy than spoken ones, so recording turns into a series of retakes of the same paragraph.

**Scripting the interface you wish existed.** Written from memory, a script assumes the confirmation dialog was removed last sprint. Write with the product open.

**Leaving the first fifteen seconds unscripted.** The opening is where viewers decide, and it is the part most often improvised because it feels like preamble.

**Describing the mouse.** "Now move to the top right and click the gear icon" narrates something the viewer can already see. Say what the action achieves and let the screen show where.

**Treating the script as disposable.** The script is the only artefact that makes a re-shoot cheap. Store it next to the video file, not in a document nobody can find.

## When this stops scaling

Scripting scales better than any other part of video production, because a script is text: it diffs, it reviews, and somebody who is not the original author can pick it up. There is no volume at which writing one stops being worth it.

What does break down is the relationship between the script and the product. A script is a description of an interface at a moment in time, and nothing tells you when that description stopped being true. Past roughly ten scripts, kept alongside a product shipping interface changes every few weeks, the collection becomes a set of documents that are individually plausible and collectively unreliable - and the discovery happens mid-recording, which is the most expensive moment for it to happen.

Teams that hit this either accept a standing review cost or move to generating walkthroughs from the interface code itself, where the script and the recording are produced from the same source and cannot disagree. [SupportPages](https://supportpages.io) works that way. Until you are past a handful of videos, a written script in version control is the sensible answer.