A narrated worked example explains how a decision is made, not just which button is clicked or which answer appears. Choose one small problem, expose the useful reasoning, and show the intermediate results. The listener should be able to distinguish the facts given at the start from the choices made while solving it.
Establish the problem and the stopping point
Write the problem in a form that can be stated aloud without a long preamble. For example: “Three tasks share one reviewer. Choose an order that respects their deadlines.” List the inputs in a companion table so listeners can inspect them while following the narration.
State what counts as a finished result. The example may end with a sequence, a completed form, or a justified choice. Without that boundary, authors often keep explaining adjacent topics until the original problem disappears.
Remove complications that do not affect the intended decision. A first example about task order does not also need a lesson about staffing, budgets, and communication style. Save those for separate examples with their own purpose.
If the problem depends on a chart, prepare its spoken orientation using the chart narration guide before writing the decision sequence.
Narrate the reason at the moment it matters
Use a repeating logic of observation, decision, and result, but vary the wording naturally. “Task B needs the output from A, so I place A first. B can now begin after that output is ready.” The listener hears the constraint and its consequence together.
Avoid inventing a stream of internal thoughts. Include reasoning that another person can inspect: deadlines, dependencies, criteria, or explicit rules. Vague statements such as “this feels best” do not help someone apply the method to a new problem.
When you reject an alternative, explain the specific conflict. “Putting B first would leave it waiting for A” is more useful than “that is incorrect.” Keep the rejected path brief so it does not overshadow the chosen one.
For interface demonstrations, combine this reasoning with the step-audio structure. Click instructions and decision explanations serve different purposes and should be paced accordingly.
Show intermediate states clearly
Give each stage an ID in the production sheet. Record what appears on screen, what is spoken, and what changed since the previous stage. This makes it easier to discover a visual that accidentally jumps ahead of the narration.
Leave time to inspect intermediate results. If a table changes three times during one sentence, the listener may never see the state that supports the explanation. Split the narration or simplify the visual sequence.
W3C's description guidance addresses essential visual information. Apply that principle by naming the important state change in words: “A now appears before B in the sequence,” rather than relying entirely on a moving highlight.
Generate one complete example before producing a series. Review it against the same inputs used in the lesson, because a changed number or renamed field can invalidate a carefully reasoned explanation.
Add a learner attempt with a meaningful variation
Create a second problem that uses the same decision process with different inputs. Change enough to require applying the method, but avoid introducing an unexplained rule. Clearly separate the demonstration audio from the learner's attempt.
Prepare feedback that refers to the relevant decision, using the quiz feedback workflow. A response should explain the dependency or criterion involved, not simply repeat the final answer.
Ask a reviewer to trace the narrated solution and independently solve the practice version. If the reviewer needs a rule that appears only in the author's notes, add that rule to the lesson before release.
Use the voice studio to produce the approved stages as manageable paragraphs. Assemble them with the visuals in your course tool, and finish by checking that every spoken reason matches the visible state and every promised result actually appears.
