PRD1.0 分享：全面通用的移动端产品需求文档

2017-01-16 11:32:00

花了大概1年整理出一份全面通用的移动端产品需求文档，包含了我多年产品经验以及对业务的理解，对技术原理的涉及。命名为浪子 PRD1.0 ，请查看全文后再直达源网址。

这份PRD虽然内容很全面通用，但是还不够系统结构化。所以才命名为1.0。首先希望对大家有帮助，其次希望大家给我提建议，然后可以不断迭代到2.0、3.0……

营销出身，先做运营，后转产品，一直研究技术原理。做过B端、C端产品。做过PC client、Web产品、H5 app、原生app、多平台产品。现在做移动端社区电商APP的商城模块。相信这样的经历和大家应该可以共鸣。

从网上学到了很多产品文章，最终自己也算是略有心得，所以特此回馈给大家。

先预览一下PRD的结构

一、画原型的步骤

二、PRD撰写原则

其实我觉得这个特别重要，但是偏理论了。

大原则

业务优先于需求，需求优先于功能，功能优先于交互，交互优先于UI。

PRD的目标

旨在对APP项目的业务架构&产品流程&功能需求做详细的介绍，为产品后续的需求、设计、开发、测试、上线提供依据。

向项目组成员(项目经理、开发、测试、运营)传达产品的业务信息与需求细节。
管理需求，进行归档，为后续需求迭代与变更提供依据。
实现项目的规范化管理。

PRD的撰写说明

只有一种输出物，在线原型。
只用原型传达思想和表意，不过度考虑视觉呈现。
逻辑确定后不经常改动，如有必要上线前统一和前端对照并修改。
内容文案是否经得起推敲，顶部标题以及按钮文案以及各种小提示是否简洁清晰。
内容结构：一级目录使用”一”，二级目录使用”1″，三级目录使用”③”。
元件样式和交互的通用规则，请写到全局规范。其他写到对应的元件逻辑中。
写的逻辑禁止不确定字样(也许/可能/maybe/考虑/好像/类似/暂时/待定/等等/像/真的/？)
所有变量统一使用红色表示并且配上说明，比如满x元减x元。
英文单词尽量小写，易识别。除非是约定俗成的词语，比如iOS、Android。
双引号&单引号&小括号不使用全角，只有半角。

需求描述原则

表述清楚需求的位置是在什么位置，比如”x”页面、还是”x”页面的”x”元件。
需求是新增”x”功能、还是修复”x”bug、还是优化”x”功能。

技术处理原则

某些场景下技术上可以考虑合并多步操作，以减少客户端对于异常情况的判断。比如确认订单页面的保存地址并返回运费。
某些警告框应该当做页面来处理数据埋点以及交互，单独说明。
尽量解耦到每一个页面，每一个警告框，而不是多个页面之间关联性太强。

PRD的核心模块

页面，写在Axure的Pages中。生成原型后请点击左侧Pages进行查看。
交互，写在Axure的Interaction中。生成原型后请点击左侧Pages中的链接图标进行展示和隐藏。
逻辑，写在Axure的Notes中。生成原型后请点击左侧Notes后查看，或者点击右侧元件旁边的图标进行查看。

元件的逻辑有5种，具体如下：

功能逻辑：详细讲解该功能的逻辑。
交互逻辑：对页面之间的相互跳转进行说明。
视觉逻辑：对颜色，对图标的要求。
业务逻辑：讲一下该功能对应着什么业务。
技术逻辑：有些逻辑可能用技术语言描述更清楚一点，以及对技术有特殊的要求。

关于命名

动作，状态的命名一定要区分，比如删除是动作，已删除才是状态。
动作的命名一般是”操作+名词”，比如修改文章。
条件的命名一般是是否怎么样。
功能的命名要么是名词，比如购物车；要么是动宾短语，比如确认订单。

其他说明

PD指产品经理，产品设计师
PM指项目经理

三、PRD阅读指南

四、产品工作流程

4.1、发布原型

4.2、制作H5

[查看大图](http://51prd.com/# g=1&p=制作H5)

4.3、PD到UI

4.4、项目开发

4.5、处理BUG

所有问题都需要填写注释。

修复：简要填写问题原因，并说明如何修复
外部原因：写清楚来源
无法重现：写大概需要哪些条件
问题重复：填写重复问题的bugid
功能设计如此：把功能逻辑链接到这里
是问题但不修复：补充不修复的理由
下版本解决：填写大概解决时间，并在解决后指派给提出者验证

4.6、软件测试

4.7、UAT测试

五、PRD全局清单

六、内禀原则

内禀规则是什么？指业务实体本身具备的内在规则，并且不受外部以及用例交互的影响。这类规则应该实现到你的实体类中，根据面向对象的封装原则，内禀的逻辑一定不要让它暴露到外部。不论你的业务实体是EntityBean，JavaBean，POJO还是COM+。

操作者是谁？程序员

如何获得？需要对每个业务实体的属性进行罗列，并找出它们的规则。最主要的来源是业务执行者，需求人员应该更多的去与他们交流。

6.1、时间

日期： yyyy-mm-dd

周几：周一/周二/周三/周四/周五/周六/周日

时分： hh:mm

时分秒： hh:mm:ss

发布于什么时间：

适用于消息列表/消息详情/动态列表/视频列表/直播列表等feed流，详见下方流程图
当前时间取本机时间，有精力的话前端童鞋可加判断，如果发现本地时间和服务器时间不一致，需做统一。

其他：

建议服务端按照时间戳来存储，并且格式是yyyy-mm-dd hh:mm:ss

6.2、距离

一、绝对距离如何显示

xm，当距离＜1000米，比如356m
xkm，≥1000米，比如5km
最小值是1m，最大值9999+km。

二、地理位置如何显示

显示格式”省份城市”，比如江苏南通，如果取不到显示”未知”。注意直辖市只显示”直辖市名称”。

6.3、账号

什么是账号？

用户的唯一身份id

如何处理抢登？

当用户使用手机a登录了账号，又去用手机b去同一账号，从而形成抢登。

第一个手机收到推送，显示警告框”该账号已在其他手机登录，如非本人请赶紧登录然后修改密码。”和确定按钮，点击确定按钮回到App首页并重新加载。

其他

身份证号必须是15或18位
手机号必须是11位

七、交互规则

交互规则是什么？产生于用例场景当中，规定了满足什么条件后业务将如何反应。比如当提交一份订单时，哪些数据是必须填写的，用户身份是否合法。当然也包括一般理解上的业务流程流转规则等，比如金额大于一万元的订单被定为VIP订单进入特殊流程等。

交互规则实际上还有两个是比较特殊的，一个是前置条件（入口条件），即Actor满足什么条件才能启动用例；另一个是后置条件（出口条件），即用例结束后会产生哪些后果。通常这部分规则是复杂多变不稳定，所谓的需求经常变更绝大部分来自于此。因此将这些规则单独列出来并给予关注和管理是很有必要的。同时这部分规则通常在系统中以Control类去实现，MVC模式/SOA架构中的BPEL也是如此。既然需求无可避免的要变更，那么将交互规则单独提取出来，并设计成为扩展性很强的结构就是一种有效的应对手段。

操作者是谁？交互设计师or产品经理

如何获得？从用例场景而来，每一个场景，每一个交互的过程可能都隐含着规则。需要与客户多讨论。交互规则最主要的来源是业务提出者和业务管理者，最好不要去找业务执行者。

7.1、状态切换

7.2、常用输入字段

7.3、边界问题

需要处理的异常边界

异常处理一般来说，PM还是会非常重视的。比如购物车商品减到0需要提醒用户二次确认是否把商品从购物车去掉、或者用户输入的密码不符合规范，需要提醒用户调整。这些很多异常情况，PM是需要把自己放空，通过很多非正常交互流程去模拟和梳理的。比如购买流程不可逆，此时用户想点返回了，哪一步是可以到上一步，哪一步到不了上一步，这些就是交互设计的细节。