产品经理的图文基本功之PRD（Product Requirement Document），即产品需求文档。
我所在的公司偏重于项目管理，很多产品经理相关的工作，都是跟着极客时间产品经理邱岳（二爷）的产品手记与产品实战课程了解学习的。
二爷的观点是，产品经理的工作，诸如协调、思考、分析，是无形的；各式各样的文档成了最能证明产品经理实力的有形产物。因此写文档、写好文档，是产品经理的基本功。
在工作中最能流转起来的文档就是是Xmind/原型图/设计图了，单凭这些，没发把业务与数据逻辑记录清楚。我在探索适用于自己的需求文档PRD样式，将一些思考记录下来。
写文档的主要目的是清晰且准确的图文描述，而不是对着文档模版填空。没有意义的模块，不用硬填。
To C产品，可能更注重交互流程描述和线框图；To B产品，可能更注重概念模型和业务流程。
对于需要进行 UI设计的新需求/变更，突出交互流程；对于不需要UI设计的变更/问题，突出描述具体的功能逻辑与细节，直接供开发人员阅读。
线框草图
贴一张二爷画的 Readhub早期的线框草图。
图片中展示了
1. 信息项展开/收起的交互
2. 单条信息项默认状态的字段元素
3. 单条信息项展示状态的字段元素
4. 信息的加载方式
5. 信息加载后的提示信息
由此得到的启示
1. 设计初期，产品经理不需要直接定死 标题与内容的长度，给 UI留出更大的发挥空间。
2. 线框操作，同样需要标注信息
3. 可以使用 XX // ... 等形式绘制操作
以下是Readhub当前页面的截图，对比查看，页面基本元素与线框操作基本一致。虽进行过几次改版，却一直在早期草图的规划范围内。
用例图
从用户角度出发，以功能点的形式，描述用户与系统的交互过程和系统的输出逻辑。
（我只画过简单的用例图，具体标准/画法还得继续学习）
产品原型
产品原型的目的是通过界面化的形式，把系统逻辑表述清楚。可以通过添加线框标注的方式，给读者一个线索，清晰的看到页面之间组件的联系与数据状态变化规则。
基本流程图
圆角矩形表示“开始”与“结束”状态；
矩形表示基本操作；
菱形表示判断环节；
平行四边形表示输入输出；
箭头代表工作流方向。
泳道图
如果业务流程变的复杂，就可以在基本流程图中加入角色/系统/模块的概念，变成泳道图。通过这些泳道，标识某一角色/系统/模块的功能操作。
时序图
查看了一些参考资料，现在找不到合适的示例图片了。
邱岳老师说，他曾经非常痴迷于画时序图，燃起了我对这个图的兴趣，代我深入学习归来，记录一波。
状态图
对于核心的业务实体，可以通过状态图展示实体状态变化的生命周期。从初始状态开始，每个节点（矩形框）即代表一种状态，节点与节点连线的文字即代表一种操作。
优点：从状态的角度出发，穷尽所有可能的状态变化，避免遗漏。
注意：业务实体，有起始状态，也应该有终止状态。
产品经理可以使用的图文类型有很多，但并不代表在每个功能需求里都要用全了。我最近一次写需求的时候，同时使用了泳道图和状态图，里面内容重复率高，没有达到应用的效果。
你对画图/写需求有什么好的方法吗？咱们交流交流吧。
