Choose the deliverable before choosing an animation tool
A product walkthrough, an interface response and an explanation of a mechanism are different animation jobs. They can share a visual language, but their outputs have different requirements. A movie explains a fixed sequence. An interface must react to the current user and actual application state. A concept animation must make a relationship understandable, including when the viewer pauses it. Treating all three as a single “generate video” request leaves essential decisions unresolved.
This guide uses a fictional community repair station that accepts booking requests. Residents choose a time, describe an item and review a summary. The proposed deliverables are a 45-second landscape walkthrough, a separately composed portrait version and a small confirmation animation on the booking page. These are production examples and acceptance instructions, not claims that a video has already been rendered or a real booking has been submitted.
Write a delivery brief with the intended audience, the action they should understand, the placement, language, aspect ratio, duration, sound requirements, caption requirements, approved assets and editable source files. Name the final formats as well. A portrait version needs its own information layout: cropping the sides of a desktop recording may remove the very field being explained. A success response needs readable status text; a looping decoration cannot establish that the server accepted a request.
Route one: build a repeatable product video with Remotion
Remotion is a useful reference when a team can maintain a React-based video project and needs repeatable changes to copy, data or language. Review the repository, documentation, dependency lockfile and the instructions for the version actually installed. Source availability does not mean every organizational or commercial use has identical terms; check the current Remotion license for the intended use. Do not infer a license from another JavaScript project's license or from the existence of a public GitHub repository.
Start with five storyboard cards for the repair-station film. Seconds 0–6 establish that a visit requires a booking. Seconds 6–16 show choosing a time. Seconds 16–28 explain the item description. Seconds 28–38 show reviewing the summary. Seconds 38–45 identify the location and cancellation route. Each card needs a focal object, on-screen text, optional narration, an entry state and an exit state. Approve the still frames before adding movement. If the still frame is confusing, a transition rarely fixes the information problem.
At a chosen 30 frames per second, 45 seconds is 1,350 frames. The proposed boundaries are 0, 180, 480, 840, 1,140 and 1,350. Keep a single timing sheet so a script revision does not leave separate duration values out of agreement. A Composition identifies settings such as dimensions, frame rate and duration. Existing projects often use Sequence with from and durationInFrames to place content. Its child timeline differs from the whole composition timeline. Current documentation also describes newer timing patterns, so follow the API recommended for the project's pinned version rather than treating an older tutorial as a universal template.
Make the same frame reproduce the same picture. Settle the input data, image files and decorative randomness instead of depending on a clock or on changing remote content. For the example, invent names and booking identifiers; do not capture residents' contact details. Use short caption units with enough reading time. Review Chinese typography and English line breaks separately. A longer English sentence can change the height of a card, even when it communicates the same idea. Record or approve narration before making the final timing adjustments.
Review the opening, every handoff and the ending in the preview. Use the project's established rendering script or the official rendering entry point to export the approved composition. For a project whose composition really is named RepairBooking, an illustrative command is npx remotion render RepairBooking out/repair-booking.mp4. Confirm the identifier, dependencies and output location before running it, and retain any previous approved export. Render a small section first to catch asset or font problems, then export the full film. A preview screenshot is not a substitute for playing the exported media.
Deliver the editable project, approved content input, asset and font notes, rendering settings and final playable file together. This makes the next schedule change a controlled edit instead of a complete reconstruction. A video-production skill may help organize rules or tasks, but a SKILL.md file does not itself supply a renderer, dependencies or sufficient machine resources.
Route two: interface motion and Lottie have different responsibilities
For a booking button, design the states before designing a flourish. Idle should explain the action. Pending should prevent accidental repeat submissions and provide text feedback. Success should identify the outcome and the next step. Failure should provide a recoverable route where appropriate. Application state must control the result; the end of an animation cannot be used as proof that a request succeeded. Keyboard focus also needs a deliberate destination after the interface changes.
For a simple hover response, fading message, expanding panel or loading indicator, first assess whether existing CSS and JavaScript are sufficient. Describe the trigger, duration, interruption behavior and final state beside the component. In a React, Vue or Svelte project, connect playback and cleanup to that framework's component lifecycle. Avoid adding listeners or animation instances every time a panel opens. Re-entering the page should not double the speed or leave an invisible animation consuming resources.
Lottie is a separate route for playing compatible animation data. The lottie-web repository provides a documented implementation and identifies an MIT license. Animation assets and fonts still need their own permission checks. An approved compatible JSON asset can be evaluated directly. For an After Effects authoring workflow, Bodymovin is a common export route, with feature compatibility to check. An arbitrary HTML interaction, CSS transition or SVG illustration does not become Lottie data merely by changing its extension. After Effects is not required just to play an existing JSON file.
For the example confirmation icon, specify an 80-by-80 container, one playback and a meaningful resting frame. Retain a static fallback. Inspect whether the data references additional images, contains unused layers or includes a longer timeline than the component needs. Compare important frames after optimization: a smaller file that breaks a mask or removes essential text is a regression. Judge loading behavior and responsiveness on the target devices, rather than repeating a claim that every vector animation is small or fast.
A failed player download should leave a clear success message on the page. Reduced-motion preferences should still allow the complete task to be understood and performed. Test that route explicitly; do not hide the only confirmation together with the moving icon. When a visual loop is decorative, consider whether it needs to continue while off screen. When it communicates progress, ensure its text remains accurate rather than implying a measured percentage the application does not know.
Route three: turn an AI storyboard into a real film
An AI-generated storyboard is an intermediate artifact. Give the assistant enough constraints to produce something reviewable: a 45-second duration, five shots, one decision per shot, fictional booking data, a defined audience and a ban on unsupported performance numbers. Ask for a timing sheet, narration, on-screen copy, required assets and unresolved questions. A human should correct the business process before deciding how to implement the animation in code or an editing application.
A usable initial request is: “Plan a 45-second explanation of a community repair-station booking. Cover time selection, item description and summary review. For every shot give the duration, caption, visual state and required assets. Return the storyboard first. Do not download assets, create real bookings or publish anything. Mark missing information instead of inventing it.” This request keeps the first output small enough to inspect and makes later execution depend on approved material.
Add the shot durations and confirm that they total 45 seconds. Look for repeated introductions, a missing cancellation route and text that has no time to be read. Separate a realistic screen demonstration from an illustrative diagram; the diagram should not suggest that an unimplemented feature exists. Freeze the approved storyboard as the production reference. If narration or a required field changes later, update the timing sheet and dependent captions together.
Choose the rendering or editing environment that the team can actually operate. A skill with “video” in its name does not establish that a rendering engine, model allowance, account or media license is available. Record those prerequisites before scheduling production. If the chosen tool cannot export the required format, resolve that limitation while the project is still a storyboard instead of discovering it at delivery time.
Explain a concept with a short, inspectable sequence
A concept animation should expose the rule being explained. To illustrate booking conflicts, show three request cards and two available time slots. First show two requests selecting the same time. Then show the conflict message. Finally show a person choosing another available slot. Movement represents those stated steps; it must not imply that the service automatically reallocates people if that behavior does not exist.
Prepare a still frame for each stage, with labels that remain understandable when paused. Check the explanation with someone unfamiliar with the system before turning it into an eight-to-twelve-second loop. This exposes ambiguous arrows and unexplained colors while revision is cheap. Use consistent labels across the walkthrough and the concept sequence so viewers do not have to learn two vocabularies. If order matters, show the order with both position and text rather than relying on color alone.
Choose a delivery format for its placement. GIF can be convenient for a short embedded loop, but its color, size and lack of ordinary audio support need consideration. MP4 is generally a more appropriate candidate for a narrated film. Verify any transparency requirement against the actual encoding and player; an MP4 extension alone does not promise an alpha channel. When the explanation needs choices, keyboard interaction or branches, keep an accessible interactive implementation. A recording can supplement that interaction without replacing it.
For every output, record dimensions, duration, file size and the environment in which it was played. Keep the editable original. If the concept later changes from manual rescheduling to automatic allocation, revise the diagram, narration and screen demonstration together. Otherwise individually polished assets can give contradictory instructions.
Verified SkillPI associations and their exact jobs
The directory inspection for this article did not establish a matching, verifiable Remotion or Lottie production-skill page for the names listed in the source article. Consequently this guide does not manufacture six “must-install” links. The code-video and player routes above use the original projects' documentation. New catalog entries can be assessed later against those specific jobs, including their dependencies and actual outputs.
Canvas Design fits the preparation stage when an original static storyboard board or visual-direction artifact is useful. Supply dimensions, intended use, approved materials and a writable output location. Review its PDF or PNG visually before approving the look. Its role here is static design, not generating MP4, implementing interface components or exporting Lottie JSON. Do not install it merely to satisfy an arbitrary association count.
Webapp Testing fits local verification of the booking-page interaction. Establish the runnable site, startup command, port, test data and relevant Python/Playwright environment. Observe the page, exercise the relevant paths and retain screenshots or console clues for issues. This does not prove real appointment delivery, backend correctness or the quality of an exported video. Source verification, static scanning and runtime evidence are distinct signals on a skill page; a reachable repository is not a general safety certificate.
Practical handoff and revision example
The repair-station handoff can contain storyboard.md, an approved content file, an assets directory, a timing sheet, the video project and an exports directory. These are suggested organizational choices, not files generated by this article. Add a short note identifying which export is approved and which is a review copy. Name the two language versions clearly so a later editor cannot accidentally replace the Chinese narration with English captions while retaining the old timing.
For a single revision, such as changing the cancellation instruction, identify every affected artifact first. Edit the approved copy, revisit the ending shot's reading time, update narration if present and render a review version. Compare the ending and the transition into it, then play the complete export to catch an unintended duration change. On the website, verify that the live instruction and confirmation text still agree with the video. This focused change process is more reliable than regenerating every shot from a loosely remembered prompt.
Troubleshooting by the layer that failed
If preview text looks correct but the export loses characters, examine font availability and loading in the rendering environment. If a scene starts black or a caption disappears early, inspect timeline boundaries and total frames. If only the portrait version clips content, revisit that composition's layout. When audio drifts, compare the narration duration, media trimming and frame-rate assumptions before changing the speed of the entire track. Retain the failed range and log so the issue can be reproduced with a small render.
If Lottie differs from the design preview, check player version, rendering mode, external assets and unsupported features. A simpler drawing or static fallback may be a better response than adding another player blindly. If motion continues after navigation, inspect lifecycle cleanup. If reduced motion removes the only visible outcome, fix the information design. Change one layer at a time; simultaneously rewriting the JSON, replacing the player and restructuring the component makes the successful change difficult to identify.
Before approval, ask another reader to follow the whole explanation. Check the actual title and captions, the input and outcome shown on screen, the presence of all three production routes and any numbers that might be mistaken for measured results. Play the final exported files, including the start, each transition and the end. For the website, exercise success, failure, retry, keyboard operation and reduced-motion behavior. Record observations and devices actually covered. A planned check must remain a planned check until it has been performed.
FAQ and sources
Can a non-developer begin? Yes: a clear storyboard, copy and asset inventory are valuable first outputs, but someone still needs to maintain a code template if that route is chosen. Is a Remotion skill the same as Remotion? No: task instructions and the runtime have separate roles. Does every web animation need Lottie? No: evaluate the simplest maintainable implementation for the state change. Does playing existing Lottie data require After Effects? No; authoring and playback are separate steps. Is an AI storyboard a finished film? Only actual exported media, played and reviewed, completes that deliverable. Can the Chinese version simply be translated? Review pacing, narration and layout separately for English.
The production references are the official Remotion repository and its timing and rendering documentation, the lottie-web repository and MDN's reduced-motion guidance. The repair-station examples are original proposed workflows, not tool benchmarks or accounts of executed tests. Both original-language sources and the reference addresses remain in the editorial record. The SkillPI links above are limited to their stated static-design and local-web-testing roles.