A launch video has a narrow job: help someone who has never opened your product understand one useful action and decide whether to learn more. The hard part is not finding a spectacular transition. It is choosing a promise the actual product can keep, then showing the steps that make that promise credible.
Creator 沐阳 (@yyyole) discusses the preparation, shot planning, and division between generated scenes and precise UI motion in a launch-video tutorial on X. This Meydo editorial is an independent analysis, not a translation or a tool walkthrough. The production framework and example below are our own; we have not tested or endorsed the third-party video tool mentioned in the source.
1. Start with the viewer's decision
Write one sentence before opening an editor: “For [specific person], this product helps [specific task] by [visible action].” Then decide where the viewer will encounter the video: a silent social feed, a landing page, a presentation, or an app listing. That context determines whether the opening needs captions, whether the ending needs a URL, and how much time the viewer has to read.
Select one primary action—visit a page, request access, or watch a full demo. Do not ask the launch film to explain every setting. If the product is not generally available, say “join the waitlist” rather than depicting an instant sign-up. A launch video is a claim about the current experience, not a substitute for it.
2. Build a small evidence kit
Collect the approved logo and type, a color reference, a current build identifier, the exact CTA destination, and a screen recording of one completed task. Capture the starting state, the decisive interaction, and the actual result. Use a test account with fictional data; remove messages, names, notifications, and account identifiers that do not belong in public. Keep a short list of claims that the product team can verify in the build.
Mark each asset as real UI, illustrative scene, or editorial text. This classification is more useful than a folder of unlabeled screenshots: it tells an editor what may be stylized and what must remain exact. For a hardware product, use approved photos or footage and label any concept rendering as such. Never turn a proposed capability into a demonstrated feature through editing.
3. Put the proof in the storyboard
Here is an illustrative 42-second storyboard for a fictional task-organizing app. The timings are editorial starting points, not a formula or performance guarantee.
| Time | Visual | What the viewer learns | Source of picture |
|---|---|---|---|
| 0–5s | A crowded project inbox; one task is easy to lose | The problem is missed follow-through | Designed typography and an illustrative setup |
| 5–10s | One sentence identifies the app and the task it solves | Why this product appears now | Approved product name and editorial copy |
| 10–20s | A real recording converts a request into an assigned task | The first meaningful action | Captured product UI |
| 20–31s | The same task moves to a reviewed state, then appears in the team's view | The result is visible, not merely asserted | Captured product UI, with cuts between states |
| 31–37s | A still of the final state with a concise qualification | What the feature does—and does not promise | Real UI plus editable text overlay |
| 37–42s | Logo, accurate availability wording, and one link | What to do next | Approved brand assets |
A row is a production decision: it needs an owner, a verified screen, and a fallback if the feature changes. Cut an unsupported shot rather than filling the gap with a synthetic interface. If 42 seconds feels crowded in a rough cut, remove a beat; do not speed up the UI until it becomes illegible.
4. Give different shots different tools
Generative video can explore atmosphere—a desk, a commute, a human moment—when those images are clearly illustrative and rights are cleared. It is a poor source of truth for labels, menus, prices, and product behavior. For those, record the live interface or animate approved screen assets in a conventional motion editor. If a transition needs movement, move the frame around the real capture rather than asking a model to redraw its text.
A practical shot brief states purpose, duration, aspect ratio, asset source, camera behavior, and prohibitions. For example: “Six-second crop from approved recording of task assignment; static camera, pointer and button remain legible; no invented controls or rewritten text; leave safe space for a caption.” Render a low-cost test of the riskiest shot first. Review it at phone size without sound before producing the rest.
5. Lock the specs, then review the claims
Choose a working master—for example, 1920 × 1080 at a project frame rate agreed with your editor—and export platform versions only after checking each crop. A 9:16 version is a new composition problem, not simply a center crop: keep the actionable button and caption visible, or rebuild the layout. Add burned-in captions if the placement is commonly watched muted; also retain an editable caption file for correction and localization. Check contrast, reading time, and whether the final URL remains on screen long enough to recognize.
Review with three passes. Product: do screens, labels, and availability match the current build? Rights and safety: do you have permission for footage, music, voices, logos, and any depicted people; are private details absent? Distribution: do thumbnail, first seconds, captions, CTA, and destination page tell the same story? Have someone unfamiliar with the product describe what happened after a single viewing. Treat confusion as an edit note, not a viewer failure. Measure later against your chosen action rather than assuming video alone raises adoption.
6. Where Meydo fits
For a product such as Meydo C1, the editorial opportunity is to show one grounded interaction in context—not a montage of imagined AI powers. Meydo's public product page describes a compact device with a flip camera; any video of its software workflow should be recorded or verified against the current experience, and any pre-production visualization should be identified. A scene of someone noticing a question, using the device, and receiving a clearly scoped answer can communicate more than several unverified feature captions. The same rule applies to any launch: the most persuasive shot is often the one that survives a fact-check.
Source and credit: Inspired by 沐阳 (@yyyole), “如何用 AI 快速搞定产品 Launch Video？一套从0-1的保姆级教程！” on X. We credit the creator's discussion of launch-video planning; this independent Meydo analysis does not reproduce the tutorial, images, video, promotion, or endorsement.
