PRD文档写作详细说明

你是否有过因为PRD文档写得不够好，而被开发怼的经历呢？这里一份详细的PRD文档写作说明，get这份说明，你的开发过程将会很顺利。接下来，就让笔者为我们讲述如何写好一份PRD文档吧。

PRD 文档写作详细说明

取值规则

取值后台字段「xxx」

取值用户点赞次数

取值符合某些条件的多个字段的组合结果

是否去重？

若可以多次输入，是否需要去重？

下架的/清算的/发行失败的等情况是否要取值？

很多前端的内容，都有一个后端的内容与之对应。取值来源大致分为这几种

公司内部

后台字段

可动态变化

直接写上去（写死）

静态页面

用户

如点赞次数、用户评论等

显示规则

显示内容与排版

基本通过原型图表达出来

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

写清楚「文字内容」

「按钮」的文字内容、「提示」的文字内容、页面各处的文字内容，尤其在设计稿与要求的文字内容不同时更应注明。

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

取值数据为空时如何处理

为空

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

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

不为空

显示数量

控制显示数量的作用： 1.用有限的空间显示恰当的数量； 2.保证页面性能； 3.其他。 1.用有限的空间显示恰当的数量 显示数量与空间大小息息相关。 例如限制字符数，就是因为空间限制，无法显示太多字符。 换句话说，控制显示数量，目的在于用有限的空间显示恰当数量的内容。当然，这个「恰当」由用户需求决定。 也就是说，这个逻辑链条是：用户需求-->显示空间与排版-->显示数量。 例如： 对于序号之类的标签，如果序号过大，就要考虑序号是否会超出标签现有大小的限制，要防止其超出限制。 2.保证页面性能。 例如产品列表页限制显示2500个产品，就是出于性能考虑。 3.其他 对输入框，常常会限制输入的字符数，这可能有很多考虑。 例如微博之前限制140字，是出于一种短阅读的考虑； 评论限制字数，可能也有这种考虑，也可能有性能的考虑。

列表

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

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

数量过多时可能影响性能

字段

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

显示格式

数字显示格式

只要有数字，都要限制显示格式。

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

附带xx

带单位？在前面加上xx？

善用颜色

可以用颜色来区分重点

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

排序规则

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

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

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

交互规则

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

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

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

弹窗形式

模态视图？其他视图？

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

可输入区域

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

删除

逻辑删除还是物理删除？

默认规则

默认的取值规则

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

默认的显示规则

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

默认的交互规则

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

当有多个规则时，会有默认的规则。这个不用单独列出，只需列在取值/交互/显示规则当中即可。

边界情况

取值规则

字段为空

显示规则

当没有时如何处理？

列表

无数据时显示什么

单个字段/模块

无数据时显示什么

当数量巨大时如何处理？

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

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

时间显示格式

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

交互规则

操作次数限制

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

输入内容限制

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

返回按钮

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

评论

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

点赞

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

筛选标签

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

是否必填

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

提示

提示多久消失？

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

编辑

是否可编辑

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

异常情况

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

没有网络/网络异常

显示什么？

服务器忙

显示什么？

产品下架/页面被删除等

显示404？还是其他？

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

几个不同状态

例如： 1.点赞 未登录状态下如能点赞，则可能因为未记录点赞用户而导致刷新后能继续点赞，即点赞次数无上限。而且，未登录状态下的点赞次数的接口容易被人调用从而导致恶意点赞。 2.评论 未登录状态下能否评论？如果不能，点击输入框/回复按钮，如何交互？

登录/未登录

认证/未认证

有权限/无权限

报名中/进行中/已结束

对于活动的3种状态——报名中、进行中、已结束，一般而言，应该将「报名中」、「进行中」高亮显示，以突出它们的位置，也便于用户查看和使用，也利于产品宣传。同样地，在排序时，应该将「进行中」的排在最前，其次是「报名中」，最后是「已结束」。

一般不用单独列出，只需列在取值/交互/显示规则当中即可，当然可以通过加粗等方式说明，以提醒读者

APP PRD注意点

需求列举需区分各端

原生页面

IOS/Android/Windows

H5页面

站内H5页面

站外H5页面

后端

H5页面

站内H5页面

站外H5页面

分享页点击跳转

是否要二次转发

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

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

跳转站外哪个分享页

跳linkme到站内哪个页面

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

站内站外的不同也要列举出来——针对H5页面

版本兼容

原生页面无法向下兼容

H5页面

是否做版本管理的区别

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

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

站内、站外H5页面的区别

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

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

分享

分享图标

分享标语

分享内容

分享渠道

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

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

通知类

通知标题

通知内容

点击跳转页面

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

其他

大的需求不要写"优化"

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

键盘按钮

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

其他

工作流程注意点

策划/PRD

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

在需求设计（包括PRD撰写）时，要查看设计稿的原比例图而不要看其缩小后的图（这可能也是乔布斯总喜欢看设计出的实物的原因，毕竟实物与设计效果是两种东西），这样可能导致需求设计考虑不周。

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

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

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

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

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

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

设计

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

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

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

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

开发

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

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

增删查改最好都要标记

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

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

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

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

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

发版

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

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

测试

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

运营

上线前要录入对应数据

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

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

数据统计需求

法务需求

……

产品某些特征导致的注意点

历史情况

对于一款已有产品，都要考虑历史积累，几乎不可能完全推翻重来

历史数据处理也很重要

公司内部多端打通

如PC、M端、APP端、前后台、数据中心等

一端更改，可能涉及其他端，要考虑到，否则可能影响其他端的功能

合规处理

一对多、多对一之类的

M端

关于微信

微信自带头部，因此需要说明导航栏内容

微信分享需要提供分享信息

前端可以对标题等内容进行自动适配——根据手机屏幕大小进行自动适配，所以常常可以不用限制具体的字符数，而只需限制显示1行即可

对于可编辑的字段，空格是否作为有效字符也需要考虑

对于 [密码]，空格可以作为有效字符（如果技术上无法实现，也可以不作为有效字符）； 而对于一些普通字段，则要具体情况具体分析。例如：对于一个必填字段，填了空格后在页面上无法显示任何有效内容，则应该将其作为无效字符；反之则相反。

后台字段

需要考虑

字段名

数据类型

字符型？数值型？等

是否必填

是否可修改

下拉框选项

备注等

例如

后台需注意的几个字段

权重、状态（有效，无效，已删除）

权重用于排序

状态用于确认是否有效

富文本编辑器还是普通文本编辑器要说清楚

尽量保证一个字段只有一个编辑入口

便于开发

信息架构清晰、简单，便于使用者理解

计算规则

某个数字如何计算？如收益率