如何制作讲解视频：实战工作流

01

1. 明确讲解视频必须完成什么任务

从应该在查看器中发生的更改开始，而不是从产品功能列表开始。一个实用的讲解视频将一个人从一个可识别的问题转移到对如何产生结果的清晰理解。该声明为该项目提供了界限。如果事实、动画或过渡不有助于产生该更改，则属于另一个视频、帮助文章或视频周围的页面。

用五个领域测试范围：查看器、问题、机制、证明和下一步行动。机制很重要，因为没有解释的承诺感觉像广告。证明很重要，因为没有可见结果的解释仍然是抽象的。下一个行动很重要，因为观众需要知道如何处理他们的新理解。在选择工具或视觉风格之前，用通俗易懂的语言写下所有五个。

• 观众：说出特定情况下的角色，而不是小型企业等广泛的市场。
• 问题：描述观众已经从工作或日常生活中认出的摩擦时刻。
• 机制：说明流程中的哪些变化，以及为什么这种变化解决了问题。
• 证明：选择一个屏幕、示例、结果或序列，供观众自己检查。
• 下一步行动：要求一个具体步骤来延续故事，而不是三个相互竞争的CTA。

一个快速的自我检查是从制作需求中删除产品名称。如果剩下的句子仍然解释了一个有用的前后过程，那么范围可能很强大。如果它转化为创新、无缝或强大等词，该项目有一个定位声明，但还没有解释。收紧机制，直到其他人可以在不重复你的营销文案的情况下描述它。

02

2. 选择源素材、受众和投放位置

讲解视频可以从文章、PDF、脚本、产品页面、PRD、销售甲板或简短的提示开始。这些输入不等价。完成的脚本控制着口语序列，但可能缺乏视觉证据。PRD包含精确的行为，但通常包含首次观看者不需要的细节。产品页面包含好处和证明，但其部分顺序是为滚动而不是线性查看而设计的。

在提取材料之前，决定视频将在哪里显示。登陆页面讲解视频对没有读过页面的人来说一定有意义。入职视频可以假设观众有一个帐户，并可能显示确切的界面标签。销售跟进可以解决已知的异议。社交剪辑在第一秒钟需要一个可见的前提，因为周围的环境很弱。安置会改变开头和所需的解释量。

• 记录观众已经知道的东西，这样开场就不会重复明显的类别教育。
• 在构建场景之前，请命名通道和宽高比，即使该比例在制作需求后可能会发生变化。
• 列出任何需要所有者批准的界面、法律、医疗、财务或产品声明。
• 保留用于数字、引文、UI标签和产品行为的确切来源段落的链接。

03

3. 制作一份有证据支持的制作需求

制作需求是防止昂贵的误解最便宜的地方。它应该说明观众、观看上下文、单一承诺、机制、证明、CTA、时长、语言、声音、长宽比、视觉系统、所需场景、禁止的声明和最终批准者。一个好的制作需求足够具体，以至于两个创作者可以制作出可识别的相似故事，同时仍然为视觉工艺留出空间。

实践运行要求提供大约 60 秒的关于共享支持收件箱的 SaaS 解释。这个故事必须显示重叠的回复、路由规则、有组织的渠道，以及创建第一个规则的最终行动。设置使用了英语和Adam Deep的声音。最初的请求使用了9:16，因为它一开始是一个以社会为导向的想法，TapVid在全面运行前显示了180学分的估计。

• 观众和情况：谁在观看，他们在哪里遇到视频，以及他们已经了解了什么。
• 信息和机制：一个承诺加上使承诺可信的过程。
• 证据包：已批准的产品屏幕、源URL、确切标签、编号和索赔所有者。
• 生产限制：持续时间、比例、声音、品牌颜色、字幕需求和禁止的视觉处理。
• 审批门：谁签署大纲、脚本、故事板、第一次剪辑和最终导出。

不要在经过打磨的语言中隐藏不确定性。如果号码未经验证，请将其标记为不可用或将其删除。如果工作流程因计划而异，请说明素材代表哪个计划。如果产品经常更换，请记录日期和版本。这些细节使制作需求更容易审查，并保护最终视频不暗示观察到的测试结果是普遍的保证。

04

4. 设定合理时长和信息预算

运行时是一种信息限制，而不是质量分数。一个60秒的产品讲解视频通常可以确定一个问题，通过几个节拍揭示一个机制，展示一个证明时刻，并要求一个动作。它不能教授每个配置选项。90秒的版本可以包含第二个示例或更刻意的证明序列。两分钟的解释可以支持一个技术概念，但前提是每个额外的场景都值得花时间。

字数公式是规划工具，而不是计时保证。声音、句子长度、不熟悉的术语、停顿和萤幕阅读都会影响节奏。当包含产品名称和首字母缩写词时，140字的草稿可能会感觉很匆忙，而155字的对话草稿听起来可能很舒服。以自然的速度录制粗略的阅读，然后留出时间进行视觉理解，而不是加快声音来拯救超大的脚本。

• 为查看者读取重要的界面标签、数字或比较状态的预算秒数。
• 留一个小时间边距，因为翻译版本可能会扩展或需要不同的换行符。
• 在压缩核心机制或支持它的证据之前，先剪掉次要示例。
• 保持CTA的可见性足够长，以便阅读和操作；不要将其视为端卡闪光。

05

5. 先写口播脚本，再设计场景

耳朵上的字。口语句子需要明确的主语、主动动词和一个想法。避免堆叠三个子句，因为观众无法向后移动眼睛来恢复第一个子句。大声朗读每一行，并标记你喘不过气来、对术语犹豫不决或需要解释名词的地方。这些标记显示了在页面上看起来无害的写作问题。

一个可靠的序列是钩子、问题、机制、证明和CTA。钩子应该确定情况，而不是宣布公司有答案。问题应该显示出后果，而不仅仅是重复钩子。该机制应说明工作流程中有哪些变化。证明应该能解决一开始介绍的确切问题。CTA应该说出观众可以可视化的一个动作。

• 钩子：说出熟悉的时刻，例如两个队友回复相同的支持请求。
• 问题：显示成本，例如相互矛盾的答案、重复的工作或无人处理的请求。
• 机制：显示路由规则，将每个请求分配给正确的渠道和所有者。
• 证明：显示新请求到达一次，分配一次，并收到一个协调响应。
• CTA：邀请观众创建第一个路由规则，而不是模糊地要求他们了解更多信息。

在每项索赔旁边保留单独的证据说明。如果脚本说规则会自动路由请求，请识别证明这一点的产品屏幕或文档。如果脚本使用测量结果，请保留源和捕获日期。这个双轨流程将说服性写作与索赔验证分开，并加快了以后的审查速度。此集群中的专用脚本指南提供了完整的模板和注释示例。

06

6. 选择与讲解任务匹配的视觉方案

风格应该能解决一个解释问题。动态图形可以使无形的流程可见。UI演示可以证明工作流程的存在，但当每个控件同时显示时，它可能会让首次观看者不知所措。角色动画可以使反复出现的人类问题令人难忘。实时行动可以建立信任或展示物理过程。混合格式可以将上下文与产品证明相结合，但它也会创造更多的连续性工作。

通过询问观众必须看到什么才能相信机制来选择。如果值取决于接口操作，请包括接口或其简化表示。如果产品坐标系，请使用显示运动和状态变化的图表。如果解释是情感或行为的，角色或真人可能比浮动的UI卡更好地承载故事。视觉新颖性仅次于可读性。

• 在制作需求中指定稳定的调色板、类型层次结构、图标系列、透视和运动速度。
• 使用对比度来表示状态变化，而不仅仅是使每个场景在视觉上有所不同。
• 在它证明机制的那一刻保留详细的用户界面；简化支持屏幕。
• 在批准视觉系统之前，请检查移动宽度的字幕和关键标签。

07

7. 把脚本转成可审核的分镜

故事板是一个决策记录，而不是一个漂亮的框架的集合。给每个场景一个口头的想法，一个画面任务，一个证据来源和一个过渡理由。画面任务可以建立上下文、演示机制、比较状态、揭示证据或持有CTA。如果一个场景没有工作，那就是装饰。如果它有三个工作，请将其划分或简化脚本。

在相邻的列中写下叙述和视觉计划。这显示了两个常见的问题。首先，视觉可能只是将叙述作为文本重复，留下一个交流渠道未使用。其次，视觉可能会引入一个叙述从未解释过的新概念。最好的配对划分了作品：叙述提供了意义，而视觉提供了空间、程序或比较证据。

• 场景目的：写下这个场景为观众回答的问题。
• 旁白：保持一个口头想法，并标记任何发音或强调要求。
• 画面任务：描述状态变化、比较、行动或证据，而不是审美情绪。
• 屏幕文本：仅包含查看者必须阅读、验证或记住的单词。
• 过渡：解释什么连接证明从这个场景移动到下一个场景是合理的。
• 批准说明：说出负责产品准确性、品牌和最终编辑判断的人的名字。

在没有动作的情况下查看故事板。审稿人应该能够从缩略图、叙述和标题中遵循论点。如果逻辑依赖于过渡效果才有意义，那么序列是脆弱的。修复缺失的上下文、无法解释的状态变化或生成前不支持的证明。故事板修改很便宜；在定时和声音被锁定后，替换相互关联的场景就不便宜了。

08

8. 在 TapVid 中执行获批工作流

8月6日的测试以共享收件箱提示开始，英语，Adam Deep，持续时间约为60秒，起始比例为9:16。在这次观察到的运行中，TapVid在大约40秒内制作了一个结构化的制作需求。制作需求建议16:9，因为故事依赖于接口状态和路由通道。在全面生产继续之前，这一变化得到了批准。

从批准的制作需求到可审查的项目，整个观察的工作流程大约需要八分钟。结果包含四章和11个场景。这些测量描述了此日期的一次测试。它们并不是承诺每个来源、脚本或帐户都会产生相同的时间、场景计数或积分使用。复杂性、修订、可用性和产品变更可能会改变结果。

• 确认建议的比率更改改进了解释，而不是自动接受它。
• 在审查打磨剂之前，将生成的大纲与批准的机制、证明和CTA进行比较。
• 检查视觉系统是否在各个章节中保持一致，并且没有故事原因的情况下不会重置。
• 记录在初始提示和生成之间更改的任何设置、建议和批准。
• 在项目开放时收集证据，以便以后的索赔可以与特定的屏幕和日期挂钩。

生成的项目是第一次剪辑，而不是发布决定。自动化可以组织故事并快速构建连接的场景，但评论员仍然拥有产品准确性、叙事强调、标题、品牌细节和最终索赔边界。将每个生成的场景视为必须回答之前建立的故事板问题的提案。

09

9. 分三轮审核初版

试图一次审查所有内容会产生模糊的反馈。使用三张通行证。故事忽略了打磨，并询问论点是否完整、准确、顺序正确。场景通道检查每个视觉是否执行其分配的工作并连接到相邻的场景。静音通行证关闭声音，并检查字幕、标签、视觉层次结构，以及是否仍然可以遵循主要流程。

在测试播放中，等距风格和调色板保持合理一致，字幕是可见的。这并不能使每个场景都自动修正。审查仍然将开启问题、路由顺序、已解决的请求和CTA与已批准的制作需求进行了比较。有用的问题不是一个场景在孤立的情况下是否看起来很专业。是场景是否推进了承诺的解释。

• 收集与风格偏好分开的事实更正，以便首先解决准确性。
• 要求评论者说出场景、问题和建议的结果，而不是说感觉不对。
• 在任何旁白更改后重新检查持续时间，因为一次编辑可以移动几个下游场景。
• 在批准文本繁重或界面主导的序列之前，在手机上以正常大小观看一次。

10

10. 诊断讲解视频的常见问题

当真正的失败是编辑时，一个薄弱的讲解视频往往看起来像一个生产问题。模糊的开头使视频的其余部分更加努力，因为观众不知道要跟踪哪个问题。功能转储消除了问题和结果之间的因果链。一个美丽的隐喻可以隐藏机制。多个CTA使结局感觉像是导航，而不是结论。

通过从原始范围中追踪五个字段来进行诊断。如果观众不清楚，请重写开场情况。如果问题没有后果，请显示具体的失败状态。如果缺少机制，请用可观察的过程替换收益语言。如果校样很弱，请显示开头的已解析版本。如果CTA模糊不清，请将其变成可以在最后一帧中出现的动作。

• 在花时间改进动画之前，删除不受支持的最高级。
• 当脚本依赖于特定的产品或流程状态时，替换通用的库存场景。
• 在缩小类型之前缩短字幕；小文本解决了编辑器布局，而不是查看器的问题。
• 除非关系是机制，否则不要在短视频的中途添加第二个角色。

11

11. 检查导出文件，不要只看编辑器预览

导出是可交付的。在发布前，在编辑器外播放并记录目标属性。这次实践运行的文件测量为66.837秒，1280 x 720像素，每秒30帧，H.264视频，AAC音频和9,251,501字节。最后一帧包括了预期的下一步行动。由于运行使用了免费计划，导出的视频还显示了观察到的TapVid水印。

输入屏幕估计有180个学分。在观察到的工作流程中，账户余额从500变为302，相差198个积分点。将这些数字分开。估价不是发票，观察到的余额变化不应被推广为固定价格。审核文章时，必须在官方定价或产品界面上查看当前计划详细信息和积分规则。

• 使用耳机和扬声器播放完整的导出文件，以捕捉剪辑、静音或突然的音乐变化。
• 确认持续时间、分辨率、帧率、编解码器、音轨、文件大小、水印和字幕行为。
• 检查第一个和最后一个帧，因为平台缩略图和自动播放可能会显示意外状态。
• 将每个数字、产品标签和CTA与已批准的脚本和当前产品界面进行比较。
• 在移动宽度和目标页面上测试最终文件，而不是孤立地批准它。

将已批准的脚本、简介、源链接、导出属性和最终文件一起保存。该软件包让另一个团队成员了解为什么视频说了它所说的，并在产品发生变化时进行更新。干净的交接还将编辑批准与技术导出批准区分开来，这可以防止正确编码的文件被误认为是事实批准的视频。

12

12. 带着背景发布，并衡量一个结果

视频需要配套上下文。添加描述性标题、缩略图、简短文字摘要、逐字稿或有用的配套文章、字幕，以及一个就近行动入口。页面应说明视频适合谁，以及能帮助他们理解什么。搜索引擎和无法播放声音的观众都能从文字中受益。字幕也必须人工检查姓名、产品标签和换行，不能直接接受原始输出。

选取一个与位置匹配的测量值。登陆页面视频可能会通过播放率、场景完成、CTA点击和下游转换进行评估。入职培训视频可能会使用任务完成和支持请求。销售跟进可能会使用回复或进行下一步。如果预期行动没有改变，不要将高完成率解释为业务影响的证明。

• 记录出版日期、位置、版本、受众和CTA，以便以后的比较使用相同的上下文。
• 在可用时检查场景级别的下降；一个薄弱的场景比单个完成平均值更可操作。
• 一次更改一个主要变量，如开头、证明序列、运行时或CTA。
• 当界面更改导致机制不准确时，请更新或替换产品素材。

第一次迭代应该产生一个学习决策，而不是一个仪表板。如果观众在机制之前离开，测试一个更紧密的问题并提前揭示。如果他们观看但不采取行动，请查看证据、目的地和CTA连续性。如果他们完成了任务，但重播了一部分，则使该步骤更加清晰。每次修订都应指向特定的观看行为和特定场景。

13

13. 讲解视频制作常见问题

以下回答用于规划参考，不代表普遍承诺。可继续查看脚本模板和15个案例分析。发布元数据时，请参考Google 视频结构化数据文档。