以用户体验五要素的思路，如何编写产品需求文档（PRD）

1、PRD的用户是谁？

首先，与你们先分享一句话：把需求文档当成一个“互联网产品”去管理，理解它的用户，关注它的体验，不停迭代，使其价值最大化。（引用）

既然把它视为一个互联网产品，那咱们须要思考PRD的用户是谁，他们经过PRD要了解什么内容？

根据用户以及他们的诉求。

我把PRD分红几个阶段：

1）MRD阶段

这个时候，主要须要说服咱们的老板、或者团队内部评审，也会有需求方，让你们认同你的方案，知道你要作什么怎么作。

因此这个时候相似于MRD，把整个方案路线说清楚就能够，作一个较粗线条的DEMO图。

切勿作细化的设计稿，更不要写详细的功能说明，由于这时候被拍的可能性很大。

2）PRD V1.0

若是经过了第一步评审，这时能够作细化的内容，作一个相对细化的DEMO图，这一步面向开发、交互，开发进行技术上的评估。

交互是下一步真正要作事儿的人，会关注一些页面的细节，因此这个时候能够作详细的DEMO图，并在DEMO图右侧配以一些说明，方便交互及UI进行工做。

不要写详细的界面操做说明，不过能够在进行界面设计期间，先写一些业务逻辑相关的内容。

3）PRD V2.0

这个就是全版了，这么细化的内容，只有真正作这块功能的开发同窗才会细看，写细写全没得说了。

了解了不一样用户的诉求，那咱们就具体说下PRD编写的内容吧。

2、围绕用户体验要素的PRD编写

为何要说围绕用户体验要素来编写PRD，由于产品的设计是围绕着这个经典的框架来的，那写PRD的任务固然是要把这个内容向你们表述清楚。

用户体验要素

下面就具体说下PRD如何围绕这个内容编写。

第一部分：需求概述

其实不只仅是作产品，任何事情，第一步确定是要想清楚要作什么，为何要作，也就是把战略层描述清楚，PRD的第一部分就是要把这块内容说清楚，回答出下面的问题。

1）用户要得到什么？—— 用户痛点、需求

建议这块内容，说清楚总体的问题痛点，同时也要举具体case，列举数字，如用户的使用频次，如今的花费等等。

2）用户是谁？—— 用户细分、用户数量、画像

用户是谁，并非如“商家用户”这种粗线条的描述，要说清楚对于当前的功能，是哪类用户在什么场景下的需求，用户的量级是怎样的，有一个相对具体的画像。

3）用户能经过这个获得什么？ —— 用户收益

这里面补充个内容，俞军老师曾说过，用户净收益=新体验-旧体验-替换成本，替换成本多是获取成本、认知成本、资金等等， 虽然这些内容并非真正可衡量的，但在作一款新产品评估其价值时，能够从这几个角度进行思考。

4）咱们能获得什么？—— 对企业能带来什么收益

这点很重要，作任何产品，给用户赋能，给用户带来价值，其主要目的仍是企业自身可以盈利，这点想清楚才能说服老板提供资源呀。

第二部分：产品规划

最抽象的战略层说清楚了，下一步就要大致说下为了实现上面列举的各类想法目标，要一步一步怎么作了，也就是说清范围层的内容。

1）功能&信息结构图

范围层，就是要说清楚，为了实现战略作什么事情，什么功能，提供什么内容。这块通常会经过脑图或者框架图来展示，说清楚咱们须要哪些数据，作哪些功能，各个功能与功能之间的关系。

要注意，这部分须要在长远角度，解决这个问题地整条路线进行思考。举个例子吧，好比要作个评论功能，让用户对产品更了解，并带来更多销量。那第一步先增长评论功能，以后能够对评论进行分析，为用户推荐高质量的产品，发现问题产品保证平台产品质量等等。相似这样，出一个总体的规划蓝图。

2）路线规划

蓝图出来了，仍是要落地的。因此这一步要把刚才地蓝图，切成一块一块，每一步要作什么，多长时间，这个阶段解决怎么的问题，为后面提供什么铺垫。有些内容，也能够出一个简易的DEMO图，能描述清楚便可。

第三部分：功能概述

这一部分是对当前这一期要作的内容的详细描述了。这部分面向的主要用户是UI、交互、开发、测试同窗，具体到作事情上，就是把你们的认知拉齐。

1）产品流程图

经过图的方式，能够快速、方便地告知PRD的每一个用户这个功能的思路流程。这里最开始放的是比较粗线条的流程图，好比买家购买商品，加入购物车->付款->商家发货->确认收货。而一些细节，好比买家超时未付款，或者卖家修改价钱等等，能够到具体写到这个功能点地时候再出一个细化的流程图。

2）DEMO，原型制做，这个就不用多说。

3）UI稿，这块是UI同窗完成后，放上来，统一相关资料的获取入口。

4）产品功能点，后面来细说。

补充两块，流程图和产品功能点：

产品流程图——UML（统一建模语言）

Unified Modeling Language (UML)又称统一建模语言，为软件开发的全部阶段提供模型化和可视化支持，简而言之，就是用图的方式把事情描述清楚。在这里有两个概念，类和对象。类是把一类事物的抽象，而对象是类的实例。好比汽车是一个类，某辆车就是个对象了。对于产品经理，这两个词其实含义基本等同了。

下面我以员工提交权限审批这件事为例，对应地类（或者说是对象）有员工、老板、仍是审批单，给你们主要介绍4个图。

1）活动图

咱们也常常叫流程图，就是要描述清楚各个角色之间的工做流程。

矩形框内描述当前活动，菱形块列出分叉路线。若是有多个角色，以下面的例子，则将每一个角色出一个泳道，对应哪一个角色的活动即放到哪一个泳道下。

2）序列图

这个图是各个对象之间的一个描述，与活动图略有类似，能够看下面的例子，咱们在平常工做中，选取其中某一个把事情说清楚就OK了。

这里每一个对象会有一个生命线，我把系统自己单出来，作了一条生命线，员工、老板在进行某些操做后，须要系统这面进行保存或者修改状态，那右侧即对应与数据库的交互，后端同窗根据这个，大致就了解本身在何时要作什么事情了。

3）状态图

状态图的样式，虽然说和活动图样式差很少，但其实内容差异还挺大的，状态图是对一个对象的不一样状态切换进行描述。好比权限审批这个事情，审批单有“审批中”、“未批准”、“批准”这3种状态，经过这个图能够很清晰地了解各个状态的转换方式。

4）类图

描述类的内部结构和类之间的关系，这个用得很少，能够简单了解下。

仍是这个功能，咱们有员工、审批单、老板这3个类，他们有些属性，对于员工和老板还有一些操做，能够经过这个类图来表述出来。其中有个+-号，+号是public，即其余类可见，-号是private，其余类不可见。好比员工的姓名，其余类没法获知，但能够经过一些对象操做得到。这个就有些偏开发的内容了，不是特殊须要开发同窗知道信息，能够不对这块进行标注。

产品功能细化说明

这块就是要把功能说得足够细，但也是有一些技巧。

1）更新说明

首先，我通常会在功能最上方，列出更新的清单，通常记录有：调整时间、调整功能块、详细说明。

2）全局说明

每期功能可能会有多个页面多个功能块，但有一些想通的地方，好比对于数据产品，数字的展示形式，保留2位小数，增长三分位符号等；对于移动端产品，一些操做方式等。这个适用于各个块，不用分别在每一个中单独说明，并且后续作其余功能都是能够复用的，能够先列出来讲清楚。

3）具体每一个块的功能说明

• 前置条件：有些功能可能会有这个内容，在什么状况触发这个功能，好比在用户购买什么商品后提供某个功能；
• 主体功能说明
• 流程描述：主流程、分支流程，这个就可使用上面介绍的UML图，把主线条描述清楚；
• 界面描述：操做、文案，文案建议其余颜色标注出来，防止和描述弄混；
• 业务规则：这个是在界面看不到的，好比限制条件、表格的排序规则、须要记录的数据、还有一些数字的计算公式等等；
• 异常描述：这个不能忽略，尤为是C端产品，考虑须要更为全面，由于极可能就是一个小异常，就致使用户使用不爽而流失，好比上传文件没有考虑超出大小怎么办，用户上传后一直没反应，就会认为这个产品很差用，转而使用其余产品，因此，异常地考虑很重要。列几个常见的异常：如未输入、输入错误、无数据，无网络，长时间未操做，异常退出等等。

最后说下写这块内容的原则

• 完整：足够细，考虑足够周全；
• 无歧义：RD同窗是拿着这个文档真真切切写代码，因此说得内容，要可以落到代码上，好比用户一段时间未操做则提示。。。，等待多长时间，要写清楚；
• 有条理：这文档是有人看的，因此序号、符号都适当的用上，让你的文档容易阅读；
• 及时更新：功能、DEMO的调整，都须要落到PRD上。

第四部分：数据需求

由于我本人是数据产品的产品经理，因此这一部分对于咱们很重要，须要哪些维度、哪些指标，指标的来源库表字段、计算口径是什么，这些都要清晰地记录下来。

除此以后，有个内容可能常常会被忽略，就是数据的整理。以某宝的搜索结果页为例，通常会展现图片、标题、价格、销量、卖家名称、包邮会标记出来，这些RD经过UI稿可能会查看到，但有一些好比鼠标移入显示信息，点击操做、是否购买过，都在商品展现时体现出来。

这些内容，咱们可不能期望RD同窗从UI稿中一点点发现。因此列出这样的表格，把你认为须要的类及其属性列清楚，有点相似咱们上面类图中对象属性要描述的内容，目的是让开发同窗对照这个来进行库表设计，不要遗漏某些点。

第五部分：数据埋点

包括按钮的埋点&内容的埋点，能够经过截图+表格说明的方式，截图标明须要埋点哪些控件，表格说明对应控件的什么信息，如操做PV、UV、输入内容等。

第六部分：效果评估方案及上线安排

对于C端产品，这块内容会更加剧要，通常会有个灰度发布过程，所以须要说清楚灰度发布的方式，放量安排、节奏，须要关注的指标，这个指标如何进行评估，达到什么样程度能够所有上线。

第七部分：人员排期

OK，大功告成了。

3、PRD的承载

最后说一点：PRD的存放。

我尝试过几种方式，以前就在axure中完成，在DEMO的右侧进行说明，但这个很差的是：在进行更新后，还要发送给你们，各个版本的存放加上axure自己下载解压就比较麻烦，因此并非最佳方案。

我如今通常是用wiki来完成，只要一个连接，更新后只要告知你们同步下信息就好，就是在写功能时候，须要把DEMO对应图贴上去，RD可以比较方便知道是对哪块内容的描述。

对于上述内容，我通常分红2个wiki页记录，一个记录需求概述和产品规划部份内容；一个记录产品功能及以后的内容，这个是当前这期的事情。一个总分的结构。

以上是我我的写PRD的一些经验总结，但愿对你们有帮助。不过，这个PRD的编写并不适于全部公司，一份完善的PRD须要花费比较多的时间，对大公司来讲，对接方比较多，颇有必要这样一份文档统一各方的认知；而对于创业公司，将产品快速落地投放市场进行验证更为重要，因此这个时候千万不要把时间花费到PRD上面。