PRD用什么来写，没有最好的，只有最合适的，每个人所在的公司背景都不一样，大公司要求文档规范细节到位，小公司可能只需要记录关键信息，剩余的靠口头沟通，甚至都不需要文档。

我要强调的是：PRD拿什么工具写无所谓，但一定具备良好的可读性。

我见过有产品经理用Axure写的，整个文件横向纵向各种拖动，看的人崩溃。我也见过订单结算页面使用平台红包、卖家红包、卖家优惠券的业务规则/逻辑说明用了整整3页纸将近2500余字的，这个开始写在了Axure里面，后来可读性太差，最后改成了Word文档的。

我看过很多教人写PRD文档的文章，这些文章很多都犯了同样的毛病，一上来就讲术的部分，鲜有人去讲道的部分，也就是具体的思路。

我的思路概括起来就6个字：框架、流程、细节。

框架：可以理解整个产品的业务蓝图，或者系统架构图及功能结构图。数字化建设不是一朝一夕之功，需要敏捷开发快速迭代，但在做之前需要有整个产品的业务规划蓝图，就跟建高楼盖房子之前要有设计图纸一样，不能边做边改。

流程：如上图所示，业务系统是由N多个业务模块或功能模块构成的，以我们熟悉的电商平台为例，就会涉及到支付，售后和物流多个功能模块，每个模块又会由前端的，后台的，正向的，逆向的流程构成。

所谓一图胜千言，这些流程如果用文字来描述，那么文档使用者就会特别特别的痛苦，这时如果有这么一张流程图，那整个文档的可读性就会好上一个数量级。

流程≠流程图，上述的核心业务流程也可以通过其它的视图方式来呈现，例如活动图，用例图，状态机图，时序图等等。而流程图只是最为常见的一种。

如下就是UML中比较常见的时序图，该图研发同学用的会多一些，这个图能清晰完整的反映出支付活动中的数据流向和流程顺序，能方便开发和测试同学更深刻全面的理解整个业务。产品经理用的比较多的则是上面的那种泳道流程图。

细节：上述框架和流程部分会占到整个PRD的20%左右，剩下80%则由大量的细节构成，细节则主要通过原型图来表达产品的界面和交互流程等。

比如用户在页面上点击了不同的区域后会分别跳转到哪些页面流程或节点，如下图所示。这里建议给页面表上序号且树状结构不超过3层，特别是需要多地远程沟通的项目。

比如开腾讯会议沟通需求的时候你告知对方打开订单列表页，别人可能需要在页面原型上找半天，如果你说打开3.1 订单列表页查看标记5的规则3，协作方就能快速定位到，这样也能提高多地协作的效率。