Your Tutorial Voiceover Never Shuts Up: Narration Density for Screen Recordings (2026 Guide)

1. The viewer is doing, not watching

A tutorial viewer is running your video in one window and the software in another. Their attention alternates: listen, switch, perform, switch back. Every time you speak during the "perform" phase, one of two things happens — they miss what you said, or they stop performing to listen. Both cost you the same thing: a pause, a scrub back, and a decision about whether this video is worth the trouble.

The standard advice makes this worse. "Explain your reasoning as you go" is excellent advice for a conference talk and terrible advice for a tutorial. So is "keep the energy up so there's no dead air" — the dead air is the product. It is the part of the video where the viewer catches up with you.

This is why tutorial comments are so consistently about pace rather than content: "slow down", "too fast", "had to watch this five times". The creator hears a request to reduce words per minute and obliges, which does not help, because the problem was never rate. It was density — the proportion of elapsed time occupied by speech, and specifically whether speech occupies the seconds in which the viewer needs to act.

Rate is not density

You can narrate at a relaxed 135 wpm and still be at 95% density if you never stop. You can narrate at a brisk 165 wpm at 55% density and the video will feel calm and easy to follow, because the viewer gets a gap after every instruction. Density is the variable that matters, and almost nobody sets it deliberately.

2. The narration density budget

Density = seconds of speech ÷ seconds of elapsed video, per segment. Budget it by what the viewer is doing in that segment, not by how important the content is.

Converting density to a word budget

Take the segment length in seconds, multiply by the target density, then multiply by your rate in words per second (145 wpm ≈ 2.4 words/second).

A 40-second form-filling segment at 30% density and 145 wpm:
40 × 0.30 × 2.4 ≈ 29 words.

Twenty-nine words for forty seconds of video. Almost every tutorial script written without this calculation puts 120 words there. That gap — 29 versus 120 — is the entire difference between a tutorial people finish and one they abandon.

Do this calculation per segment before you write the segment, and write to the number. It feels wrong the first three times. It stops feeling wrong when you watch someone follow your video successfully without pausing.

3. Say it before you do it

The single highest-impact rule in tutorial narration, and the one most often broken: name the action before the cursor performs it, then stop.

Compare:

• Wrong: [cursor moves, clicks] "So here I'm clicking on Settings, and then what we want to do is find the section for notifications, which is usually about halfway down…" — The viewer's cursor is nowhere near Settings yet. They are hunting while you are three instructions ahead.
• Right: "Open Settings." [1.2s gap — cursor moves and clicks] "Scroll to Notifications." [1.5s gap]

The structure is instruction → silence → confirmation of state, only if needed. Most steps do not need the confirmation; the screen confirms it.

The three rules that follow from it

1. Verb first, object second. "Open Settings", not "What we're going to do now is go into Settings". The viewer can start moving on the first word.
2. One instruction per utterance. If a sentence contains two actions, it contains two gaps you did not leave.
3. Never narrate the cursor. "I'm clicking here", "now I'm dragging this over" — the screen already shows it. Cursor narration is pure density with zero information, and it is the most common padding in the genre.

When to break it

There is one case for talking during an action: when the action takes longer than about four seconds and is mechanical (a long scroll, a slow drag, a file selection in a long list). Then a short piece of context — not instruction — fits: "This list gets long on bigger projects." Instruction during an action is always wrong; context during a slow mechanical action is fine.

4. Pause targets per UI action

These are the gaps to leave after the instruction, before the next line begins. They assume the viewer is following along in real time, which is the only assumption worth designing for.

Implement these as real silence in the audio, not as commas. If your tool inserts pauses from punctuation, a comma will give you roughly 200–300 ms — nowhere near a 2.5-second search gap. Generate the instruction as its own segment and build the gap in the edit.

5. What never to read aloud

The screen carries the syntax; the voice carries the meaning. Reading out things the screen already displays character-by-character is the second largest source of wasted density after cursor narration.

The exception is accessibility: if your tutorial is expected to be usable as audio alone — for screen-reader users, or as a podcast-style listen — then paths, values and code do need to be spoken, and that is a different piece of production with its own script. Decide which one you are making before you write. Trying to serve both produces a video that is too dense to follow along with and too incomplete to listen to.

6. The UI lexicon: shortcuts, paths and menu names

When you do have to speak a technical string, generated speech will mangle it silently. Build a small lexicon once — tutorial vocabulary is far more repetitive than it feels.

The technique underneath most of these is the same: spaces force word boundaries. maxRetryCount read as one token collapses; max Retry Count reads correctly. Underscores and slashes are dropped or turned into pauses unless you spell them out.

These errors are inaudible in the sense that the audio sounds perfectly fluent — it is simply saying the wrong thing. The only reliable catch is a search pass before generation, or transcribing the output and diffing it against your script.

7. The AI advantage: fitting the line to the gap

Here is the part that changes the economics. With a human narrator, precise timing means either re-recording a line until it fits, or stretching and compressing audio until it sounds processed. In practice this means human-narrated tutorials are almost always edited the other way around — the video is cut to fit the narration, which is exactly backwards for a follow-along format, because it removes the gaps.

With generated narration, fitting the line to the gap is free:

• You have a 6.2-second window between two actions. Your line runs 7.4 seconds at 145 wpm.
• Regenerate at 152 wpm. Now it runs 7.0. Still long.
• Cut four words. Regenerate. 6.0 seconds. Done — with 200 ms of headroom.

Three regenerations and an edit, in under a minute, at no marginal cost. The discipline this enables: lock the picture first, then write narration to the measured gaps. You can do a whole tutorial this way, and the result is a video where every instruction ends before the viewer needs to act.

A practical measurement pass

1. Record the screen at the pace a learner would work, not the pace you work. This is the step most creators skip, and it is why their gaps are too short.
2. Mark in and out points for each narration window in your editor.
3. Write the word budget for each window (seconds × density × 2.4).
4. Write to the budget, generate per window, drop in, check the tail.

Keep the voice, rate and settings identical across windows so the segments sound like one continuous take. Store the settings rather than only the audio — you will be regenerating individual lines for months as the software you are teaching changes.

8. The nine-step workflow

1. Decide the format: follow-along or audio-complete. Not both.
2. Record the screen at learner pace, with deliberate gaps at every action.
3. Segment the timeline and label each segment by type from the density table.
4. Calculate word budgets per segment.
5. Write verb-first instructions, one per utterance, to the budget.
6. Strip cursor narration and on-screen text from the draft. This usually removes 20–30% of the words.
7. Run the lexicon pass on shortcuts, paths, identifiers and acronyms.
8. Generate per window, fit to the measured gap, assemble over a continuous low-level room-tone bed so segment seams disappear.
9. Follow your own tutorial from a cold start, in real time, without pausing. Every pause you have to make is a gap that was too short.

That last step is the whole quality-control process, and it takes as long as the video. Do it once and your instincts recalibrate permanently.

9. FAQ

Retention graphs on tutorials do not behave like retention graphs on entertainment. The drop-off you are trying to prevent is not boredom — it is the viewer leaving because they could not keep up. Silence during an action does not read as dead air to someone who is performing that action; it reads as the video waiting for them. What does hurt retention is silence where nothing is happening on screen, which is why the density table budgets waiting periods at 60–80%, not zero.

140–155 wpm for instructions, a little faster for context and conceptual passages. But rate is the second-order variable. A tutorial at 155 wpm with correct density is easier to follow than one at 130 wpm that never stops. Set density first.

Tutorials are one of the strongest cases for generated narration specifically because of maintenance: software UIs change, and re-recording a single line six months later in the same voice, room and mic is genuinely difficult for a human and trivial for a stored voice profile. If your own voice is part of your brand, a clone gets you both — just store the settings alongside the audio.

Branch it in one sentence before the gap — "If you're on the free tier, this is under Account instead" — then leave a longer gap, because some of your viewers now have more to do. Never branch mid-action; the viewers on the other path lose their place entirely.

Partly. A demo viewer is watching, not doing, so demos sit at the high end of the density table throughout — 80–90%. The rules about cursor narration and reading on-screen text still apply, because they are about wasted words rather than about gaps. The pause table does not.