PRD文档规则详细说明思维导图模板_ProcessOn思维导图、流程图

显示规则

显示内容与排版

基本通过原型图表达出来

按钮、图标、文字、图标+文字……

写清楚「文字内容」

文案、提示说明（填写说明）。例如增加功能，是叫“新增”还是“增加”还是“+”？

取值数据为空时如何处理

为空

若数据为空是否用「xx」（如「--」）代替？还是隐藏？

如果隐藏，是否要连字段一起隐藏

不为空

显示数量

列表

显示多少列表内容？是否使用分页？一页显示多少？不使用分页显示多少？

显示多少数量才不影响性能？

数量过多时可能影响性能

字段

显示多少字符？超过多少数量时是否以...或其他符号（如--）代替？被代替的部分是否在某种情况下显示（如鼠标悬浮时、显示在title中）？还是截断？

显示格式

数字显示格式

时间/距离/金额/百分数/小数点等数字的显示格式

附带xx

带单位？在前面加上xx？

善用颜色

可以用颜色来区分重点

尽量涨跌只用一种颜色，保证一致性

排序规则

按照xx排序？xx相同如何排序？

优先按照xx排序，其次按照yy排序

xx相同则随机排序，这个&quot;随机排序&quot;也要写出来

状态规则：

不同状态之间切换的触发点是什么，如：状态为已发布的文章，要变为下架，可能的触发条件有：发布时间已过期、手动操作下架等

交互规则

当前页打开，还是新开页面打开

鼠标悬浮、点击、按压等时的颜色变化

提示形式——toast? dialog? snackbar? 还是其他形式？

弹窗形式

如何关闭弹窗？能否点击弹窗外区域以关闭弹窗？

可输入区域

输入的方式是否限制（键盘输入？下拉框选择？点击标签自动添加等？）？输入的数据类型是否限制（数值型？字符型？）？输入的字符数是否限制（超出限制如何提示？）？是否必填？

删除

逻辑删除还是物理删除？

默认规则

默认的取值规则

默认取值xx，当xx为空则取值yy

默认的显示规则

默认显示xx，当....则显示yy

默认的交互规则

导航栏，默认选中某个标签

边界情况

显示规则

当没有时如何处理？

列表

无数据时显示什么

分支主题

单个字段/模块

无数据时显示什么

当数量巨大时如何处理？

列表显示数量过大时可能影响性能，要与开发协商处理措施

避免影响性能、网页加载速度

时间显示格式

显示时间区间格式：若开始时间和结束时间为同一天，那么是否只显示一个时间即可？这样更简洁，也更容易阅读。

交互规则

操作次数限制

是否要限制？如要限制，限制多少次？达到上限后如何提醒？

输入内容限制

是否要限制？如要限制，限制多少次？达到上限后如何提醒？

返回按钮

若上一个页面为空，则返回哪里？

刚评论成功时，评论显示在最上方。刷新后，再按照排序规则显示

未登录状态下如能点赞，则可能因为未记录点赞用户而导致刷新后能继续点赞，即点赞次数无上限。而且，未登录状态下的点赞次数的接口容易被人调用从而导致恶意点赞。

筛选标签

能否同时选中多个？如能同时选中多个，页面显示什么内容？按照什么规则显示？

是否必填

必填提示、未填写的提示等

提示

提示多久消失？

比如toast提示，是否3s后消失？

编辑

是否可编辑

涉及到编辑时，要描述清楚编辑成功后的交互。比如保存后是否要刷新页面

异常情况

出现异常情况时如何处理？

没有网络/网络异常

显示什么？

服务器忙

显示什么？

产品下架/页面被删除等

显示404？还是其他？

比如恶意评论、恶意刷分等

几个不同状态

登录/未登录

认证/未认证

有权限/无权限

报名中/进行中/已结束

APP PRD注意点

需求列举需区分各端

原生页面

IOS/Android/Windows

H5页面

站内H5页面

站外H5页面

后端

H5页面

站内H5页面

站外H5页面

分享页点击跳转

是否要二次转发

哪些页面有，哪些页面没有要确认清楚。有些页面没有站外分享页面。

点击哪些区域进入哪些位置要确认清楚

跳转站外哪个分享页

跳linkme到站内哪个页面

边界情况要确认清楚，比如无数据了是否显示某些按钮等等。

版本兼容

原生页面无法向下兼容

H5页面

是否做版本管理的区别

如果做了版本管理，则新旧版本可以独立

如果没做版本管理，则只有一种页面——新版本页面

站内、站外H5页面的区别

站外H5页面无法区分旧版本APP，只能统一用一种方式处理。

站内H5页面可以区分新旧版本APP，可以针对不同版本APP做不同处理。

分享图标

分享标语

分享内容

分享渠道

通用分享渠道就是各个APP常用的那几个，比如微信、朋友圈、微博等等。如果需要特殊分享的，需要标注出来，特殊分享如点击后生成图片分享之类的。

有分享功能的页面，都要带上「分享」按钮

通知类

通知标题

通知内容

点击跳转页面

push确认——是否需要push，点击push后跳转的页面，push的时间、样式等

其他

大的需求不要写&quot;优化&quot;

每个版本都涉及APP启动页更新

键盘按钮

比如键盘右下角的回车按钮，在搜索时，点击后可以搜索

其他

工作流程注意点

策划/PRD

在策划/写PRD时，要查看设计稿的原比例图而不要看其缩小后的图，以免影响判断

尽量使用最终用户会用的，才能形成更正确的判断

文不如表，表不如图，能用图的就用图

用原型图表示所有可能出现的样式、形式

要把页面上涉及的样式都补充完整，比如社区列表页，就会包括各种情况——长文、短文、红包、转发（分多种情况）……

流程较复杂时，要用流程图梳理流程

情况较多时，多用思维导图梳理

设计

需设计、前端参与的需要标注清楚

给设计的PRD要尽量具体，尽量考虑到设计会问的问题

例如超过部分用...替代，那么...就要体现出来

给的文字内容需要便于复制，比如一些带交互的地方，可以在旁边备注好文字内容，便于设计复制

开发

如果有与线上功能类似的，就尽量保持一致，降低开发理解难度与开发成本

多为开发考虑，提需求前要考虑清楚，并看看开发目前的排期，避免给开发造成太大压力

增删查改最好都要标记

现有产品有的最好能提供个URL之类的，便于开发查找

对于以后可能会作为通用模块使用的，要备注出来，否则开发可能会忘记，导致后续效率降低

对于关联性较强的数据，开发难度往往更大，此时应更多地考虑性能

如果更改频率低，写死比在后台添加更好

对于更改后与更改前相同的部分，最好写清楚是哪里（取值/显示/交互等）不变，便于开发找到代码

发版

对于web端，先前端发版，再后端发版，避免上线后样式出现问题

更改任何需求，都要知会相关人员。最好是：版本负责人知道--&gt;需求文档变更--&gt;然后才是开发和测试同学知道

测试

争取在测试环境发现所有问题，以保持线上稳定、准时上线

运营

上线前要录入对应数据

对运营而言，需要他们配置的字段，最好都能有一个排序功能

这样他们可以快速比较，快速找出异常项/突出项，从而对这些内容进行更改

……

文档注意

没有逻辑硬伤

指文档的内容前后不一或者逻辑不通。一旦有硬伤出现，那么文档显然就不可用，技术的同事会搞不清楚到底该怎么做

没有疏漏

有经验的产品经理出现硬伤的几率不大，但是疏漏的可能还是有的，一个功能牵连的信息和逻辑越多就越会有考虑不周的地方，没有定义清楚细节，让技术的同事开发到一半，发现有的功能应当有，但是没有描述。只好再找产品经理进行补充。

逻辑清晰

有的文档内容写的零零散散，会给技术的同事造成困扰，看过很多遍不知道如何下手，产品设计可以松散，但是技术人员开发时如果不从全局出发定义问题就无法开展工作，这是需要产品经理尽量在文档里配合的。

可读性强

很多产品经理只是考虑把事情说出来，但是不是友好的说出来。有很多数据、信息、流程的展现用图标更清楚，但是因为懒得做，就几行字说一下，大大增加了理解成本，有很多名词、解释都说的模棱两可，难以理解。使得技术在后续的时间需要向产品经理确认。有很多可能被误解的名词，最好在文档头部进行说明。