产品经理的图文基本功

产品经理的图文基本功之PRD（Product Requirement Document），即产品需求文档。

我所在的公司偏重于项目管理，很多产品经理相关的工作，都是跟着极客时间产品经理邱岳（二爷）的产品手记与产品实战课程了解学习的。

二爷的观点是，产品经理的工作，诸如协调、思考、分析，是无形的；各式各样的文档成了最能证明产品经理实力的有形产物。因此写文档、写好文档，是产品经理的基本功。

在工作中最能流转起来的文档就是是Xmind/原型图/设计图了，单凭这些，没发把业务与数据逻辑记录清楚。我在探索适用于自己的需求文档PRD样式，将一些思考记录下来。

写文档的主要目的是清晰且准确的图文描述，而不是对着文档模版填空。没有意义的模块，不用硬填。

To C产品，可能更注重交互流程描述和线框图；To B产品，可能更注重概念模型和业务流程。

对于需要进行 UI设计的新需求/变更，突出交互流程；对于不需要UI设计的变更/问题，突出描述具体的功能逻辑与细节，直接供开发人员阅读。

线框草图

贴一张二爷画的 Readhub早期的线框草图。

图片中展示了

1. 信息项展开/收起的交互

2. 单条信息项默认状态的字段元素

3. 单条信息项展示状态的字段元素

4. 信息的加载方式

5. 信息加载后的提示信息

由此得到的启示

1. 设计初期，产品经理不需要直接定死 标题与内容的长度，给 UI留出更大的发挥空间。

2. 线框操作，同样需要标注信息

3. 可以使用 XX  //  ... 等形式绘制操作

Readhub早期线框草图

以下是Readhub当前页面的截图，对比查看，页面基本元素与线框操作基本一致。虽进行过几次改版，却一直在早期草图的规划范围内。

Readhub页面截图

用例图

从用户角度出发，以功能点的形式，描述用户与系统的交互过程和系统的输出逻辑。

（我只画过简单的用例图，具体标准/画法还得继续学习）

用例图

产品原型

产品原型的目的是通过界面化的形式，把系统逻辑表述清楚。可以通过添加线框标注的方式，给读者一个线索，清晰的看到页面之间组件的联系与数据状态变化规则。

原型标注（二爷）

基本流程图

圆角矩形表示“开始”与“结束”状态；

矩形表示基本操作；

菱形表示判断环节；

平行四边形表示输入输出；

箭头代表工作流方向。

电灯流程图

泳道图

如果业务流程变的复杂，就可以在基本流程图中加入角色/系统/模块的概念，变成泳道图。通过这些泳道，标识某一角色/系统/模块的功能操作。

时序图

查看了一些参考资料，现在找不到合适的示例图片了。

邱岳老师说，他曾经非常痴迷于画时序图，燃起了我对这个图的兴趣，代我深入学习归来，记录一波。

状态图

对于核心的业务实体，可以通过状态图展示实体状态变化的生命周期。从初始状态开始，每个节点（矩形框）即代表一种状态，节点与节点连线的文字即代表一种操作。

优点：从状态的角度出发，穷尽所有可能的状态变化，避免遗漏。

注意：业务实体，有起始状态，也应该有终止状态。

状态图

产品经理可以使用的图文类型有很多，但并不代表在每个功能需求里都要用全了。我最近一次写需求的时候，同时使用了泳道图和状态图，里面内容重复率高，没有达到应用的效果。

你对画图/写需求有什么好的方法吗？咱们交流交流吧。