彻底抛弃WORD！教你用Axure快速输出高质量的PRD

画原型图是产品经理的基本功，但很多PM画了几年的原型，仍然不能高效、准确的输出一份原型。很多人都在纠结PRD应该怎么写，写到什么程度，粗了怕遗漏需求，细了没时间不说，别人还不看。

作为产品经理，我们到底应该输出一份怎样的PRD，又如何做到最“低成本”的方式，输出最轻便、完整的PRD？

1、Axure版PRD 还是 Word 版PRD

到底能不能直接用auxre输出PRD这个问题，很容易引发争论。

在回到这个问题之前，我们再明确一下PRD的目的和作用：

为了向团队说明业务解决方案，并试图让相关方都能理解而且支持这一解决方案，以及在开发过程中有条不紊的推进方案的落地执行。

PRD的问题不在于如何写而在于让团队能够理解业务，以及开发过程中如何被传递与执行。真正困扰我们的是一个很尴尬的现象：

“写多了大家未必都会看；写少了又怕别人不懂”。

关于PRD，最开始几乎所有人都是用WORD，我们也能很容易搜索到各种模板。一般说来，PRD都是从目的、范围、背景、功能需求、非功能需求这样一种逻辑组织语言，如下图所示，最终会形成一份结构清晰的需求规格说明书。

PRD 结构图

在描述需求的时候，通常用“输入”---->"输出"的逻辑关系阐述用户需求，并且用“表格”来呈现完整的需求列表。

用户登陆

WORD输出的文档，最大的优势就是有一个清晰的目录大纲，一眼过去就能大致明白这一个“项目”的范围，要做那些事情。

之所以今天很多人在反对这种格式文档，原因在于这种“项目交付式”的需求规格说明书已经跟不上节奏，其撰写和阅读的效率太低，写和读都非常的痛苦。而且非常局限，很难真正理解一个产品的全貌，传统的软件工程面向的是项目交付，而不是我们今天大力倡导的以用户为中心的产品思维。

曾经负责过一个项目，应甲方要求，洋洋洒洒输出六万余字的PRD（一式三份打印出来，推在桌上蔚为壮观），依然感觉意犹未尽。这种巨幅的PRD文档，在传统软件领域，极为普遍，但尴尬的是，这种文档往往写完就束之高阁。

对一份PRD来说，没有什么比可读性还重要的事情了。

PRD的作用就是为了帮助能够阅读到它的每一个人，都真正理解并推动执行。

是时候抛弃线性描述的WORD了，互联网下的产品经理需要更高效的专业工具和工作方式。

从现在出发，我们的目的是让你的PRD相对轻便，别人愿意看，自己也不太“痛苦纠结”。

我们要让团队的每个人很清晰的知道当下处于什么境况，我们要在什么时候做到什么样子。

x 产品 PRD v1.0

可以参考以下的方式来设计一个清晰的文档结构：

版本摘要：为什么要做这个版本，要做什么，什么时候做好；

变更日志：让你的团队成员知道你“又做了什么手脚”；

产品原则：通用性的规范，需要遵从什么标准，什么要求，做成什么样；

功能结构：“用图来描述”你现在想要改动“个人资料”模块还是订单页面；

关键流程：涉及到的关键业务流程；

故事板与原型：用场景化的语言描述某个功能是什么，配合适当的例子，让团队成员真正理解这个场景下的用户行为。

注：这是一个真实项目改编的模板，源文件可点击文末的下载连接下载。

2、设计一个清晰的摘要追踪版本

PRD的目的就是为了在团队内外的高效沟通，也就是，作为承上启下的沟通工具和载体，PRD文档会有强烈的指引性和归档性，PRD的版本管理就至为重要。

版本摘要是一个非常好的方式，清晰的列出当前的版本号，版本范围和需求变更过程，以保障产品需求的及时同步和追溯。

你的目的只有一