Narrated Explainers and Decks

Position this module against the previous two. Module 1 made the case for video as an agent output; Module 2 covered the two working stacks — Remotion compositions and hyperframe-style HTML sequences — and the project structure that keeps them maintainable. This module deliberately steps back from the rendering machinery and spends its time on the content layer: the script, the slide structure derived from it, the narration voice, and the editing pass. Most quality problems in agent-produced explainers are content problems wearing a motion costume.

The phrase 'the script is the design' is the organising idea. In a traditional explainer pipeline the script, the slides, and the voice-over are produced by different people at different times, and they drift. In an agent pipeline, the script is the single artifact a human writes and edits with care, and everything else — slide structure, on-screen text, timing, narration audio, captions — is derived from it mechanically. That makes the script the highest-leverage place to spend design attention.

Flag the worked example early: this school's own course modules are written as slides plus per-slide narration scripts, and that exact format is what feeds the school's video pipeline. Participants are, in a literal sense, inside the worked example right now — the script being narrated over this slide is the same kind of artifact the module teaches them to write.

This is the structural argument of the module, and it is the same argument the rest of the course makes about motion generally: the artifact that matters is the diffable text source, and the rendered output is a build product. Applied to explainers and decks, the source is a structured document — for this school, a course module file with slides, speaker notes, and per-slide scripts; for a product team, it might be a release note, a spec, or a help-centre article. The article, the deck, and the video are derived from it.

The practical payoff is maintenance. Product material goes stale constantly — pricing, screenshots, feature names. When the deck and the video are hand-built, they decay silently and someone discovers the out-of-date claim in front of a customer. When they are generated from the source, updating the source and re-running the pipeline is the whole job. Huashu Design's slide-deck capability is a useful concrete reference here: it produces an HTML deck for browser presentation plus an editable PPTX, where the export translates real DOM styles into actual PowerPoint text frames rather than images — so even the 'editable in PowerPoint' requirement does not force you back to hand-maintained decks.

Be honest about the boundary: one source, three outputs does not mean one text pasted into three templates. The formats have different grammars — the article can sustain nuance and caveats, the deck compresses to claims and evidence, the video adds time and voice. The source has to carry enough structure that each output can make its own selection. That is what the next two slides cover.

The format matters because the script is doing double duty: it is the narration a voice will read, and it is the specification the agent uses to generate visuals. An essay-shaped script gives the agent prose to summarise, and summarisation is where invention creeps in. A screenplay-shaped script — scenes, beats, anchors — gives the agent a one-to-one mapping: this beat becomes this slide, these words go on screen, this sentence gets read aloud.

The on-screen anchors deserve the most emphasis. The single biggest quality lever found in this school's motion work, and stated in the school's article on Remotion and Hyperframes, is whether the brief contains the actual words that will appear on screen. The same is true at the script level: numbers, product names, claims, and headings should be written into the script as anchors. An agent asked to 'pick out the key point' will pick a plausible one, which is not the same as the right one.

The word-count guidance is practical, not aesthetic. At a conversational reading pace of roughly 150 words per minute, a 60–120 word beat produces 25 to 50 seconds of narration, which is about as long as a single visual can hold attention without changing. Beats much longer than that need splitting; beats much shorter than ten seconds tend to feel like a slideshow on fast-forward. This school's own per-slide scripts sit in exactly that 60–120 word band, which is one reason they convert to video shots cleanly.

The phrase 'not alongside it' is doing real work in the title. The common failure is to write a script and then build a deck as a separate creative act — at which point the deck drifts from the script, the narration no longer matches what is on screen, and the video assembled from both feels subtly broken even when no single element is wrong. Generating the slide structure from the script keeps the two locked together: the beat's type determines the treatment, the beat's anchors become the on-screen text.

This table is a condensed version of the element-to-template mapping this school's own video pipeline uses to turn course modules into chapter videos: section headings become teaching beats, definitions get a term-and-definition card, diagrams are capped at about five nodes per shot and split when larger, tables are trimmed to roughly five rows, code is cut to the few lines the narration actually explains, and quotes become pull-quote shots. The cap of about thirty words on screen per beat comes from the same convention.

The deeper point is about where judgment lives. Making the mapping mechanical is not an abdication of design — it is a relocation of design. The taste decisions happen in the script: what to claim, what to anchor, what to cut. The slide generation is then deliberately boring, which is exactly what makes it repeatable and reviewable. When a generated slide looks wrong, the fix is almost always upstream in the script, not downstream in the layout.

Walk the six stages and name the owner of each. Stage one is the script, one segment per slide or beat, written and edited by a human — the previous slides covered why. Stage two is text-to-speech and timing: the agent generates one audio file per segment and measures its duration; captions and the transcript are generated from the script text rather than transcribed back from the audio, so they are exact. Stage three is the timeline: a small, diffable file that maps each segment to its visual, with start times and durations derived from the measured audio. Stage four renders the visuals per segment from templates and brand tokens, with the on-screen text taken from the script's anchors. Stage five assembles the MP4: segments stitched in order, music ducked under the narration, captions packaged with the output. Stage six is a human watching the whole thing end to end.

The ordering principle worth calling out is that narration drives duration. Each shot lasts as long as its narration plus a little breathing room, never shorter than the visual's own animation needs. Pipelines that go the other way — fixed-length visuals with narration squeezed to fit — produce the rushed, breathless pacing people associate with cheap generated video. This is also how the Huashu narrated-animation pipeline is structured: voice generated first, durations measured, a timeline file generated from those durations, and the visuals driven from the timeline, with the music ducked under the voice in the final mix.

The dashed feedback line is the same discipline as everywhere else in this course: when the review finds a problem, the fix is made in the script or the timeline and the video is re-rendered. Editing the MP4 directly would break the link between source and output and put you back in the world of hand-maintained video that this whole approach exists to escape.

The failure mode here is well documented across agent design work and has a name in the open-source skill community: slop — the visual and verbal greatest common denominator of the training data. In narration it shows up as breathless enthusiasm, vague superlatives, marketing transitions, and a tone that sounds like every product launch video at once. None of it is wrong sentence by sentence, which is exactly why it survives a quick read; it is wrong in aggregate, because it carries no information about who is speaking.

The fix is the same instrument used everywhere else in this curriculum: encode the rule where the agent always sees it. A voice section in the project's harness or skill — sentence-length range, first or second person, contraction policy, how claims are hedged, a banned-phrase list, and two or three paragraphs of approved writing as a reference — does more for narration quality than any amount of per-prompt pleading. The Huashu skill takes the same approach for visuals, maintaining an explicit list of slop elements that are banned unless the brand itself uses them; the narration equivalent is a banned-phrase list plus a positive reference sample.

Reading the script aloud before generating audio is a cheap, old discipline that survives the move to synthetic voices. Sentences that are fine on the page — long subordinate clauses, three-item lists inside three-item lists — fall apart when spoken, and a synthetic voice will read them with perfect, oblivious fluency. The ear catches the problem in seconds. Australian and standard English spelling and phrasing should also be settled at this layer, because the TTS model will pronounce whatever it is given.

Make the practical case before the ethical one, because both matter. Synthetic narration is what makes the one-source, three-outputs model maintainable: when the source changes, the narration regenerates in minutes, in the same voice, with no studio booking and no drift between the script and what was actually said. Captions and transcripts are exact because they come from the script rather than from transcription. A pipeline built on a human narrator is better in some ways — warmth, emphasis, credibility — and dramatically worse at being re-run every time the product changes. Many teams land on a hybrid: synthetic for the frequently-updated material, recorded humans for the flagship pieces.

Then be straightforward about disclosure. The line that matters is viewer expectation: an explainer narrated by an obviously generic presenter voice carries a different implicit claim than a video where a named person appears to speak, or a testimonial. Where a reasonable viewer would assume a human — and would feel misled to learn otherwise — disclose. A short line in the description or end card costs nothing and protects trust, which is the asset these videos exist to build. Voice cloning of real people is a separate, harder line: written consent, scoped to the use, revisited when the use changes.

Keep the regulatory claim conservative and dated. As of June 2026, platform rules and jurisdictional requirements for AI-generated content disclosure differ and keep moving; some platforms require labels for synthetic media in specific categories. The durable advice is to settle a team policy once — when to disclose, what wording, who signs off on voice choices — and to check the destination platform's current rules at publish time rather than relying on what was true last quarter.

There are two distinct passes and they catch different things. The script edit happens before any audio exists, which is when changes are cheapest: cut filler, tighten claims, fix the register, split sentences that will not survive being spoken. The video watch happens after assembly and is mostly about time: pacing, emphasis, and whether the on-screen text and the narration land together. Teams that skip the second pass because 'the script was already approved' ship videos where a dense diagram appears for four seconds while the narration glides past it.

The pacing point deserves the strongest wording because it is the failure no automated gate catches. Lint can find timing overlaps, frame checks can find dead animations, validators can confirm every segment is covered — nothing in the toolchain measures whether a human had time to read the headline before it left the screen. The school's motion article makes the same observation about feature clips: generated motion is reliably technically correct and slightly too fast. Budget a real-time watch for every video, not a scrub.

The honesty item is about generated connective tissue. When an agent writes transitions between beats, it tends to inflate: 'this changes everything', 'as we have seen, the results are dramatic'. Each phrase is small; the cumulative effect is a video that promises more than the source supports, which is exactly the press-release quality this module's summary warns against. The edit removes those claims or scales them back to what the evidence carries.

The structural advantage is worth stating plainly: in a script-first pipeline, the narration text exists before the audio does, so captions and transcripts are derivations rather than transcriptions. Captions generated from the script have no recognition errors; the only work is timing them to the audio segments, which the pipeline already measures for shot durations. The transcript is the script with headings. Both should be packaged with the render as a matter of routine — the school's article on this topic puts captions and narration pacing in the render gate, not in a retrofit, and that placement is the right one.

On-screen text in motion is still text: contrast ratios, minimum sizes at the destination's actual playback size, and reading time all apply. A 28-pixel caption that passes on a desktop preview is unreadable on a phone where most of the audience will watch. The reading-time rule of thumb — long enough to read twice at normal pace — exists because viewers are also listening, glancing away, and reading captions; text that disappears the moment a fast reader finishes it has failed half the audience.

Motion-specific harms need naming even in slide-style explainers: flashing content, rapid full-screen luminance changes, and aggressive parallax can be genuinely harmful for photosensitive and vestibular-sensitive viewers, not merely unpleasant. Rendered MP4s cannot respond to a reduced-motion preference, so restraint has to be designed in; HTML or embedded interactive versions can and should respect prefers-reduced-motion. Module 4 picks this thread up properly for motion inside the product.

Decks deserve their own slide because they are the output with the messiest social life. Articles stay on your site and videos are consumed read-only, but decks get forwarded, presented by other people, and edited the night before a meeting by someone who has never seen your pipeline. The export strategy has to acknowledge that reality rather than pretend everyone will present from the canonical HTML version.

The export options are concrete and current. The HTML deck is the native output: presented from a browser, styled by the same tokens as everything else, regenerated when the source changes. For audiences that need PowerPoint, the Huashu Design toolchain demonstrates the standard worth holding any pipeline to — its export translates the deck's computed styles into actual PowerPoint text frames, so the receiving team can edit the words, rather than receiving images of slides pretending to be a deck. The narrated video version reuses the same beats with the TTS narration from earlier in this module. Stills and PDF cover review threads and documentation. As of June 2026 these export paths are skill- and script-based rather than polished products, so expect to keep a small amount of glue code in the repo.

The governance point matters more than the formats: every export should carry a note saying what it was generated from and when, and the repository should name the canonical version. Editable exports drift the moment they leave — that is their purpose — so the team needs to know which artifact to trust when the deck that comes back no longer matches the video. The answer should always be the source, which is the same answer this module started with.

This trace comes from the school's own production setup: course modules are authored as slide definitions with speaker notes and a per-slide narration script, and a separate video pipeline turns each module into a chapter video using a template library, per-segment TTS, and an automated validator. The numbers of shots and the specific fixes vary by module; the shape of the run is stable and is what the table shows. Present it as a representative trace of a working pipeline, not a benchmark.

The details worth dwelling on are the ones that confirm the module's claims. The script was not written for the video — it was written as course material, and the video pipeline consumed it unchanged, which is the one-source argument made concrete. Shot length was derived from measured narration duration plus breathing room, never shorter than the template's own animation envelope, which is the narration-drives-duration rule. The validator is the automated gate: it checks that every slide of the source is covered by a shot, that no template placeholder text leaked into the output, and that each shot's duration covers its audio — and the convention is zero errors before a human watches it. The pacing problem found in review was fixed by editing one script segment and re-running, not by trimming the video.

Be equally clear about what the table does not show. Building the template library and the pipeline itself was real up-front work, spread over many modules — this is the second-video-is-a-pipeline-question argument that Module 5 takes up properly. And the human review pass does not get cheaper per video: it costs the runtime every time, which is exactly why it is the gate worth protecting when everything around it gets faster.

The exercise is deliberately a writing task with no tooling, for the same reason the module keeps insisting the script is the design: the part of this work that agents do not do well is exactly the part the exercise practises. Choosing what the document is really about, cutting it into beats, deciding what earns a place on screen, and writing narration in the organisation's own register are judgment calls. The generation steps that follow are mechanical by comparison.

The step that participants find hardest, and learn the most from, is writing the on-screen anchors. It forces a decision about what the viewer must see versus what they only need to hear, and it surfaces how much of the source document is connective prose that no output needs. The three word-for-word beats are the voice exercise in miniature: the beats most likely to drift are usually the opening hook, anything making a claim about value, and the close — which is also where press-release tone does the most damage.

If this is run as a group session, have people swap outlines and read each other's narration aloud. Hearing someone else read your words at speaking pace exposes pacing and register problems faster than any silent review, and it previews the experience of hearing a synthetic voice read the same words. The disclosure and accessibility notes at the end are small on purpose; the point is to make answering them a habit that happens at outline time, not at publish time.

Recap by ownership rather than by sequence: humans own the script and the final watch; the agent owns text-to-speech, timing, the timeline, the per-segment visuals, and assembly; the automated gates own coverage, placeholders, and durations. Pacing, register, and honesty remain human judgments, and they remain the difference between an explainer that builds trust and one that merely exists.

The one-source discipline is the idea most worth restating, because it is the one teams break first under deadline pressure. The moment a fix lands in the deck or the MP4 but not in the source, the formats begin to disagree, and the disagreement is always discovered by an audience rather than by the team. The fix is cheap and procedural: name the canonical source, route every fix through it, and regenerate.

Then set up Module 4 as a genuine change of subject. This module and the two before it were about motion as content — videos and decks that get watched. Module 4 is about motion as interface: transitions, micro-interactions, and state changes inside the product, where the questions are duration, easing, and restraint, and where the characteristic agent failure is not press-release narration but decorative animation applied to everything that moves. The instrument is the same — rules encoded where the agent always sees them — but the rules themselves are different, and that is where the course goes next.