A technical tutorial can look clear on the page and still sound awkward when read aloud. Commands interrupt sentences. Acronyms sound unfamiliar. The narrator moves on while the viewer is still looking for a button.
The voice matters, but so does what you ask it to read. This guide walks through a simple example: narrating a screen recording that shows someone how to start a local development server and open their app.
Write for someone watching the screen
Start with the instructions you already have. Keep a separate narration draft so you can change the wording without changing the commands.
A written instruction might say:
Execute npm run dev from the project root, then navigate to the localhost address printed in the terminal to verify that the development server is running.
For a project with its dependencies installed and a working dev script, the spoken version could be:
Open a terminal in your project folder. Run the command shown here. When the server is ready, open the local address printed in the terminal. You should see your app.
Show npm run dev clearly on screen and include it in the written instructions. The voice explains what to do and what to expect; the viewer does not have to reconstruct the command by ear.
Check references such as “here” and “this.” They work when the relevant item is visible. If the cursor is elsewhere or several windows are open, name the terminal, file, or button instead.
Check technical terms before generating the full script
Read through the narration and mark anything that might sound wrong: acronyms, library names, version numbers, paths, and keyboard shortcuts.
In this example, “local URL” can become “local address.” That is easier to say and just as useful to someone following the demonstration.
Some terms need to stay. If a later section explains an API, try that acronym in a short sample. If the voice treats it as a word, writing “A P I” in the narration draft may help. Listen to the result before applying that spelling throughout the script.
Keep the conventional spelling in written instructions. For terms with more than one common pronunciation, choose one your audience will recognize and use it consistently.
Avoid reading every character in a path when the viewer can see and copy it. “Open the configuration file shown here” is usually enough. But if the lesson depends on the difference between two filenames or command flags, explain that difference aloud.
Leave time for the action
Watch the screen recording before deciding where the narration should pause.
After “Run the command shown here,” the viewer needs to see the command being entered. After “Open the local address,” they need to see the browser appear. Those moments take longer than a natural breath between sentences.
Mark them in your working script:
Run the command shown here.
[Leave time to enter the command.]
When the server is ready, open the local address printed in the terminal.
The bracketed note is an editing instruction, so remove it before generating speech.
Keep short conversational pauses in the audio. Leave longer gaps for typing, loading, or switching windows in the video edit, where you can match them to the footage.
Do not add a pause after every sentence. Listen for the points where the viewer has something to do.
Test one short section first
Paste the revised paragraph into FlowSpeech’s text to speech editor, choose a voice, and generate a short sample. Use the actual tutorial text so the test includes the terms and instructions that matter.
Start with minimal delivery direction. Listen for rushed phrases, unclear pronunciation, or emphasis that changes the meaning.
If “You should see your app” sounds detached from the previous instruction, check the punctuation and wording first. A shorter sentence may solve the problem without extra controls.
For a deliberate pause within the narration, insert a pause tag in the text editor. For example:
Open the local address printed in the terminal. [⌛1.0s] You should see your app.
That one-second pause is a starting point. Listen and adjust it to fit the recording.
Use emotion tags only where the delivery needs a clear change. A routine setup instruction usually works with a steady, straightforward voice. Adding enthusiasm to every line can distract from the steps.
Once the sample sounds right, use the same voice for the remaining sections. Generate and review manageable sections, then download the audio for the video edit. Keep the narration script alongside the project so later corrections are easy to find.
Match each line to the recording
In your video editor, place the narration alongside the screen recording.
At “Open a terminal in your project folder,” show the terminal and enough context to identify the folder. At “Run the command shown here,” keep the command readable. When the voice mentions the local address, show the relevant terminal output.
Follow the address printed by that project rather than assuming a particular port.
If the browser takes a few seconds to load, leave space before “You should see your app.” The confirmation should arrive when the viewer can actually see the result.
When a section feels rushed, check the script before changing playback speed. You might be explaining the same action twice or describing something that is already obvious on screen. Remove the extra sentence and watch again.
Keep essential commands available as copyable text outside the video. Captions help people follow the narration, but they are an awkward place to copy code.
Check the parts a new viewer might miss
Listen once without watching the screen. Notice any terms you cannot understand or sentences that seem to stop halfway through an idea.
Then watch the whole sequence. Can you follow the instruction without anticipating the next step? Is the command visible long enough to read? Does the tutorial show what success looks like?
For this example, the viewer should be able to identify three things: the project folder, the command to run, and the address that opens the app.
Ask someone unfamiliar with the recording to try that section if possible. If they hesitate, find out what they were looking for before adding more explanation.
After making corrections, check the captions, confirm that the displayed commands match the written instructions, and export the finished video.
