业务流程和产品文档

一.什么是产品文档

1.spec？XRD、原型？User Sstory? Use Case? 数十月页 word 文档？

2.产品文档也是我们的产品：用产品文档解决谁的问题？

3.文档与效率的关系：什么情况下需要文档？

4.文档光辉时刻：写时/聊天/查时

二.为什么我们需要产品文档

1.提前进行 *完整 *思考

思考：写作是思考的线性化表达，写作是思考本身，写文 档是为了让我们自己思考。产品落地之前想明白。

提前：最便宜也是最容易推动的调整时刻

完整：具体化、细节化、可落地

2.高效沟通

一次编写，到处沟通

一次编写，异步沟通

3.仪式感与责任感

stake Holder /工程师/合作方

三.产品文档应当包含什么？

1. 标题（给别人发的时候 一看就知道写的是关于什么，未来可以检索出来的意识）、标签

2.作者、修改历史

3.需求背景、上下文/问题、现状、目标（和非目标）

4.场景化描述

5.确定达成目标的具体标准

6.具体解决方案

7.成本和计划 产品要成本感的

8.决议前提/假设/风险

四.什么是好的产品文档

1.有效回答读者问题：这个跟我有什么关系 & 为什么 & 我要做什么

2.清晰、简洁（需要很大心力和时间才能写成简洁）、说人话、有故事性

3.结构清晰（目录）、能够快速索引定位

4.图文（看的人有个直观的认识）并茂，有数字

5.良好的组织结构

6.持续更新

7.读起来有意思

五.产品文档的成型过程

1.从一个松散的非结构化小备忘文档开始

2.基于这个备忘，开始进行零【售沟通】（意思：和相关人员一对一的私下沟通）

3.基于零售沟通的输入，形成完整的文档

4.文档发酵（不要写完就给别人看，放一段时间再看）和修改

5.对完整的文档进行【零售确认（相关关键人员私下确认）】

6.对完档进行批发讨论（分门别类的讨论）和确认

7.正式需求评审

8.形成最终版本，确定下来，分发存档

9 持续更新*

六.常见的文档类型及含义

BRD:商业，受众——公司老板 股东 ceo 等等，需要做什么需求方案，市场上需不需要，收益

MRD:市场分析

PRD：

DRD：设计图

FRD：功能需求文档

FSD：具体功能文档

User Story：

UC：用例

七.产品经理三大文档（？）

BRD MRD

用户价值与机会 用户、场景与时间

解决方案与产品策略 市场机会与竞争对手

市场分析 产品轮廓和主要功能

销售渠道和策略 价值描述、卖点、渠道

组织保障

路径规划

收益预估

时间/团队成本估算

风险

PRD

需求背景

目标、期望

利益相关方

场景描述

需求优先级

详细的产品功能性需求

非功能性需求

商业规则

八.从一个小小小小小尝试开始

某学习课程 app 的完课率下降，人走了就不来了，要把他们弄回来。

开始写备忘录

你知道什么，你假设什么，你想干什么，你想得到什么，你怕什么，你需要谁来帮忙，哪些问题你没想清楚

咱们开始吧 写备忘录是疯狂输出的过程

为某课程学习 APP 增加自动提醒功能督促流失用户回来上课

你知道什么，你假设什么，你想干什么，你想得到什么，你怕什么，你需要谁来帮忙，哪些问题你没想清楚

出现了什么问题

~我们观察到，整体完课率低，有 50%的购买了课程的用户没有完成课程学习（50%需要 BI 提一下确认）

备忘录

有一种叫法 bulleted brain storm ,把你知道的和想知道的，全部列出来

定义问题，把问题范围划清楚；比如完课率和 NPS 和复购，可能不是同一个问题

定义目标，量化目标

划定相关人员，以及要让他们干什么

列出可能的问题，并领起后续的沟通和格式文档写作

2——产品文档和原型咋弄

用例

一.什么是用例

参与者：

以某种方式与系统交互的人或时

用例：

系统为其参与者所执行的 有价值 的操作

用例图和用例文档以及把他们组织起来的方式描述系统是如何被使用，如何与参与者互动

用例不是功能或特性，用例包含一个对于参与者来说有完整意义的过程。

用例解释系统如何向利益相关者 参与者提供功能性价值

用例通过使用者视角描述系统与互动的方式，从而观测出系统实现。

特性：人们可以取钱 用例：取钱

特性：系统可以自动选择吐钞面值组合 用例：取钱

推荐一本书——《用例建模》

二.用例的参与者

参与者不会是 人，而是角色，一个人可以有多个身份。

参与者不一定是人，也可能是系统。

先写多，在合并和抽象。

要抽象，但不要过度泛华。

特殊参与者：系统/时间

三.用例的粒度

系统为参与者提供的具备 完整价值 的服务。（关注价值而非功能）

查看商品详情 是不是一个用例？教科书中 其实不是用例

两点时候当做用例：

1.当他有很多交互的时候，对用户的影响的时候 我们会认为作为用例

2.还有一个可能，当跟开发更明确沟通时，让开发更明确意识到他的流程的时候，是一个步骤，不具备完整价值服务，单独拿出来做一个用例。

这个用例是一个完整的具有可销售价值的服务吗？老板测试？

用例：用户管理 vs.修改用户密码

以主动的逻辑命名：

风险评估 vs 评估风险

划定系统边界，什么是边界内的？外的？

四.用例文档

画好用例图以后，下边 UC1 uc2 UC3

五.用例文档包含的内容

标题坐着修改历史

简要描述

利益相关者/涉众/参与人及其相关利益

事件流：基本流程/扩展流程/异常流程

辅助图例

前置条件/后置条件

*术语表

*界面图例

*限制条件/特殊需求/策略

六.用例文档的核心——事件流

用例文档中最重要的部分（事件流），描述如何通过交互传递由用例所承诺的价值。

用例文档是一个被严格流程化规范的故事，它像一个词牌名。

用例开始（入口）——用户发起请求-系统校验请求-系统处理-系统反馈——结束

基本流/扩展流/异常流：

基本流中没有任何分支，没有如果，只有顺序描述，预期会成功的路线。

即便啰嗦，也要严格按照 1234 步骤编写，可以帮助自己快速切换视图，注意主语。

基本流必须完整，不用引用其他扩展流。

一起写一个：ATM 机取钱的事件流

基础流程

1.用例开始

2.系统展示插卡教程

3.用户插入银行卡

4.系统校验银行卡合法

5.系统展示输入密码组合

6.用户输入密码

7.系统校验密码正确

8.系统展示服务项

9.用户选择取款界面

10.系统展示取款界面

11.用户直接选择预定的取款金额

12.用户提交取款申请

13.系统校验金额合法

14.系统登记取款记录

15.系统支付现金

16.用户取走现金

17.系统确认用户没有其他业务

18.系统退还卡片

19.用例结束

子流程

登录流程

扩展流程

4a.系统无法识别银行卡

4a1.系统提示用户，银行卡错误

4a2.系统推出卡片

4a3.用例结束

4b.系统识别到银行卡挂失

4b1.系统提示用户，银行卡有误

4b2.系统发出警报，并录下用户脸庞

4b3.系统锁住 ATM 小房间

4b4.用例结束

4c.系统识别卡片插反

4c1.系统提示用户，卡片插反

4c2.系统退出卡片

4c3.系统播放正确的卡片插入样式

4c4.用户重新插入卡片 若未插入卡片 用例结束

4c5.执行用例 4

7a.系统校验密码不正确

7a1.系统提示用户密码错误，提示用户剩余密码尝试次数

7a2.系统展示密码输入界面

7a3.用户输入密码

7a4.系统扣除密码尝试次数

7a5.系统校验密码正确

7a5a.系统校验密码错误

7a5a1.判断尝试次数用尽

7a5a2.锁卡

否则执行 7a1

7a6.继续执行步骤 8

七.前后置流程

系统能够感知和校验的状态描述

前置：确保系统在正确起点（且）

比如：与银行链接的网络是可用的；用户被授权进行此次操作。

后置：确保系统正确的结束（或）

比如：ATM 向用户返回卡及现金，并记录本次提款事务与用户账本上；ATM 未向用户返回现金，本次支付失败事件记在账本上。

八.辅助图例 &界面图例

原型的时候还会有的

九.限制条件/特殊需求/策略

策略：向不活跃用户发送提醒，时机和用户群就是策略。

限制：如拍卖，单日提现不得超过 5000

特殊：如敏感词审核

九.术语表

十.用例文档包含的内容

标题作者修改历史

简要描述

利益相关者/涉众/参与人及其相关利益

事件流：基本流程/扩展流程/异常流程

辅助用例图

前置条件/后置条件

*术语表

*界面图例

*限制条件/特殊需求/策略

进阶

用例之前的关系

参与者之间的关系

用例与

去看《用例建模》和《UML 和模式应用》——书

作业：写一个用例 自己的产品 或者喜欢的产品

2.挑一个产品，想一个你想做的新功能，然后写一个完整的文档

第三——流程图

第四——业务架构与概念模型

1.什么是状态图

画一个员工的职业生涯状态图：

状态图的价值

2. 什么是概念模型

概念模型设计过程：

画一个视频号和微信号的关系：

概念模型的价值：

有个完整的系统视角，看到系统内的概念以关系。

帮助思考和澄清一些边界性的问题。

有个明确的概念关系统一沟通，统一开发、业务和用户视角。

概念模型的风险和问题

画图一时爽，读图火葬场。

要考大量沟通，很难独立读懂。

模型和当前用例/业务规则之间，可能存在差异（比如一个微信号关联几个视 频号？）

小小经验：

概念模型图，很多时候，对自己的意义大于对外沟通，是一个结构化提问的构成。

可能是需要迭代最多的一种图。

To B 业务中通常更加需要。

规模到一定程度，可能就很难读懂了，建议有机拆解。

第五——产品原型图

提纲：

做原型图的目的

绘制原型图的步骤

绘制原型图的实践

绘制原型图的一些技巧和经验

不同级别的原型图

1.纸盒笔的 原始的图 自然的东西的

2.线框图

3.高保真的图 真实图

一.做原型图的目的

塌缩：规划时梦到自己成了乔布斯，赶紧画个图让自己冷静冷静

具体：具体就是故事，讲故事的能力就是营造画面感的能力

沟通：多方都看得懂的抓手，文档描述的 索引

思考：在原型中会发现很多在文档和规划是想不到的问题

二.做原型图的步骤

列出用例（有哪些功能？）

基于用例规划界面（有哪些界面？）

列出界面结构（界面路径？信息架构？）

每个界面的元素和行为以及优先级

草稿——线框——严肃——高保真——动效

步骤：

1.列出用例（1/5）

知道用户完成的用例

知道完成这个用例的步骤

2.规划界面（2/5）

不同用例的步骤，打散，重聚

列出相关界面

3.界面架构（3/5）

4.界面内元素优先级（4/5）

元素结构和优先级：要传递给设计师的重要信息

动作：越少越好，越集中越好，也要列出优先级

状态：当前页面可能的不同状态（时间/角色）

5.做原型图的步骤——画（5/5）

草稿——线框——严肃——高保真——动效

思考——表达——沟通————展示

画一个从课程进直播间

6.工具：做原型图的经验

（2）.做原型经验

最好的学习路径：重视别人的产品（Remix）——重做别人的产品 看看他怎么做的，然后不看产品，重新画一下页面结构

手机端一定要到手机上摸一摸，不是在电脑上看截屏

知识的诅咒，给人先看看，听听怎么说

别忘记文案 也是 UX 得一部分 文案是产品价值的体现

花在让原型图更加逼真精美的每一份钟 都（可能）是射向设计师的子弹

第六——PRD 与整体文档

一.已经学到的各种元素

1.基本元素（目录标题作者版本历史等）

2.场景描述 我们要同仇敌忾面对一个问题

3.需求背景， 现状，问题，目标（一定要被指标化 名词化 比如：提升用户周留存） 目标—现状=问题（需要解决的问题）

4.计划时间表 &可行性评估 &规模评估

5.用例图（用户视角的描述）0&用例文档

6.概念模型图 &状态图

7.流程图（活动图）&时序图（交互）

8.产品原型 &线框图 &页面结构、信息架构与路径

抓手是什么意思：有个落脚点

二.还有些其他元素需要知晓

1.特性描述

2.非功能性需求

3.需求的优先级

4.数据字典/商业规则

5.策略/规则/接口文档（业务之间的接口）

三.组装 PRD ——PRD 是干什么的

1.积极去找工作 3 4 月最好

PRD 存在的意义：讲清楚我们要做什么 what

PRD 的讲述方式：通过介绍产品如何工作，从而说明要做什么 how

PRD 的前提：交代清楚我们的目标 why

2.组装 PRD——PRD 需要如何推进

交代清楚我们的目标，用户场景和价值，产品定位 why

描述用户使用产品的过程和互动方式、业务 guize how

产品的架构、页面、特性、资源计划等等 what

3.组装 PRD——PRD 组织方式

以用例为纲

以特性为纲

以页面（模块）为纲

***以场景/故事为纲

读过剧本的 比如雷雨 就是一幕一幕场景描述

1.文档的基本要素

2.交代清楚背景和目的（starts from why）

3.描述用户场景和角色，以及用户问题（用什么方法解决谁的什么问题）

4.提纲挚领地粗略给出系统的大图

用例图

页面架构图

概念模型图

主要页面/模块

核心流程/状态

5.以用例为（目录）逐步发展

6.每个用例中包含流程，涉及到相关界面、流程图、状态图、商业规则时，包含进来

7.可以将（界面）（流程图）

8.列出非功能性需求

9.可行性评估、资源评估、计划评估、第三方支持、风险评估等

10.竞品分析 市场分析

四.PRD 几个建议

1.让整份文档有 发酵时间 过个一晚上，肯定会有提升

2.先零售沟通，在批发沟通

3.定期复盘，改进结构和面熟方法

4.回到文档的目的：解决谁的什么问题？问一问 用户反馈

法无定法，非法法也

如何总结/复盘

1.重复别人的笔记，最好要有自己的观点

2.最好一篇总结一个观点，用金字塔原理

3.写时王道，若是不好意思给别人看不发就可以了

4.通过写东西来了解自己（喜恶偏好），提醒和改进自己

5.只有输入是不够的，输出是最好的充足和消化过程