7个产品讲解视频脚本示例
探索7个产品讲解视频脚本示例，了解示范旁白、视觉规划以及实用的改编技巧。
当你明确了视频需要回答的问题时，撰写产品视频脚本就会变得更加容易。“这个功能有什么作用？”和“我该如何开始使用？”需要采用不同的讲解方式。
以下7个产品讲解视频示例均为虚构产品的原创脚本构思。每个示例都包含旁白、视觉规划，以及对该结构适用场景的说明。这些内容仅供写作参考，并非客户案例研究，也不代表任何经过测量的转化率数据。
你可以借鉴这些示例，为真实产品选择合适的脚本结构。然后，用可以实际演示和验证的产品功能替换其中的虚构内容。
先确定问题，再选择视频形式
你可能需要制作首页视频、产品发布视频或销售视频。这些名称描述的是视频的展示位置，却不能完全说明观众需要了解什么。
向提出视频制作需求的人确认：这段视频应该消除观众的哪种困惑。访问者可能不了解产品所属的类别；客户可能知道产品类别，但需要看到某项具体操作；现有用户则可能只想了解产品发生了哪些变化。
| 观众的问题 | 适用的脚本结构 |
|---|---|
| 这个功能有什么作用？ | 单一功能讲解 |
| 我该如何开始？ | 首次使用操作指南 |
| 这个产品如何解决我的问题？ | 问题与解决方案 |
| 整个流程是如何进行的？ | 工作流程讲解 |
| 这个产品适合我的情况吗？ | 使用场景示例 |
| 它如何与其他系统协同工作？ | 集成讲解 |
| 遇到这种特殊情况会怎样？ | 常见问题讲解 |
每个视频只聚焦一个核心问题。如果一份脚本试图回答全部七个问题，那么它很可能需要采用另一种结构，并且需要比短篇讲解视频更长的时长。
7个产品讲解视频脚本示例
1. 通过直观操作讲解单一功能
虚构产品： Pinboard，一个共享项目工作空间，提供动态置顶功能。
旁白：
重要的项目更新可能会淹没在日常评论中。Pinboard 允许你将团队需要随时查阅的更新置顶。打开项目，选择已确认的更新，然后点击“置顶”。该更新就会保留在项目的置顶区域，团队成员可以随时打开并查看完整内容。当信息发生变化时，请检查已置顶的内容，并用当前版本替换过时的信息。对于需要反复查阅的决策，例如交付日期或已商定的项目范围，可以使用置顶功能。
视觉规划： 展示一份内容繁杂的评论列表、明确的置顶操作，以及置顶内容区域。最后，展示一位用户打开并查看完整更新内容。
这种结构为何有效： 该功能只有一个明确的用途。视频直接演示这一用途，无须逐一介绍整个工作空间的所有功能。
真实产品需要核实的内容： 哪些用户有权限置顶内容、置顶操作是否会改变通知设置，以及如何替换过时的置顶内容。如果该功能不会向任何人发送通知，就不要在视频中展示通知弹出的场景。
2. 帮助用户完成第一次有价值的操作
虚构产品： PackList，一款支持重复使用打包清单的应用。
旁白：
下一次旅行，从一份可以重复使用的清单开始。在 PackList 中，创建一份清单，并根据旅行类型为其命名，例如“两天商务出差”。添加实际需要的物品，然后将它们分类为衣物、工作用品和必需品。将这份清单保存为基础清单。下次出行时，复制这份清单，并修改副本。保留原始基础清单不变，避免某次旅行的特殊物品被加入以后每次出行的清单中。你的第一个实用成果，就是一份符合个人出行习惯、可以重复使用的打包清单。
视觉规划： 展示一份空白清单如何逐渐变成内容简洁、分类清晰的示例。然后，将基础清单与复制后的旅行清单并排展示。
这种结构为何有效： 它为用户设定了一个明确的完成目标。视频最终呈现的是一份可以直接使用的成果，而不是对所有菜单选项的逐一介绍。
需要核实的内容： 实际的创建和复制步骤。如果产品只支持手动复制，就不要展示保存模板的功能。
3. 将具体问题与具体改变联系起来
虚构产品： ReviewLane，一款设计评审工具，支持将评论关联到指定版本。
旁白：
上周设计稿上的评论，可能会被误认为是针对今天这个版本的反馈。ReviewLane 会将每条评论关联到正在评审的版本。打开当前设计稿，检查版本标签，然后在该版本下发表评论。当新版本上传后，之前的讨论仍会作为历史记录保留。在修改设计之前，先确认反馈针对的是哪个版本。这样，团队成员就能围绕同一份设计展开讨论，而不必猜测某条评论是否仍然适用。
视觉规划： 首先展示两个不同版本的设计稿，以及一条归属不明确的评论。随后，清晰地将评论关联到其中一个版本，再展示对当前版本的评审过程。
这种结构为何有效： 开场提出的问题足够具体，可以通过画面直观呈现。产品操作也能直接解决这一特定问题。
需要核实的内容： 添加新版本后，评论的处理方式。除非已经确认评论会自动迁移，否则不要暗示系统具有这种功能。
4. 讲解涉及多个人员的工作流程
虚构产品： RequestDesk，一款支持手动分配任务和完成确认的请求跟踪工具。
旁白：
一个请求始于需要帮助的人。在这个示例工作流程中，用户首先在 RequestDesk 中提交问题描述。协调人员随后指定负责人，负责人则在工作完成后记录处理结果。接下来，请求者确认该结果是否满足请求要求。整个过程中，要清楚展示各个角色：请求者、协调人员和负责人。如果处理结果不完整，请求就会保持未关闭状态，等待进一步处理。整个流程以确认环节结束，因此可以轻松区分任务已完成和结果已获认可这两种情况。
视觉规划： 使用一张请求卡片，展示它如何在不同角色之间流转，并为每个角色添加明确标签。展示处理结果不完整时，请求返回负责人处继续处理的分支。
这种结构为何有效： 它解释了不同人员之间的任务交接和完成条件，而这些内容通常无法通过简单罗列功能来充分说明。
需要核实的内容： 实际的任务状态、权限设置和异常处理方式。清晰简洁的流程图不能虚构出比产品实际支持的流程更简单的操作方式。
5. 展示符合观众实际情况的使用场景
虚构产品： BriefBox，一个用于准备客户会议记录的工作空间。
旁白：
明天的客户会议涉及三个尚待解决的问题和两项近期决策。在 BriefBox 中创建一份会议简报，并将这些内容分别放入不同的栏目。在每项决策下方添加对应的原始记录链接，方便任何人核实具体信息。准备会议时，标记出哪些问题需要客户回答，哪些问题可以由团队提前解决。然后，将会议简报分享给所有参会人员。最终，你将获得一份围绕本次会议重点整理的材料，并且在有人需要进一步了解时，可以随时查阅相关依据。
视觉规划： 展示零散的示例笔记如何整理成一份包含待解决问题、决策事项和原始资料链接的会议简报。
这种结构为何有效： 具体场景能够帮助观众联想到自己日常从事的工作。它展示了明确的实际成果，同时不会夸大或承诺普遍适用的时间节省效果。
需要核实的内容： 产品支持的资料来源类型以及分享方式。如果实际工作流程需要手动整理，就不要展示自动检索或自动总结的功能。
6. 通过展示数据流转来讲解集成
虚构产品： TaskBridge，提供一种假设性的日历连接功能，可以将选定的任务截止日期复制为日历事件。
旁白：
项目截止日期应该记录在任务信息中，但你可能也希望它显示在日历上。在这个虚构的 TaskBridge 集成方案中，连接日历账户，并选择需要复制到日历中的任务截止日期。每个选定的日期都会生成一个与对应任务关联的日历事件。在实际使用之前，请先确认当前配置如何处理信息修改和删除操作。始终将任务记录作为管理工作的主要位置。日历事件则可以帮助你将截止日期与其他日程安排放在一起查看。
视觉规划： 展示账户连接过程、明确选择某项任务的操作，以及最终生成的日历事件和返回任务的链接。整个演示都应标注为虚构的集成方案。
这种结构为何有效： 它明确指出了数据来源、目标位置以及实际传输的数据内容。相比两个品牌标志通过动画连接在一起的画面，这些细节更有助于观众判断集成功能是否实用。
需要核实的内容： 同步方向、支持的字段、同步延迟、权限设置，以及删除数据后的处理方式。集成功能的视频尤其容易出现夸大描述的问题。
7. 回答阻碍用户做出决定的特殊情况
虚构产品： GuestRoom，一款提供候补名单申请功能的预订工具。
旁白：
你需要的房间已经被预订了。在 GuestRoom 中，你可以针对该时间段提交候补申请。填写日期、时间和联系方式，然后查看申请状态。加入候补名单并不代表预订已经确认。如果之后有空房，请按照你收到的通知中列出的确认步骤进行操作。在正式收到确认之前，请保留其他备选方案。候补名单可以记录你的预订意向，同时清楚区分申请和正式预订这两种状态。
视觉规划： 展示无法预订的时间段、候补申请表单，以及标注为“已申请”的状态。最后，明确展示“已申请”和“已确认”之间的区别。
这种结构为何有效： 它解决了一个实际的不确定因素，而这个问题可能会阻止客户继续操作。
需要核实的内容： 是否提供通知、候补优先级如何确定，以及哪些操作代表预订已经确认。不要承诺一定有空位。
改编示例时，不要照搬其中的假设
如果你需要一个可以重复使用的分镜结构，可以从讲解视频脚本模板开始。首先准备一份经过确认的产品说明。记录功能的实际行为、用户角色、前置条件和例外情况。然后，根据这份说明，替换所选结构中的虚构细节。如果旁白已经获得批准，Script to Video 可以作为基于现有脚本开展制作的合适起点。
接下来，仔细检查脚本中的动词。“检测”“同步”“批准”和“发布”等词语都意味着特定的功能行为。如果产品只是帮助用户完成某项操作，就应该明确展示用户在其中扮演的角色。
在适当的情况下，使用真实素材来制定视觉规划。简化后的示意图可以帮助解释流程，但不能将其伪装成真实运行界面的截图。如果概念性场景可能被误认为实际功能，就应明确标注。
一个很好的审核问题是：客户是否有理由认为，产品能够完成视频中展示的所有操作？如果答案不确定，就应该在润色动画之前修改相关场景。
为 Felo 准备产品讲解视频说明
提供经过批准的产品描述、相关截图或原始资料，以及选定的脚本。明确说明目标受众，以及视频需要回答的问题。
例如：
为新用户讲解一项经过确认的产品工作流程。严格遵循所附脚本，只使用提供的功能信息。清楚展示前置条件和例外情况。如果截图内容过于复杂，可以使用示意图。不要添加未经确认的自动化操作、集成功能、客户引言或性能统计数据。最后，以说明文档中指定的唯一操作作为结尾。
Felo 的 Product Explainer Video 入口主要用于讲解产品信息和用途。应将其生成内容视为初稿，并根据产品说明进行审核，尤其要注意那些可能暗示产品具备未经明确说明的功能行为的场景。
关于产品讲解示例的常见问题
哪种脚本结构适合放在首页？
选择新访客最需要了解的问题。可以采用问题与解决方案的叙事方式，也可以展示具体的使用场景。当访客了解产品的作用后，再进一步介绍具体功能的操作流程。
每个示例都应该以注册引导作为结尾吗？
不应该。现有用户的下一步可能是完成某项任务，或者检查某项设置。应根据目标受众以及视频的展示页面，选择合适的引导操作。
脚本示例可以代替真实的产品演示吗？
脚本有助于规划讲解内容，而真实演示则能够证明产品的实际行为。如果购买决策或新用户引导取决于产品究竟能做什么，就应该同时使用这两种方式。
选择你需要回答的客户问题，核实相应的工作流程，然后探索 Felo Product Explainer Video。