create-onboarding-video

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Onboarding Video

创建引导视频

Produce a short, punchy iOS onboarding video in Remotion that showcases one feature working. Output is meant to feel like an App Store preview zoomed into the moment that proves the feature works — not a tutorial, not a screen recording, not a marketing reel.

使用Remotion制作一段简短有力的iOS应用引导视频，展示某一项功能的运行效果。最终产出应类似App Store预览视频，聚焦于能证明功能有效的关键瞬间——而非教程、屏幕录制或营销宣传片。

What you make

产出内容

Length: short. 3–8 seconds per onboarding screen, stitched together. Whole video rarely exceeds ~30s.
Style: UI-first, never the whole screen. Each beat shows a piece of the feature in action — a single button being tapped, a toggle flipping, a row reordering, a sheet sliding up, a chart filling in — animated with nice UI-like transitions (springs, slides, scales, crossfades, masked reveals, shared-element swaps).
What "pieces" means: crop, mask, or extract just the relevant component from the supplied still — the card, the input field, the tab bar, the empty state turning into a filled state. The rest of the UI is omitted, blurred, or implied by a tinted background. We are showcasing what the feature does, not what the whole app looks like.
Tone: to the point. Each beat communicates one thing the feature does.
Output: a Remotion project that renders to MP4 (and optionally a portrait variant for App Store previews).

时长： 简短。每个引导画面为3–8秒，拼接后整个视频时长很少超过约30秒。
风格： 以UI为核心，绝不展示全屏。每个片段展示功能运行中的局部——单个按钮被点击、开关切换、行重新排序、面板滑出、图表填充——搭配类UI风格的流畅转场动画（弹簧动画、滑动动画、缩放动画、交叉淡入淡出、遮罩揭示、共享元素切换）。
何为“局部”： 从提供的静态截图中裁剪、遮罩或提取仅相关的组件——卡片、输入框、标签栏、空状态变为填充状态的部分。UI的其余部分将被省略、模糊处理，或通过着色背景暗示。我们要展示的是功能的作用，而非整个应用的外观。
基调： 直奔主题。每个片段传达该功能的一项作用。
输出： 一个可渲染为MP4格式的Remotion项目（可选生成适用于App Store预览的竖屏版本）。

Workflow

工作流程

Follow this loop. Do not skip the intake — guessing at flows produces generic videos.

遵循以下循环步骤。请勿跳过需求收集环节——猜测流程会导致视频过于通用。

1. Intake — ask for stills + intent

1. 需求收集——索要截图与意图

For each onboarding screen the user wants to feature, collect:

Still shots (screenshots) of the screen — ask for 2–4 stills per screen so you can show interaction states:
- resting state
- mid-interaction (button pressed, field focused, sheet halfway up, etc.)
- result state (data loaded, success, next screen)
- any variant worth showing (empty vs. filled, light vs. dark, etc.)
What the feature is — one or two sentences on what this screen does for the user and what makes it feel good. This drives which detail to zoom into.
Order — the sequence of screens in the onboarding flow.
Optional: brand color / accent, font if non-standard, target aspect ratio (default 1080×1920 portrait for iOS), end-card text/CTA.

Use

AskUserQuestion

when the user is vague. Don't start rendering until you have stills + intent for every screen.

针对用户想要展示的每个引导画面，收集以下信息：

屏幕静态截图——每个画面索要2–4张截图，以便展示交互状态：
- 初始状态
- 交互中状态（按钮按下、字段聚焦、面板半滑出等）
- 结果状态（数据加载完成、操作成功、进入下一屏幕）
- 任何值得展示的变体（空状态 vs 填充状态、浅色模式 vs 深色模式等）
功能说明——用1-2句话说明该画面为用户提供的功能，以及其亮点。这将决定需要聚焦展示的细节。
顺序——引导流程中各画面的排列顺序。
可选信息： 品牌颜色/强调色、非标准字体、目标宽高比（默认iOS竖屏1080×1920）、结尾卡片文字/行动号召（CTA）。

当用户描述模糊时，使用

AskUserQuestion

询问。在收集到所有画面的截图与意图前，请勿开始渲染。

2. Plan the shots

2. 镜头规划

For each screen, identify the single piece of the feature that proves the feature works — the tapped button, the filling progress ring, the row that gets swiped, the field that auto-completes — and how it transitions to the next beat. Never animate the whole screen. Sketch the timeline (focal element → motion → result → next focal element) before writing components. Prefer:

isolating/cropping/masking the relevant component out of the still and placing it on a tinted background
showing the interaction itself (tap ripple, drag, focus, state change) rather than just the static layout
shared-element transitions between beats (the button on beat 1 becomes the header on beat 2)
subtle parallax / depth on layered elements
spring-based motion over linear easing

针对每个画面，确定能证明功能有效的单个UI局部——被点击的按钮、填充的进度环、被滑动的行、自动补全的字段——以及如何过渡到下一个片段。绝不动画全屏内容。在编写组件前，先勾勒时间线（聚焦元素→动画→结果→下一个聚焦元素）。优先选择：

将相关组件从静态截图中分离/裁剪/遮罩出来，放置在着色背景上
展示交互过程本身（点击波纹、拖拽、聚焦、状态变化），而非仅展示静态布局
片段间使用共享元素转场（片段1的按钮变为片段2的标题）
分层元素添加微妙视差/深度效果
基于弹簧的动画，而非线性缓动

3. Build with Remotion

3. 使用Remotion构建

Always invoke the
remotion-best-practices
skill before writing Remotion code. When you do, include this guidance in your prompt to it:

Build a short iOS-app onboarding video. Never render the whole screen — each beat must show a piece of the feature in action: an isolated/cropped/masked UI component (button, card, row, sheet, field, chart, etc.) animating through the interaction that demonstrates what the feature does. Place it on a clean tinted background; the rest of the app chrome is omitted or implied. Use nice UI-like transitions — springs, masked reveals, shared-element morphs, crossfades, parallax — to move between beats. Prefer
spring()
over linear interpolation, use
<Sequence>
to chain beats, and keep each beat short (90–240 frames at 30fps). Stills go in
public/
and load via
staticFile()
; crop them with CSS
clip-path
/
overflow: hidden
/ absolute positioning to extract the focal element.

Project conventions:

Source stills in
```
public/<screen-name>/<state>.png
```
.
One
```
<Composition>
```
per onboarding flow; one
```
<Sequence>
```
per screen-beat inside it.
Components in
```
src/scenes/
```
, shared transitions in
```
src/transitions/
```
.
Default 30fps, 1080×1920 portrait; expose width/height as props so the same scenes render landscape if asked.

**在编写Remotion代码前，务必调用

remotion-best-practices

技能。**调用时，在提示中包含以下指导：

制作一段简短的iOS应用引导视频。绝不渲染全屏内容——每个片段必须展示功能运行中的局部：一个被分离/裁剪/遮罩的UI组件（按钮、卡片、行、面板、字段、图表等），通过动画展示能体现功能作用的交互过程。将其放置在简洁的着色背景上；应用的其余框架元素将被省略或暗示。使用类UI风格的流畅转场——弹簧动画、遮罩揭示、共享元素变形、交叉淡入淡出、视差——实现片段间的过渡。优先使用
spring()
而非线性插值，使用
<Sequence>
串联片段，每个片段保持简短（30fps下为90–240帧）。截图放入
public/
目录，通过
staticFile()
加载；使用CSS
clip-path
/
overflow: hidden
/ 绝对定位裁剪截图，提取聚焦元素。

项目规范：

源截图存放于
```
public/<screen-name>/<state>.png
```
。
每个引导流程对应一个
```
<Composition>
```
；每个画面片段对应其中一个
```
<Sequence>
```
。
组件存放于
```
src/scenes/
```
，共享转场效果存放于
```
src/transitions/
```
。
默认30fps，1080×1920竖屏；将宽/高设为props，以便同一场景可按需渲染为横屏。

4. Iterate

4. 迭代优化

Render a preview, show it to the user, and ask which beats need to be slower, faster, or restaged. Treat the first render as a draft.

渲染预览版本，展示给用户，询问哪些片段需要调整速度或重新设计。将首次渲染视为草稿版本。

Operating rules

操作规则

Stills are required. If the user hasn't provided screenshots, stop and ask. Do not invent UI from descriptions.
Pieces of the UI, not the whole UI. If you catch yourself rendering a full-screen mockup, stop and crop down to the component that carries the beat. The viewer should see the feature in action, not a tour of the app.
One feature per video. If the user describes 5 unrelated features, propose splitting them into 5 videos.
Show, don't narrate. No voiceover, no big text overlays explaining the feature — let the UI motion carry it. A short caption per beat is fine.
Captions are visible for the entire beat. Each beat's supportive caption fades in within the first ~10–14 frames of the beat and remains on screen for the whole sequence. Do not delay caption entry to mid-beat or fade it out before the beat ends — the viewer should be able to read the line the entire time the focal UI is on screen. Let the scene-level crossfade between beats carry the caption swap.
Captions rise in from below. They start ~60px under their rest position with opacity 0 and slide up + fade in together (strong UI ease-out, e.g.
```
Easing.bezier(0.16, 1, 0.3, 1)
```
). Never have a caption appear in place or drop in from above — the upward motion is part of the visual identity.
Captions live at the top, always at the same spot. Anchor every caption to a fixed top-of-frame position (e.g. ~100px from the top, horizontally centered) and reuse that position across every beat. Never put a caption below the focal UI, never let it drift from beat to beat. Reserve a consistent top "caption band" (~200–240px) and lay the focal slice out below it. Build a single
```
TopCaption
```
wrapper component and use it everywhere — don't position captions inline per scene.
Captions are big. Default font size for a 1080-wide canvas is around 54px, weight 700, with a
```
maxWidth
```
so long lines wrap instead of running off-frame. They are headline-size callouts, not subtitle-size labels.
Same caption across connected beats stays put. When two consecutive beats are conceptually parts of the same moment and share the exact same caption text (e.g. one beat shows tapping the day, the next shows the form opening — same headline applies to both), the caption must not re-animate at the cut. It rises and fades in once on the first beat, then on every continuation beat is rendered with
```
staticEntry
```
(or equivalent: instant full opacity, rest position, no slide). The two captions composite identically during the scene crossfade so the viewer perceives a single caption that persists across the cut, not a flicker. Only use this when the text is exactly the same — if the caption changes at all between beats, let the new one rise-and-fade-in normally so the change reads.
Cursor leads every tap. If a beat shows a tap, click, or selection, a visible cursor (
```
Pointer
```
) must appear, move along a path, and arrive on the target before the tap ripple fires. No teleporting, no jump-cut taps. The cursor's motion is what tells the viewer where the action is about to happen — the tap ripple alone is not enough. Beats that are purely illustrative (highlighting a feature with glow rings, animating a static state, showing a result land) do not require a cursor; let glow / motion carry the eye instead. Decide per beat: interactive → cursor leads; illustrative → no cursor. For the cursor component itself and a copy-pasteable usage pattern, load
```
resources/cursor-component.md
```
only when you are about to author or modify a beat that has a tap.
Cursor fades in at center, then moves in one straight line to the target. The first interaction in a beat is always:
1. Fade in at the visual center of the focal area (slice center / container center — whatever the viewer's eye is parked on for the beat). The pointer materialises in place; it does not enter from off-frame.
2. One single straight move from that center to the interaction point. Direction is free — vertical, horizontal, diagonal are all fine, as long as it's one straight segment. Both
```
x
```
  and
```
y
```
  may change together (this is the only place a diagonal is allowed). Use a single decelerating ease (e.g.
```
Easing.bezier(0.16, 1, 0.3, 1)
```
  ) so the cursor feels guided, not flung.
Multiple taps on the same UI: the pointer stays visible and glides from one to the next. When a single beat has two or more interactions on the same UI (e.g. tapping a segment then tapping the Create button on the same form), do not reset the pointer between taps. The pointer fades in once at center, glides straight to the first target, taps, then glides directly from that target to the next target in one continuous straight segment, taps, and so on. Only after the last interaction does it fade out. Never fade out + fade in at center between taps on the same UI — that breaks the sense of a single user driving the action. Each segment between consecutive interactions is itself a single straight line (any direction allowed, same diagonal-OK rule as the entry).
Different UI / new screen: reset. If the next interaction lands on a different UI (a new screen, a different form, a different beat altogether) the pointer does fade out and the next interaction starts with a fresh fade-in at center. The reset is what tells the viewer "we're somewhere new now."
Forbidden: entering from off-frame edges, multi-segment paths within a single move, curves, zig-zags, intermediate keyframes that bend the trajectory, fading the pointer out + back in between taps on the same UI. The motion should feel like the user's finger appearing where the eye already is and gliding straight to each action in turn — not like a hand entering from off-screen, and not like the cursor blinking out between every tap on the same form.
Match the app's design language. Use the colors, corner radii, and type from the supplied stills; don't restyle them.
Delegate to
remotion-best-practices
. It is the source of truth for how to write Remotion code — invoke it any time you're about to author or modify a composition, scene, or transition.

必须提供截图。若用户未提供截图，请停止操作并索要。请勿根据描述凭空设计UI。
展示UI局部，而非全屏。若发现自己在渲染全屏原型，请停止并裁剪到能承载核心信息的组件。观看者应看到功能的运行过程，而非应用游览。
每个视频聚焦一项功能。若用户描述了5个不相关的功能，建议拆分为5个视频。
用展示替代解说。不添加旁白，不使用大文本叠加层解释功能——让UI动画传递信息。每个片段可搭配简短说明文字。
说明文字全程可见。每个片段的辅助说明文字应在片段开始后的约10–14帧内淡入，并在整个片段期间保持显示。请勿延迟说明文字的出现时间至片段中途，或在片段结束前淡出——观看者应在聚焦UI显示的全程都能阅读说明文字。通过片段间的场景级交叉淡入淡出实现说明文字的切换。
说明文字从下方升起。初始位置为最终位置下方约60px处，透明度为0，随后同时向上滑动并淡入（使用强烈的UI缓出效果，例如
```
Easing.bezier(0.16, 1, 0.3, 1)
```
）。绝不让说明文字直接出现在目标位置或从上方落下——向上的动效是视觉标识的一部分。
说明文字始终位于顶部固定位置。将所有说明文字锚定到帧顶部的固定位置（例如距顶部约100px，水平居中），并在所有片段中复用该位置。绝不将说明文字放在聚焦UI下方，也不要让其在片段间偏移。预留一个固定的顶部“说明文字区域”（约200–240px），将聚焦片段布局在该区域下方。构建一个统一的
```
TopCaption
```
包装组件并在所有场景中使用——不要为每个场景单独定位说明文字。
说明文字字号较大。在1080宽度画布上，默认字号约为54px，字重700，设置
```
maxWidth
```
使长文本自动换行而非超出帧范围。它们是标题大小的提示文字，而非字幕大小的标签。
连续相关片段的相同说明文字保持固定。当两个连续片段在概念上属于同一时刻且使用完全相同的说明文字（例如一个片段展示点击日期，下一个片段展示表单打开——同一标题适用于两者），说明文字在切换时不得重新动画。它在第一个片段中升起并淡入一次，随后在所有后续片段中使用
```
staticEntry
```
（或等效方式：立即完全显示，处于最终位置，无滑动动画）渲染。在场景交叉淡入淡出期间，两个说明文字应完全重合，让观看者感知到单个说明文字在片段切换时持续存在，而非闪烁。仅当文字完全相同时使用此规则——若片段间说明文字有任何变化，让新的说明文字正常升起并淡入，以便用户注意到变化。
每次点击需有光标引导。若片段展示点击、单击或选择操作，必须显示可见光标（
```
Pointer
```
），沿路径移动，并在点击波纹触发前到达目标位置。禁止瞬移、跳切式点击。光标移动是告知观看者即将发生操作的关键——仅靠点击波纹是不够的。纯演示性片段（用发光环突出功能、动画展示静态状态、展示结果加载完成）无需光标；让发光效果/动画引导视线即可。针对每个片段做出判断：交互式→光标引导；演示性→无光标。如需获取光标组件本身及可复制粘贴的使用模式，仅在准备编写或修改包含点击操作的片段时加载
```
resources/cursor-component.md
```
。
光标从中心淡入，然后沿直线移动到目标位置。片段中的首次交互流程始终为：
1. 在聚焦区域的视觉中心淡入（片段中心/容器中心——即观看者在该片段中视线聚焦的位置）。光标在该位置显现；不得从帧外进入。
2. 从中心沿单一直线移动到交互点。方向不限——垂直、水平、对角线均可，只要是单一直线段。
```
x
```
  和
```
y
```
  坐标可同时变化（这是唯一允许对角线移动的场景）。使用单次减速缓动（例如
```
Easing.bezier(0.16, 1, 0.3, 1)
```
  ），使光标移动看起来流畅自然，而非生硬甩动。
同一UI上的多次点击：光标保持可见并在目标间滑动。当单个片段在同一UI上有两次或多次交互（例如先点击某分段，再点击同一表单上的“创建”按钮），请勿在点击间重置光标。光标在中心淡入一次，沿直线滑动到第一个目标，点击，然后从该目标直接沿单一直线段滑动到下一个目标，点击，依此类推。仅在最后一次交互完成后才淡出光标。绝不在同一UI的多次点击间淡出再淡入光标——这会破坏用户连续操作的感知。连续交互间的每个移动段本身都是单一直线（方向不限，遵循与入场相同的对角线允许规则）。
不同UI/新屏幕：重置光标。若下一次交互位于不同UI（新屏幕、不同表单、全新片段），光标需淡出，下一次交互从中心重新淡入开始。重置操作告知观看者“我们现在进入了新场景”。
禁止操作： 从帧外边缘进入、单次移动中包含多段路径、曲线、锯齿形、弯曲轨迹的中间关键帧、同一UI多次点击间淡出再淡入光标。光标移动应让观看者感觉像是手指出现在视线已聚焦的位置，然后依次直接滑动到每个操作点——而非从屏幕外伸入的手，也不是同一表单每次点击间闪烁消失的光标。
匹配应用的设计语言。使用提供截图中的颜色、圆角半径和字体；请勿重新设计样式。
委托给
remotion-best-practices
。它是编写Remotion代码的权威指南——任何时候准备编写或修改合成、场景或转场效果时，都应调用它。

When in doubt

存疑时

Ask. A 10-second clarifying question saves a 2-minute render that misses the point.

询问用户。一个10秒的澄清问题，能避免产出一个偏离需求的2分钟渲染视频。