2018年11月

目录

第一部分：产品原型规范： 2

一、 文档参数 2

二、 修改记录： 2

三、 总览： 2

四、 全局规范和说明： 3

五、 核心业务流程图； 3

六、 功能模块原型，说明或标注 4

第二部分、需求文档标准（PRD）； 5

一、 文档属性： 5

二、 产品简介 6

三、产品概览 6

三、 产品架构 6

四、 功能说明 7

五、非功能性需求： 9

第一部分：产品原型规范：

产品原型图以实现业务逻辑，详细阐明产品功能为核心

内容构成：文档参数、修改记录、总览（功能结构图）、全局规范和说明、核心业务流程图、页面关系图、功能模块原型。

原型图有清晰的层次、必要的标注、同一个页面的所有状态等。其中结构图明确，流程图清晰，重要页面指示和说明详细。

原型的受众是交互设计师、UI设计师、开发人员和运营人员等，他们在阅读原型时，除了需要明确了解产品定位和目标之外，还需要了解每个模块的核心目标。

一、文档参数

文档参数每个产品经理可以自己增补，至少包含以下内容：

1、文档类型，包括内部文档（只限项目组成员或需求方使用），开放文档（一般作为产品宣传，操作手册等）

2、文档编号，文档性质（prdmrdbrd）项目简称项目版本号（如有）文档日期；

3、文档版本号、产品名称、编写人、编写日期；

二、修改记录：

修改版本、修改前内容、修改后内容、修改位置（链接）、修改时间、修改人；

三、总览：

页面结构图，表现所有功能所需的页面和页面的分级，通常使用脑图即可；

页面关系图，体现页面之间的跳转关系。

四、全局规范和说明：

1、页面结构，指整个项目的通用规则；如首页、列表页、详情的内容通用构成和布局，通用的导航形式等；

2、页面间切换方式，如左右翻页还是上下翻页，进入方式等；

3、手势，左滑、右滑、上滑、下滑，双指滑等；

4、基本条件下的页面状态，无法连接网络、加载中、加载失败、加载成功、页面不存在、上拉、下拉等、未获得授权等、已登录、未登录；

5、申请授权，授权内容、授权触发等；

6、图片相关处理，加载中、加载失败，点击放大等；

7、统一格式，如时间格式、金额格式等；

8、文本框、按钮等；

9、信息提示，弹出框、图层规则等；

交互规范参考：页面状态、页面加载、页面刷新、页面转场、局部刷新、状态切换、热区范围、边界问题、常用字段、异常支线等。

五、核心业务流程图；

流程图包括总体流程和具体功能流程图；

总体流程体现整体业务的操作流程和分支。具体功能流程图需要作为开发的判断依据，清晰定义条件的判断和分支走向。

六、功能模块原型，说明或标注

模型主要体现页面元素和交互。主要由以下模块构成：元素基础设置、交互动作、跳转逻辑、限定极限值、状态及状态之间转换的描述。

1、每个版本涉及改动的所有界面均需表现在原型中，务必覆盖功能的每个场景；

；

2、每个界面的不同状态，每个功能点的不同状态都需要通过原型表现；

例如：列表页没有内容显示什么，内容过多时如何显示；

按钮：已触发和未触发的状态；

登录位置，已登录显示什么，未登录显示什么，点击下拉还是弹出，弹出内容是什么。

3、每一个可点击元素，都能点击跳转到目的位置。并且提现点击热区位置；

4、交互的形式（效果）和内容需要加以说明；

5、原型内容排版需整齐、层级清楚、有层次感；

6、每个原型界面的说明标注内容，可标注在原型的两侧；

7、每个界面都要考虑到异常情况的处理，是否超出全局的规范，需另行说明；

8、需要涵盖内容空白、内容溢出的情况；

9、表单或控件的提示信息需要清洗体现；

10、涵盖信息提示、对话框、弹出等交互信息的形式和位置；

11、严谨的页面层级。

第二部分、需求文档标准（PRD）；

prd框架结构应该至少包含以下内容：文档属性、产品简介、产品概览、产品架构、功能需求、非功能性需求几部分；

一个需求文档只针对一个版本或一次升级，不在此版本上线内容无需体现。

一、文档属性：

1、版本说明：

1）、产品输出的所以文档，都应有的统一命名规范。做到通过文档名称即可看到产品的发展趋势，输出时间周期。

例如：文档版本号—项目名称（项目版本号）—开始时间-结束时间

2）、标记文档的使用类型，包括内部文档（只限项目组成员或需求方使用），开放文档（一般作为产品宣传，操作手册等）

3）、统一文档编号，文档性质（prdmrdbrd）项目简称项目版本号（如有）文档日期；

4）、文档属性还要包括：文档版本号、产品名称、编写人、编写日期；

2、修订历史

需求文档自评审通过或者正式公布之后，每一次的修改都需编写修订记录。

修订记录内容至少包括：修订的日期、当前版本号、修订说明（修订前，修订内容）、修订作者。word文档最好能链接到修订位置。

二、产品简介

通过产品简介的说明，能够向读者清楚传达产品定位和目标。

三、产品概览

1、需求列表；列清本次文档需求点，包括：功能模块、子功能点、说明等内容；

需求确认后，产品经理基于此表，为相关技术经理创建需求任务。

2、全局规则：

只要是需要所有开发人员查看，且适用于整个系统的都可以写进全局规则中，包括：交互说明、屏幕适配、全局字段说明等等。

比如：字段‘邮箱’，在系统中多个地方出现，我们只需要在全局规则写明1次字段‘邮箱’的规则限制即可，而不需要在‘邮箱’出现的每个地方都进行重复编写规则。

通过全局规则，说明什么是页面本身内容，需要在页面显示的，什么是页面逻辑规则。

客户端开发还包括：字体、后台调出、杀死程序后重新打开、网络环境、手势、页面跳转等；

3、名词解释：对于新的业务模式名词或较难理解的概要，可统一在此加以说明和定义；

三、产品架构

1、功能结构；主要使用结构图、脑图等形式讲本次需求的功能结构阐明；

2、业务流程图，主要是需求的整体业务流程图；

3、页面关系图，页面关系图一般只用于移动客户端交互性较强的产品；表明页面间的调整关系，便于前台工程师理解。

四、功能说明

功能说明以模块为单位，进行详细说明；内容包括：该模块设计的交互原型、业务逻辑说明定义、功能流程图、交互信息等；

前台产品还包括：特殊场景、操作与反馈、页面状态、数值限制条件、功能、流程、文案、动效、控件、弹框等说明。

1、交互原型：

依次罗列该模块的原型图片；单个界面中因状态改变导致内容或功能改变较大的均需展示。

每个图片需要编号和标题；

2、逻辑模式：

模块功能描述，首先需要阐明此功能模块的核心目标。清晰定义业务逻辑，说明规则边界。设计计算的内容注明计算公式；并对公式项加以定义说明。

其次以模块为单位，页面为子项，分别描述产品的模块、页面及页面区域元素的功能需求。

示例1：

1、频道名：频道介绍及需求说明

2、页面1：页面介绍及需求说明

2.1、页面模块1：模块功能需求说明

2.1.1、页面模块1-元素1：功能说明

2.1.2、页面模块1-元素2：功能说明

2.2、页面模块2：模块功能需求说明

示例2，关于内容显示：

a. 正常：理想状况

b. 内容为空：内容为空时如何展示，是选择缺省设计，还是直接不展示该模块的内容。这些信息都需在PRD里描述清楚；

c. 内容溢出：文字内容是否有字符限制，超过字符限制会在后台给出相应提示吗？还是超出部分显示为省略号，或者设计展开样式展示更多内容。对于国际化的多语言产品，产品经理还需要考虑不同语言的文字长度是否会影响内容的展示。

私利3，关于用户操作

a. 操作成功

b. 操作失败：是否有相应的提示&提示文案，是弹框提示还是toast提示。操作后页面是否发生跳转？操作失败后是否提示用户再次尝试？

c. 操作超时：一般和网络状况和用户操作时间有关，如果出现这种情况应该如何处理？是否有相应的提示和文案，是否需要用户重新登陆？

2、交互说明：

交互主要由以下模块构成：元素基础设置、交互动作、跳转逻辑、限定极限值、状态及状态之间转换的描述。

1. 规定数据格式、样式，规定数据的展示方式、字段限制；

2. 规定控件的使用规范；

3. 从功能流程的高度，梳理功能的页面层级；

4. 规定数据的前后台交互；

5. 规定临界状态；

6. 页面切换动效的规定和模拟等等。

示例1：

:需要考虑用户的流程，例如一个“完成”按钮，需要描述他完成后，系统要不要给出反馈提示(反馈提示是什么样的形式反馈，内容显示成什么，有没有内容需要调取数据库)，或者要不要跳转页面(跳转到哪个页面，这个页面是其他频道页面，还是这个功能的子页面，如果是子页面就需要再描述这个子页面的模块及元素内容)。

示例2，交互信息的说明方法：

交互信息编号；

信息形式：弹出信息、对话框；

交互形式：三秒隐退、屏幕位置等（应该在全局规则中定义）；

或按钮编号，名称，触发规则；

五、非功能性需求：

产品为满足用户业务需求而必须具有且除功能需求以外的特性。大致包括如下内容，产品经理根据需求的实际需要加以说明，并定义清楚需求条件。

网络需求（网络环境）、数据需求、性能需求、服务需求、安全需求（敏感词库）、接口需求、法务需求、财务需求、帮助需求、统计需求、风险需求、兼容需求（兼容的系统类型、版本、浏览器等）、语音需求、验收需求、设计需求、营销需求、测试需求、参考需求、服务端需求、其他需求