2.内容加载（下拉、松开）

3.页面加载网络正常却没数据

4.页面加载网络异常

5.页面加载搜索没有结果

全局交互

下面罗列下文档中咖啡厅后期策划方案，具体去怎么写全局交互

分为：页面间交互也页面内交互

1.页面间交互

首先是对于Native的交互，另外需要注意H5网页的交互默认是不作处理的，因为就是淡入淡出的效果。

页面间之间的交互，可以进行自定义，但最终进入那个页面，每个页面哪些地方可以进入，可以退出等，PM或交互设计师需要进行说明。以下我分为单张和多张图示进行展示，页面间交互应该如何说明

2.页面内交互

以上为移动端内的页面内交互，可以看到基本为目前常见的人类手势，当然还有长安、双击等交互，目前以上列举的是比较常见的一些手势

六、功能清单

在对于UGC模块中，我将相应的子功能进行罗列，那么这里我们需要以用表格的方式进行统计，方便设计、开发人员以及测试人员对工作量的评估。

当然值得注意的是可能一个模块下有子功能，子功能下面还有子功能，这个时候建议方便文档查看，就以2个层级进行区分，在后方描述的时候进行说明。

七、业务流程

这里的业务流程，我们默认是以用户开始，依照用户的操作，将其流程分为前端和服务端，告知相应端开发人员应该做什么、不应该做什么。

当然这里移动端流程指向的用户相对单一，当然也有按照用户角色来进行区分的流程，常见的就是在ERP或者一些后台产品设计中，PM需要根据不同的角色将相应流程进行绘制。

另一个流程图比较常见就是上面说的根据默认以用户流程，将前端与服务端的流程涉及

PRD需求文档，在创业团队中可能处于一个空置的情况下，为什么这么说？因为你写出来没人看，只能作为一个留底

但在一些成熟性公司中，那么PRD文档不仅仅起着留底的作用，将产品逻辑和用户使用逻辑描述得清楚，将方便开发人员以及测试人员知道如何去进行开发和验收，涉及到数据交互的都应该在服务端与

但值得注意的是流程图千万要清晰、明了，不要弯弯曲曲，混成一团。

八、需求/功能描述

到这里就是PRD主要的篇幅部分，在这里我建议将功能的每个页面进行列举，比如某一个功能

每个功能的描述，我们既然按照功能点进行分类，将不同的子功能分别列举。接下来在文档中我们需要展现的是三部分内容：

1.页面需求描述

说明该页面是干什么的？并且该页面出现的地方，在什么时间出现，需要有什么条件要求

2.交互手势

上面所说的交互手势在这里就可以列举出来了，当前页面能做什么交互手势？哪些手势不能做？

该页面如果只有点击手势，那么即在手势下面写有，并且描述在IOS与安卓那个版本下有，如果没有是否需要开发

3.用例描述

描述点击相应控件或位置，页面后进入到哪一个页面，以什么方式（滑动？弹出？）

这里以开红包方式来描述

用例1：点击开，页面左滑进入红包首页用例结束

4.异常情况

这里的异常情况或许很多PM朋友都没有写进去，说实话，今天以前我也没有写。但和产品朋友交流后我发现，其实异常情况的知晓能够反映出作为PM你目前的经验丰富情况，到底该页面下那些异常会出现，你是否能预知？

大多数PM或许会将该异常情况统一交给测试来处理，因此为了百分百保证这一份分享是最完整的PRD干货，今天就把这个加上了。

用例1：用户未登录，点击红包开，页面左滑进入红包首页用例结束

九、数据统计需求

以上我们的PRD差不多完成了70%，接下来就是为了后期验证跟进做的一些辅助性跟进，那就是对于数据的统计需求。数据统计的需求我们也需要在文档中进行撰写，当然如果有专门的数据部门，我建议PM可以交给数据部门完成，PM将其需求过渡给数据部门。

当然不懂数据的PM肯定不是好PM，为此能够了解产品哪些地方有数据统计，我还是把相应的数据要求提交在文档中。

这一点必须说明的是关于自定义事件LABEL和自定义事件参数，（图中时间改为事件），由开发人员来定就行了。当然如果你是开发转型的PM，你可以来决定，但为了后期的数据参数统计和分类，建议还是直接交给开发人员

这里可以简单举例比如以UGC模块，以发帖事件来进行说明，该页面所能进行的操作都需要将其规则化，以事件名称来确定每个操作的名称，可以满足将其规则化的目的。

十、其他需求描述

综上，基本一个PRD文档就算完成了，但在工作中一个功能模块或一个版本的迭代往往还需要涉及其他需求咖啡厅后期策划方案，涉及人力、财务资源的需求，以及对于每次评审或小团队沟通的记录。这里我也一并同步出来自己在工作中做的一些需求描述，也可以集中放置于项目文档或该PRD文档中。

1.性能需求

性能需求可以以表格的形式对相应的功能模块进行要求，如红包点击弹出的时间在3S内，成功率是99%，并发数是20000。

2.服务需求

来源【写作训练营】自媒体，更多内容/合作请关注「辉声辉语」公众号，送10G营销资料！