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

花了大概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

4.3、PD到UI

4.4、项目开发

4.5、处理BUG

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

修复：简要填写问题原因，并说明如何修复

外部原因：写清楚来源

无法重现：写大概需要哪些条件

问题重复：填写重复问题的bugid

功能设计如此：把功能逻辑链接到这里

是问题但不修复：补充不修复的理由

下版本解决：填写大概解决时间，并在解决后指派给提出者验证

4.6、软件测试

4.7、UAT测试

五、PRD全局清单

六、内禀原则