Plan voiceover around a screen demonstration
Prepare narration that matches visible screen actions, loading waits, and results. Use a cue sheet and a rehearsal before recording the final voiceover.

AI-generated editorial illustration.
On this page 7 sections
- 1. Choose what will lead: picture or narration
- 2. List the screen states before the sentences
- 3. Make a cue record for each meaningful change
- 4. Rehearse the joins and protect waiting time
- 5. Check capture permissions and a saved sample
- 6. Leave a clear handoff for the final assembly
- 7. Frequently asked questions
Plan a screen-recording voiceover around visible changes: the starting screen, the action, and the result the viewer should notice. Give each change a short spoken line and a clear cue for when it begins. Rehearse the actions with the narration before recording the final version. This makes timing a series of small decisions instead of a struggle to fit one long paragraph over moving pictures.
Choose what will lead: picture or narration
If the interface is predictable and you already know the steps, draft the explanation first and capture the screen against a rough read. If the recording already exists, watch it before writing and note where each useful result appears. Neither order removes the need to check the final pairing. A sentence that fits a silent rehearsal may still run across the next screen once spoken naturally.
For a workflow with uncertain loading time, treat the visible result as the cue. “When the folder list appears” is more repeatable than “at exactly six seconds” during capture. You can decide how much waiting to retain in the editor afterward. Do not promise the viewer that a result appears instantly just because your particular demonstration loaded quickly.
Choose live narration when speaking and operating the interface together feels manageable in a test. Choose a separate voice recording when the actions require concentration or the wording needs repeated revision. These are workflow options to compare, not claims that one always sounds better. Use the same short sequence for the comparison so the decision reflects the actual task.
List the screen states before the sentences
Take a hypothetical demonstration about creating a folder and moving a practice file into it. The useful states are: a source folder with the practice file visible, an empty destination folder with a clear name, the move action, and the destination containing the file. Those states describe what the viewer must be able to verify. They are more useful planning units than every movement of the pointer.
Reset the demonstration to a known starting point before rehearsal. Use harmless practice material and fictional names. Close unrelated windows and check what could appear in notifications, recent items, account menus, or autocomplete. This preparation is your production choice; selecting a capture area alone does not establish that every private detail is hidden.
Write the result of each step in plain words. For example: “The practice file is now listed inside Lesson Assets.” If you cannot describe the visible result, the action may not need its own narrated beat. If the result is important but difficult to see, change the framing or demonstration plan before asking the voiceover to compensate for it.
Make a cue record for each meaningful change
Use four fields in your planning notes: starting state, action, visible result, spoken line. For the folder example, the starting state is the source list; the action is creating a destination; the result is a folder named Lesson Assets; and the spoken line explains why that destination exists. Keep the spoken line free of instructions intended only for the person recording.
An illustrative cue might read: “Start after the destination name is confirmed. Say: ‘This folder will hold the files for one lesson.’ Hold until the folder name is easy to identify.” The next cue can begin once the practice file is selected. You do not need narration for every pointer adjustment. Explain a choice or direct attention where the picture alone leaves uncertainty.
For an already captured sample, add observed time ranges to those notes. A hypothetical draft could reserve zero to five seconds for the source folder, five to eleven for creating the destination, and eleven to eighteen for the move and result. These numbers are examples, not measured software performance or recommended pacing. Replace them with timings from your actual clip.
Rehearse the joins and protect waiting time
Read one cue while performing its action. Stop when the sentence arrives before the relevant control or carries on after the result has disappeared. Shorten the sentence, leave the result visible longer, or split the beat. Speeding up the entire delivery can hide the local mismatch without making the demonstration easier to follow.
A useful repair is to move explanation away from a precise click. Say why the destination matters while the folder is stable, then use a short action line at the transition. Long background explanations are difficult to land on a tiny cursor event. They are easier to place over a screen that remains meaningful while someone listens.
When a loading screen appears, wait for the actual result before delivering the next instruction. In your notes, mark the condition rather than inventing a fixed delay. If you later remove part of the wait, review the edit with sound to confirm the sequence still makes sense. Keep any important warning or decision visible long enough for the spoken explanation you actually recorded.
Check capture permissions and a saved sample
On a Mac, Apple documents screen recording through Screenshot and QuickTime Player. Screenshot can record the whole screen or a selected portion, and its Options menu includes microphone selection. Those are Apple tool capabilities, not EasyLines features. Choose the capture tool and area you intend to use, then record a short sample that includes a real click and spoken sentence.
Apple also provides controls for screen and system-audio recording access under Privacy & Security. If your chosen capture app cannot see the screen, review the permission for that app and follow its instructions. Screen access, microphone selection, and a usable spoken recording are separate checks. A moving picture does not prove that your narration was captured.
Play the saved sample and inspect both the voice and the visible result. If the sound is unclear, use the audio-check workflow before repeating the entire demonstration. For awkward or overlong lines, use the spoken-script checklist to simplify the wording. Change the part that caused the mismatch, then repeat the same small sample.
Leave a clear handoff for the final assembly
Record or collect the final narration in short, identifiable beats. Note which line belongs to which screen state and flag any changed wording. If you say “open Lesson Assets” after renaming the folder in the picture, correct the mismatch before export. A precise cue sheet is useful only while its labels agree with the actual recording.
Watch the assembled sequence once for timing and again for meaning. Can a viewer identify the relevant control before the next action? Does the final state prove the step finished? Are you describing what happened in this demonstration rather than promising universal behavior? Keep the original recording until you have checked the finished file.
EasyLines is a teleprompter and recorder preparing to launch. It may fit your preparation for a spoken introduction or separate explanation, while screen capture and assembly happen in other tools. Do not plan on a direct editor integration or automatic synchronization. The reusable asset is your cue record: it tells you what must change when the interface, wording, or demonstration changes.
Frequently asked questions
Should I record the screen or voice first?
Use a rough spoken read before capture when the workflow is predictable. Write against the actual clip when the screen recording already exists. Review the final pairing either way.
How do I handle loading screens?
Cue the next line from the visible result during capture. Decide how much waiting to keep during editing, then check the sequence again with sound.
Do I need a sentence for every click?
No. Narrate the decision, required action, or result that needs explanation. Leave routine pointer movement unspoken when the picture is clear.
Can EasyLines capture my computer screen?
EasyLines is a prelaunch teleprompter and recorder. Use a separate screen-capture tool and editor for this workflow.
Sources and further checks
Coming to iPhone and iPad
Put your next script on EasyLines.
A little help with the words. More room to be yourself. Join the waitlist and we’ll email you at launch.


