How to Write a Demo Video Script in 2026 (+ Templates)

Most demo videos do not fail because of bad visuals. They fail because the narration wanders. The presenter says "um, so now I'm going to, let's see, click over here," the viewer loses the thread, and the video gets closed before the useful part.

A short written script fixes almost all of that. This guide shows you how to write a demo video script for a software product, step by step. You will get a simple structure, rules for writing each line, a way to estimate timing, three complete templates with filled-in examples, and a before/after rewrite you can learn from.

It is written for founders recording their first product walkthrough, product marketers shipping launch videos, and support teams building how-to libraries.

#Why a script matters for screen demos

A screen demo has two channels running at once: what the viewer sees and what they hear. When the two match, the video feels effortless. When they drift apart, viewers have to work to connect them, and most will not.

A script helps in a few concrete ways:

• It keeps you on the main path. Without one, it is easy to wander into settings menus and edge cases that only matter to you.
• It makes the video shorter. Writing forces you to cut steps that do not move the viewer toward the outcome.
• It makes re-recording cheap. When the UI changes, you update a few lines instead of improvising a whole new take.
• It gives you captions and a written guide for free. A clean script is already most of your caption file and the backbone of a step-by-step article.
• It makes translation possible. You cannot reliably translate rambling, but you can translate twelve clear sentences.

If you have not planned the video itself yet, start with our guide on how to make a product demo video, then come back here to write the words.

#The five-part structure of a demo video script

Almost every good software demo follows the same shape. You can use it for a 45-second feature clip or a five-minute onboarding video.

#Hook

The hook is a promise. It tells the viewer exactly what they will get if they keep watching. Skip the greeting and the company history. "Hi everyone, welcome to this video about our platform" wastes the most valuable seconds you have.

#Context

One or two sentences that describe the situation before the feature. This is what makes the steps meaningful. If you skip context, viewers see clicks but do not understand why they matter.

#Steps

This is the body of the script, and it is where most of the writing rules below apply. Each step gets its own line, and each line matches one thing happening on screen.

#Outcome

Show the finished result and say it out loud. Viewers need a clear "done" moment, especially in onboarding and support videos.

#Next step

Close with a single action: try it, read the guide, book a call, or watch the next video. One call to action, not three.

#How to write each line of the script

The steps section is where scripts get messy. These rules keep it tight.

#Write one line per on-screen action

Each line in the steps section should map to one visible action: a click, a selection, typing into a field, or a page change. This gives you three benefits:

1. Your narration stays in sync with the screen.
2. Editing becomes easy, since you can fix a single line without touching the rest.
3. The script doubles as a numbered step list for a written guide.

If you find a line covering three actions, split it. If two lines describe the same action, merge them.

#Describe what the action achieves, not which button to press

The viewer can already see the button. Your voice should add what the screen cannot show: the purpose of the action.

• Weak: "Click the blue button in the top right."
• Better: "Save the draft so your teammates can review it."

The viewer still sees you click the blue button, but now they know why. This also makes your script survive small UI changes. If the button moves or turns green next quarter, the line is still correct.

There are exceptions. If the control is hard to find, it is fine to name it: "Open the menu under your profile picture to find billing settings." Use location hints when they help, not by default.

#Avoid repeating what the screen already says

The most common mistake in demo narration is reading the interface aloud. It sounds robotic and adds nothing.

Bad: "Enter the folder link in the folder link field."

Good: "Paste the link to the folder you want to sync."

Bad: "Click Settings to open Settings, then click Notifications."

Good: "Open your notification settings."

Bad: "Select the date in the date picker."

Good: "Pick the day the campaign should start."

Each good version tells the viewer something new: what to paste, why to open the page, what the date controls. If a line only repeats a label, rewrite it around intent or cut it.

#Use plain language

Short words, short sentences, active voice. The U.S. federal plain language guidelines are a good reference here, and their advice applies just as well to software narration: address the reader as "you," use common words, and keep sentences short.

Some practical rules:

• Keep most lines under 15 words.
• Use "you" and present tense: "You'll see your new project here."
• Prefer verbs to nouns: "configure" beats "perform the configuration of."
• Drop filler like "simply," "just," and "basically." They add length, and "simply" can make a viewer who is struggling feel worse.
• Use the same name for the same thing every time. If it is a "workspace" in line two, it should not become a "project space" in line six.

Product style guides are useful for word choices. Both the Google developer documentation style guide and the Microsoft Writing Style Guide cover how to refer to UI elements, how to write instructions, and how to keep a friendly but clear tone.

#Write for captions and translation

Many people watch demo videos with the sound off, in a busy office, or in a second language. Your script should work as text, not just as audio.

The W3C's guidance on captions and the WCAG success criterion for captions on prerecorded media explain why captions matter for accessibility. From a scripting point of view, that means:

• Short sentences caption cleanly. A 12-word sentence fits on one or two caption lines. A 40-word sentence becomes a wall of text.
• Avoid idioms and slang. "This feature is a home run" does not translate well. "This feature saves you about an hour each week" might, if it is true for your product.
• Avoid puns and wordplay. They rarely survive translation.
• Spell out what pronouns refer to. "Click it and then drag that over there" is unclear in any language.
• Keep numbers and product names consistent. Translators and translation tools handle consistent terms far better.

The W3C also has short tips for writing for web accessibility that apply directly to scripts: clear headings, simple sentences, and explaining unfamiliar terms.

#Timing your voiceover: the words-per-minute method

You do not need a stopwatch to plan timing. You need a word count and a rough speaking rate.

As a rule of thumb, conversational narration commonly runs roughly 130 to 160 words per minute. Treat that as an approximate guideline, not a fixed number. Your actual pace depends on the voice, the language, the complexity of the content, and how many pauses you leave for the viewer to watch something happen.

Here is why the method works. A demo video has two clocks: how long it takes to say the words, and how long it takes for the on-screen action to happen. Your script needs to fit inside the second clock. If a step takes four seconds on screen, a 25-word line will spill over and either rush the viewer or leave the narration lagging behind the screen.

A simple way to plan:

1. Decide your target length. For a single-feature video, 60 to 90 seconds is a reasonable goal.
2. Multiply minutes by your planned rate. At about 140 words per minute, a 60-second video holds roughly 140 words of narration.
3. Subtract room for pauses. Leave silence while pages load or results appear. In practice, a 60-second demo often works best with noticeably fewer words than the maximum.
4. Divide the remaining words across your lines. If you have eight steps, that might be around 10 to 14 words per step.
5. Read the script aloud with the recording playing. Adjust any line that runs long.

These numbers are estimates for planning. Always check against the real recording.

If you use an AI voice, you can usually adjust speed and pace instead of rewriting. Many tools let you change the voice speed and pace, then re-render. Still, if a line feels rushed at normal speed, the better fix is usually a shorter line.

#Three demo video script templates you can copy

Each template below is a fill-in-the-blanks structure, followed by a complete example script for a fictional project management app called "Tasklane." Copy the template, swap in your product, and cut any line that does not earn its place.

#Template 1: Feature walkthrough

Use this when you are showing one feature to existing users or prospects, for a changelog, a feature page, or a help center article.

HOOK:      In the next [time], you'll [outcome the feature delivers].
CONTEXT:   [The old way, or the problem], which [cost or pain].
STEP 1:    [Open or find the feature, framed by purpose].
STEP 2:    [First meaningful choice the user makes].
STEP 3:    [Second meaningful choice].
STEP 4:    [Confirm or apply].
OUTCOME:   [What is now true]. [Why it matters in one clause].
NEXT STEP: [One action: try it, read the guide, watch next].

Example: Tasklane recurring tasks (about 60 seconds)

Hook: In the next minute, you'll set up a task that repeats on its own.

Context: Right now, someone has to remember to create the weekly status check every Monday.

Step 1: Open the task you want to repeat.

Step 2: Choose how often it should come back, in this case every week.

Step 3: Pick the day and time it should appear.

Step 4: Decide who it goes to. Tasklane can keep the same owner or rotate through the team.

Step 5: Save the schedule.

Outcome: The task now shows up every Monday at 9am, already assigned. Nobody has to remember it.

Next step: Try it on one of your own routines, or read the full guide below.

#Template 2: Onboarding or how-to

Use this for first-run tutorials, help center videos, and support replies. The goal is that a new user finishes the video and completes the task without help.

HOOK:      This video shows you how to [task] in [number] steps.
CONTEXT:   You'll need [prerequisite], if you have one.
STEP 1:    [First action, stated as what it accomplishes].
STEP 2:    [Next action].
STEP 3:    [Next action].
STEP 4:    [Next action].
STEP 5:    [Check that it worked].
OUTCOME:   You're done. [What the user can do now].
NEXT STEP: Next, [the natural follow-on task or video].

Example: Tasklane, creating your first project (about 75 seconds)

Hook: This video shows you how to create your first project in five steps.

Context: You'll need a Tasklane account. If you were invited by a teammate, you already have one.

Step 1: Start a new project from your home screen.

Step 2: Give it a name your team will recognize, like "Website refresh."

Step 3: Pick a template. The basic board works well if you are not sure.

Step 4: Invite the people who will work on it. They'll get an email with a link.

Step 5: Add your first task so the board isn't empty when they arrive.

Outcome: You're done. Your team can now see the project and start adding their own tasks.

Next step: Next, watch how to set due dates and reminders.

#Template 3: Sales or launch demo

Use this for launch announcements, landing pages, and short videos sent in sales follow-ups. It leans harder on context and outcome, because the viewer is deciding whether to care.

HOOK:      [Bold, specific outcome], without [common pain].
CONTEXT:   Most teams [current workaround]. It [cost of that workaround].
STEP 1:    Here's how it works. [First action, framed as benefit].
STEP 2:    [Key differentiating moment].
STEP 3:    [Second differentiating moment].
STEP 4:    [Result appears].
OUTCOME:   [What changes for the team]. [Who it helps most].
NEXT STEP: [Clear CTA: start free, book a call, join the waitlist].

Example: Tasklane launch of workload view (about 90 seconds)

Hook: See who is overloaded this week before anyone burns out, without building a spreadsheet.

Context: Most teams track workload in a separate sheet that is out of date by Tuesday. Managers find out someone is swamped only when a deadline slips.

Step 1: Here's how it works. Open workload view from any project, and everyone's tasks are already counted.

Step 2: Each row is a person. The bar shows how much is on their plate this week.

Step 3: Spot someone in the red, and drag one of their tasks to a teammate with room.

Step 4: The bars update right away, and both people get a heads-up about the change.

Outcome: Your team spreads work evenly, and you catch problems days earlier. It is especially useful for teams with shared on-call or support queues.

Next step: Workload view is live today on every plan. Open it from your project sidebar to try it.

For pacing, visuals, and editing decisions that go with these scripts, see our list of demo video best practices.

#Before and after: rewriting a real-sounding script

Here is a typical first draft, transcribed from someone narrating a recording without a script. The product is a fictional file-sharing app called "Driftbox."

Before (about 95 words):

"Okay, so, hi, in this video I'm going to show you, um, how to share a folder. So first you go up here and you click on the Share button, which is the Share button up here. And then it opens the share dialog. And then you enter the email address in the email address field. And then there's this dropdown, the permission dropdown, and you can choose the permission. So I'll choose Can Edit. And then you click Send. And that's basically it, it's pretty simple. So yeah, thanks for watching."

After (about 55 words):

Hook: Here's how to share a folder with a teammate in under a minute.

Step 1: Open the sharing options for the folder.

Step 2: Add your teammate's email address.

Step 3: Choose what they can do. "Can edit" lets them add and change files.

Step 4: Send the invite.

Outcome: They'll get an email and can open the folder right away.

Next step: To stop sharing later, open the same menu and remove them.

What changed:

• Filler removed. "Okay, so," "um," "basically," and "so yeah" are gone.
• Repetition removed. "The Share button, which is the Share button" and "the email address in the email address field" became short, purpose-led lines.
• Purpose added. The permission line now explains what "Can edit" means, which the screen alone does not show.
• A real ending. "Thanks for watching" became a useful next step.
• Much shorter, with more useful information.

This is also a good example of why one-line-per-action scripts are easy to edit. If a reviewer says "explain the other permission options too," you add one line under Step 3 and nothing else moves.

#Reviewing and editing the script against the recording

A script that reads well on paper can still feel wrong against the video. Always review the two together.

1. Play the recording with the script beside it. Check that each line lands while its action is on screen, not before or after.
2. Read every line out loud. Anything you stumble on, a viewer will stumble on too. Rewrite it.
3. Check for lines that describe nothing. If a line has no matching action and adds no context, cut it.
4. Check for actions with no line. If something important happens on screen in silence, decide whether it needs a line or whether the silence is fine.
5. Check terminology. Make sure UI names in the script match what is on screen today. Products change.
6. Read the captions without sound. If the video still makes sense, your script is doing its job.
7. Ask one person who has never used the feature to watch it. Note where they hesitate or rewind.

Many viewers scan rather than read every word, a pattern described in Nielsen Norman Group's article on how users read on the web. The same habit shows up in video: people skip around. Clear, front-loaded lines help them find the part they need.

#Using a first draft instead of a blank page

Writing a script from scratch is the slow part. A faster approach is to record first, then edit a generated draft. That is the workflow Nook is built around: you upload any screen recording, and it transcribes what you said (or reads the on-screen text if you recorded in silence) and writes a short script line for each step.

From there, you apply the rules in this guide. You can rewrite any single line by hand, or rewrite every line at once with an instruction like "shorter, more friendly." It then voices the script with natural AI voices, zooms in on clicks, adds captions, and re-renders after each edit, so you can check your changes against the recording right away.

The same script also becomes a written guide. If your team needs documentation as well as video, see how to turn a screen recording into a step-by-step guide.

#A quick checklist before you record or render

• The hook states a specific outcome in one sentence.
• Context explains the problem in one or two sentences.
• Each step is one line tied to one on-screen action.
• No line reads a UI label aloud without adding meaning.
• Most lines are under 15 words.
• Product terms are used consistently.
• There are no idioms, puns, or unclear pronouns.
• The total word count fits your target length with room for pauses.
• The video ends with one clear next step.
• The script works as captions with the sound off.

#FAQ

#How long should a demo video script be?

Base it on the video length you want. As a rough guide, conversational narration often runs about 130 to 160 words per minute, so a 60-second video usually holds somewhere around 100 to 140 words once you leave room for pauses. Single-feature demos tend to work best when they stay short. Check the final length against the actual recording, since every voice and product is different.

#What is the difference between a demo video script and an explainer video script?

An explainer video script usually focuses on the problem and the idea, often with animation and few product screens. A demo video script focuses on the product itself, with each line tied to an on-screen action. Many launch videos mix the two: a short explainer-style hook and context, followed by demo-style steps. The five-part structure in this guide works for both.

#Should I write the script before or after recording?

Either works. Writing first helps when the flow is long or the stakes are high, like a launch video. Recording first is often faster for help center and onboarding content, because you can see exactly which steps happened and write one line for each. Some tools generate a first-draft script from your recording so you can start editing instead of starting from a blank page.

#Should I name the buttons in my script?

Usually not. The viewer can already see what you click. Describe what the action achieves instead, like "Save the draft so your team can review it." Name a control only when it is hard to find or when the viewer will need to search for it later.

#How do I make my script work for other languages?

Use short sentences, consistent terms, and no idioms, puns, or slang. Make sure every pronoun clearly points to something. A script written this way translates more reliably, whether a person or a tool does the translation. Nook can translate scripts into Spanish, French, Portuguese, Italian, Hindi, Japanese and Chinese, with native voices for each.

#Do I need a professional voiceover?

Not for most product demos. Clear wording matters more than a polished voice. You can record your own voice, or use an AI voice and adjust its speed and pace. If you go with AI voices, a clean script matters even more, since the voice will read exactly what you wrote.

#How often should I update demo scripts?

Review them whenever the UI or workflow changes. Scripts that describe purpose ("Save the draft so your team can review it") age better than scripts that describe visuals ("Click the blue button in the top right"), so you will rewrite less often.

#Does a good script help with SEO?

Indirectly. A clear script gives you accurate captions, a transcript, and a written guide you can publish alongside the video. Google's guidance on creating helpful, people-first content rewards pages that genuinely help readers complete a task, and a well-structured walkthrough does exactly that.

#Try it on your next recording

The fastest way to get better at demo scripts is to write a lot of short ones and compare them against the recording. If you want a head start, Nook turns a screen recording into a first-draft script, voiceover, captions, and a written guide you can edit line by line. Your first video is free (up to one minute, with a watermark), and you can see the paid options on the pricing section. Create a free account and try it on the next feature you ship.