【转】产品设计文档之Story Design

https://www.bilibili.com/video/BV1kv4y1A7rH

1. 版本说明

一个PRD会经过1~3次审查，每次Re会产生一些内容调整。因此对PRD的变动做好记录，对未来的阅读者会更加友好，避免信息缺失。一般来说只需要概述下变动即可，因为具体的变动读者可以通过版本记录追溯，且往往最新版已经足够于开展工作。

2. 背景与目标

背景一般会分为两个层次，第一层次是对当前产品大的背景介绍，往往可以链接到产品的宏观设计文档，第二层次是对当前整个故事所处的背景进行更加微观的介绍。例如：

脚踏板社区App已经上线3个月，DAU稳定到10000，每日有200多原创内容发布。累积了一定的种子用户，也保持了一定的图文内容发布的活跃度，为了进一步扩展内容的种类，提升用户的访问时长，希望尽快支持用户能够发布短视频内容。
同时，目前许多主流用户本身就是其他平台的短视频博主，内容生产均是基于视频的形式，只有图文发布功能会加大运营难度，损失头部KOL。

目标则是指大概要上线什么功能，以什么指标衡量：

通过上线短视频发布、浏览、分发功能，扩充内容丰富度、数量与用户的浏览时长等，希望本次迭代功能上线1个月后能够实现:
1.每日有至少100位用户发布短视频内容;
2.短视频内容浏览量占比大盘帖子浏览量的25%+;
3.短视频3日平均每条访问量不低于300次，互动率不低于10%(评论+点赞);
4.App人均日访问时长从3分钟提升至10分钟。

3. 故事介绍

3.1 用户场景

如果在背景与目标里还未能将用户的使用场景描述透彻，则可以继续深入向读者介绍一下未来用户的使用场景，加深画面感，例如：

用户可以发布15分钟内的视频，暂不支持App内拍摄视频;
视频发布流程支持断点续传;
用户可以在信息流中显著的区别出视频内容，也可以只浏览视频内容;
用户可以将视频转发到社交网络，如微信、QQ、微博、即刻;
用户可以对视频进行像图文帖子一样的点赞、评论操作;
用户发布的视频会经过严格的内容安全审核步骤。

注意，场景其实可以写得非常复杂、规范，甚至用表格详细介绍参数、制约条件等。但是我个人觉得没必要，好的设计文档是可以让读者循序渐进、引人入胜的。可以把设计文档也当做是一个产品来撰写，要注意读者的关注度、接受度和情绪。这才刚开始，不建议让读者脑子里塞太庞杂的资讯，毕竟可能PRD还有上万字等着他读，能有简单的画面感即可。甚至你可以截图一些竞品的界面加深这个画面感。

3.2 价值分析

当介绍完画面感后，辅以一些数据推演增加对目标的可及性介绍，增强团队信心。千万不要小看“信心”哦，研发团队每天的工作会比较单一、甚至枯燥，不断告诉大家自己的代码能带来多少新的价值，是产品经理应尽的义务)

视频内容丰富后，理论上可以增加用户的访问时长，以及入驻更多的KOL。以目前的数据进行预估对比如下表:
……

3.3 核心体验路径

按国产品设计的五张图 的设计思路，我们首先要明确视频功能的核心用户体验路径，这里以发布者为例

发布者核心体验路径:
选择内容类型(图文/视频)->选择视频 ->描述视频 ->提交并等待审核 ->过审发布成功

3.4 产品指标预测

当体验路径明确后，核心的过程指标便可以继续完善。除了在目标环节明确的业务指标外，产品经理还应该关注产品体验本身的漏斗指标。例如:

• 表明发布意向 ->提交并等待审核 的 比例%，首月预测为 80%±。
  预计会有一部分用户抱着试一试的态度选择发布视频，但发现我们目标没有美化、剪辑视频的功能，因此会放弃当次发布。在其他App中处理后再发起发布流程

• 提交成功 ->过审发布成功 的 比例%，首月预测为70%±。
  预计会有一部分用户发布带有水印、违反社区规则的内容，也有可能会有一些用户恶意刷屏，需要一段时间的引导。随着用户逐渐熟采新功能应该会逐步提升

团队对产品经理的信任度随着预测的完整度、达成度而建立。写PRD和周报一样，能够建立信任循环。

扩展阅读: 为什么周报如此重要

3.5 路径规划

还记得Backlog和Sprint吗?每一个Sprint往往只能完成一部分功能，为了能够让研发团队更好的架构技术框架，建议对未来可能发生的产品变动做出预告。

• 当前版本:实现视频的上传和浏览互动;
• 未来可能的功能升级:
  • 实现更长时间视频的承载，例如1小时;
  • 实现用户可以自定义封面;
  • 实现更聪明的视频审核机制，以节省审核成本;
  • 可能会考虑支持简单的视频裁切、贴纸、滤镜、文字等编辑功能，提升视频的可观赏性;可能会考虑支持视频直接拍摄、配乐功能。

如果有更加明确的产品路线图，更佳。

4. 概要设计

通过背景、目标和故事介绍，读者对新产品功能的价值和画面感基本已经具备，接下去要将画面转化为研发团队能够拆解、开始研发的产品设计语言。

模块、功能清单、页面结构三者描述的内容是互相有所重叠的，因此，他们既可以从不同维度表述设计细节，又可以互相验证设计的健壮度，避免遗漏。

4.1 模块设计

模块设计一般来说相对抽象一些，主要是起到归纳理解的作用，避免在设计大方向上有所遗漏。比如设计了C端体验却忘了设计后端对应的配置等。继续设计我们的脚踏板社区案例：

本次新增视频功能，涉及到的模块:
内容消费：信息分发模块+信息浏览模块
内容生产：视频发布模块+视频审核模块
内容存储：视频存储模块

是不是很简单? 简单就好，能够将复杂的功能抽象、归纳出来是产品经理的基本功。好的模块设计可以帮助产品未来的升级更加高效。由于本次只是新增视频的功能，因此涉及的模块本身也不会很多。这种情况下，甚至可以忽略掉模块的设计，直接设计功能清单。

4.2 功能清单

功能清单是基于模块的进一步细化

4.3 页面结构

人是视觉动物，看到页面是日常用户使用最直接的接口，通过页面结构的简单表述可以继续加强团队对产品的全貌理解。在一些涉及页面比较多(比如5个以上)的PRD中，是必备的。

墨刀、蓝湖

5. 详细设计

详细设计章节是我认为最简单的部分，只需要顺着功能清单有逻辑的将每个功能、页面的设计内容阐述清楚即可。通过不断的写、读、改，最终输出逻辑严谨的内容。不同的公司有不同的格式要求，很难在这步做出很细致的规范，只需要将事情讲清楚即可。常常以表格组织，并与功能清单、页面结构呼应。

6. 交付设计

6.1 数据分析设计

指明确当前版本需要新增、更新的数据埋点内容，以及未来可能需要的分析报表。这一章节，主要面向工程师和数据分析师。工程师需要研发埋点，数据分析师需要根据埋点制作/更新报表。产品上线第一天就能开始分析数据是非常重要的竞争力。

埋点设计：

由于每家公司的埋点系统不同，这里就不展开了，重点举例分析报表的需求设计。

报表设计：

一般来说，只需要罗列好需要看的报表内容和目的即可，剩下的交给数据分析师吧。不过在规划报表时也需要有产品思维，抽象、归纳，判断分析需求是对现有报表的升级，还是需要新增报表。时候经常会遇到报表越来越多，使用率越来越低的情况?有兴趣可以读读: 目数据分析体系的两大价值与四个搭建原则

6.2 上线筹备

每次上线都要考虑新功能是否会影响其他团队or历史数据，需要明确指名会发生的冲突及解决方案。简单举例:

本次上线存在数据冲突，需要重新申请阿里云内容安全的秘钥与主题，避免视频内容的审核数据与图文冲突。负责人:小李。

本次上线前需要DevOps提前规划好CDN的部署，并对相关云账号进行预充值;负责人:小王