The best way to write a product demo script is to write two documents instead of one: an exact click
sequence you rehearse from, and a loose set of narration points you speak over the finished cut.
Writing a single word-for-word script and performing it live is what produces the recited, slightly
anxious delivery that most demos are criticised for.
This is the scripting step in creating a product demo. The
recording mechanics — data, frame, resolution — are covered separately in
recording without retakes.
Why split the script in two?
Because the two documents have different jobs and different failure modes.
The click sequence must be exact, because it is choreography. You rehearse from it until the
actions are mechanical, and it is the artifact that lets you re-record step four next quarter
without touching steps one to three. If it lives only in your head, every product change costs you a
full re-record.
The narration must be loose, because it is performance. Bullet points let you sound like someone
explaining their own product. Full sentences make you sound like someone reading, and viewers detect
it immediately even when they cannot say why.
Separating them has a practical benefit too: you can re-narrate the same recording for a different
audience — a technical buyer versus an executive — without re-recording anything.
What does a click sequence look like?
Plain, numbered, and specific enough that someone else could perform it:
1. Start on Invoices, filtered to All. Wait for the list to settle.
2. Click the Overdue filter. Pause on the result.
3. Select the top three rows.
4. Click Send reminder. Confirm in the dialog.
5. End on the confirmation toast with the count visible.
Three things make this version useful. It names the starting state, so you are not recording
whatever the app happened to be showing. It includes the pauses, which are what make a demo
readable rather than frantic. And it names the last frame, so the demo ends on the payoff instead
of trailing off.
How do you structure the narration?
Four beats, in this order:
The outcome first. "In about thirty seconds, every overdue invoice here gets a reminder." Not
"Hi, I'm Jake and today I'll be walking you through…". The viewer already chose to watch; the
introduction spends the only attention you are guaranteed.
The context, briefly. One line on why this matters — the situation the viewer recognises.
The doing, narrated as consequence not instruction. Say what the click achieves rather than what
it is. "Filtering to overdue" is a description of the screen the viewer can already see. "These are
the ones past due — twelve of them, about four thousand pounds" tells them something the screen does
not.
The payoff, stated plainly. Name what just happened. Then stop talking.
The most common script problem is narrating the interface instead of the work. If a line would still
be true with the product replaced by any other product, cut it.
What changes for an interactive demo?
Interactive demos replace narration with step captions, and the constraint is much tighter — nobody
reads a paragraph in a tooltip.
One instruction, one reason, per step:
Filter to overdue. These twelve are the ones costing you money.
Instruction first, because the viewer is looking for what to do. Reason second, because that is what
they remember. Anything longer than about two short lines gets skipped, and a skipped caption is
worse than no caption — it trains the viewer to ignore the next one too.
Write captions in the imperative and in the second person. "Click Send reminder" beats "The user can
now send a reminder." You are giving directions, not documenting a feature.
How do you know the script is good?
Read the click sequence aloud while watching someone unfamiliar follow it. Three signals mean it
needs work:
- They ask "where?" — your sequence assumes knowledge of the interface.
- They finish and say "so what?" — the payoff is not on screen, only implied.
- You find yourself explaining something the script does not cover — that thing belongs in the script, or the demo is covering too much.
Then publish it where the decision happens. For an interactive demo that is usually the pricing page
and the top feature pages; the embed guide covers the single script tag and
its options. Rendemo can also generate step captions from the recording as a starting draft, which
is useful precisely because editing a draft is faster than facing an empty caption field — though
the lines above about instruction-then-reason still apply to whatever it gives you.
A script is a maintenance artifact as much as a creative one. Keep it in the repository or the
document next to the demo, so the person who re-records in six months inherits the choreography
instead of reinventing it.
Top comments (0)