PRD文档规则详细说明
2021-11-16 17:51:36 3 举报AI智能生成
登录查看完整内容
PRD文档规则
作者其他创作
大纲/内容
按钮、图标、文字、图标+文字……
基本通过原型图表达出来
文案、提示说明（填写说明）。例如增加功能，是叫“新增”还是“增加”还是“+”？
写清楚「文字内容」
显示内容与排版
如果隐藏，是否要连字段一起隐藏
若数据为空是否用「xx」（如「--」）代替？还是隐藏？
为空
不为空
取值数据为空时如何处理
显示多少列表内容？是否使用分页？一页显示多少？不使用分页显示多少？
数量过多时可能影响性能
显示多少数量才不影响性能？
列表
显示多少字符？超过多少数量时是否以...或其他符号（如--）代替？被代替的部分是否在某种情况下显示（如鼠标悬浮时、显示在title中）？还是截断？
字段
显示数量
时间/距离/金额/百分数/小数点等数字的显示格式
数字显示格式
带单位？在前面加上xx？
附带xx
可以用颜色来区分重点
尽量涨跌只用一种颜色，保证一致性
善用颜色
显示格式
按照xx排序？xx相同如何排序？
优先按照xx排序，其次按照yy排序
xx相同则随机排序，这个"随机排序"也要写出来
排序规则
不同状态之间切换的触发点是什么，如：状态为已发布的文章，要变为下架，可能的触发条件有：发布时间已过期、手动操作下架等
状态规则：
显示规则
当前页打开，还是新开页面打开
鼠标悬浮、点击、按压等时的颜色变化
提示形式——toast? dialog? snackbar? 还是其他形式？
如何关闭弹窗？能否点击弹窗外区域以关闭弹窗？
弹窗形式
输入的方式是否限制（键盘输入？下拉框选择？点击标签自动添加等？）？输入的数据类型是否限制（数值型？字符型？）？输入的字符数是否限制（超出限制如何提示？）？是否必填？
可输入区域
逻辑删除还是物理删除？
删除
交互规则
默认取值xx，当xx为空则取值yy
默认的取值规则
默认显示xx，当....则显示yy
默认的显示规则
导航栏，默认选中某个标签
默认的交互规则
默认规则
分支主题
无数据时显示什么
单个字段/模块
当没有时如何处理？
列表显示数量过大时可能影响性能，要与开发协商处理措施
避免影响性能、网页加载速度
当数量巨大时如何处理？
显示时间区间格式：若开始时间和结束时间为同一天，那么是否只显示一个时间即可？这样更简洁，也更容易阅读。
时间显示格式
是否要限制？如要限制，限制多少次？达到上限后如何提醒？
操作次数限制
输入内容限制
若上一个页面为空，则返回哪里？
返回按钮
刚评论成功时，评论显示在最上方。刷新后，再按照排序规则显示
评论
未登录状态下如能点赞，则可能因为未记录点赞用户而导致刷新后能继续点赞，即点赞次数无上限。而且，未登录状态下的点赞次数的接口容易被人调用从而导致恶意点赞。
点赞
能否同时选中多个？如能同时选中多个，页面显示什么内容？按照什么规则显示？
筛选标签
必填提示、未填写的提示等
是否必填
比如toast提示，是否3s后消失？
提示多久消失？
提示
是否可编辑
涉及到编辑时，要描述清楚编辑成功后的交互。比如保存后是否要刷新页面
编辑
显示什么？
没有网络/网络异常
服务器忙
显示404？还是其他？
产品下架/页面被删除等
比如恶意评论、恶意刷分等
出现异常情况时如何处理？
异常情况
登录/未登录
认证/未认证
有权限/无权限
报名中/进行中/已结束
几个不同状态
边界情况
IOS/Android/Windows
原生页面
站内H5页面
站外H5页面
H5页面
后端
需求列举需区分各端
分享页点击跳转
是否要二次转发
哪些页面有，哪些页面没有要确认清楚。有些页面没有站外分享页面。
跳转站外哪个分享页
跳linkme到站内哪个页面
点击哪些区域进入哪些位置要确认清楚
边界情况要确认清楚，比如无数据了是否显示某些按钮等等。
原生页面无法向下兼容
如果做了版本管理，则新旧版本可以独立
如果没做版本管理，则只有一种页面——新版本页面
是否做版本管理的区别
站外H5页面无法区分旧版本APP，只能统一用一种方式处理。
站内H5页面可以区分新旧版本APP，可以针对不同版本APP做不同处理。
站内、站外H5页面的区别
版本兼容
分享图标
分享标语
分享内容
通用分享渠道就是各个APP常用的那几个，比如微信、朋友圈、微博等等。如果需要特殊分享的，需要标注出来，特殊分享如点击后生成图片分享之类的。
分享渠道
有分享功能的页面，都要带上「分享」按钮
分享
通知标题
通知内容
点击跳转页面
push确认——是否需要push，点击push后跳转的页面，push的时间、样式等
通知类
大的需求不要写"优化"
每个版本都涉及APP启动页更新
比如键盘右下角的回车按钮，在搜索时，点击后可以搜索
键盘按钮
其他
APP PRD注意点
站内站外的不同也要列举出来——针对H5页面
尽量使用最终用户会用的，才能形成更正确的判断
在策划/写PRD时，要查看设计稿的原比例图而不要看其缩小后的图，以免影响判断
要把页面上涉及的样式都补充完整，比如社区列表页，就会包括各种情况——长文、短文、红包、转发（分多种情况）……
用原型图表示所有可能出现的样式、形式
流程较复杂时，要用流程图梳理流程
情况较多时，多用思维导图梳理
文不如表，表不如图，能用图的就用图
策划/PRD
需设计、前端参与的需要标注清楚
例如超过部分用...替代，那么...就要体现出来
给设计的PRD要尽量具体，尽量考虑到设计会问的问题
给的文字内容需要便于复制，比如一些带交互的地方，可以在旁边备注好文字内容，便于设计复制
设计
如果有与线上功能类似的，就尽量保持一致，降低开发理解难度与开发成本
多为开发考虑，提需求前要考虑清楚，并看看开发目前的排期，避免给开发造成太大压力
增删查改最好都要标记
现有产品有的最好能提供个URL之类的，便于开发查找
对于以后可能会作为通用模块使用的，要备注出来，否则开发可能会忘记，导致后续效率降低
对于关联性较强的数据，开发难度往往更大，此时应更多地考虑性能
如果更改频率低，写死比在后台添加更好
对于更改后与更改前相同的部分，最好写清楚是哪里（取值/显示/交互等）不变，便于开发找到代码
对于web端，先前端发版，再后端发版，避免上线后样式出现问题
发版
更改任何需求，都要知会相关人员。最好是：版本负责人知道-->需求文档变更-->然后才是开发和测试同学知道
开发
争取在测试环境发现所有问题，以保持线上稳定、准时上线
测试
上线前要录入对应数据
这样他们可以快速比较，快速找出异常项/突出项，从而对这些内容进行更改
对运营而言，需要他们配置的字段，最好都能有一个排序功能
运营
……
工作流程注意点
指文档的内容前后不一或者逻辑不通。一旦有硬伤出现，那么文档显然就不可用，技术的同事会搞不清楚到底该怎么做
没有逻辑硬伤
有经验的产品经理出现硬伤的几率不大，但是疏漏的可能还是有的，一个功能牵连的信息和逻辑越多就越会有考虑不周的地方，没有定义清楚细节，让技术的同事开发到一半，发现有的功能应当有，但是没有描述。只好再找产品经理进行补充。
没有疏漏
有的文档内容写的零零散散，会给技术的同事造成困扰，看过很多遍不知道如何下手，产品设计可以松散，但是技术人员开发时如果不从全局出发定义问题就无法开展工作，这是需要产品经理尽量在文档里配合的。
逻辑清晰
很多产品经理只是考虑把事情说出来，但是不是友好的说出来。有很多数据、信息、流程的展现用图标更清楚，但是因为懒得做，就几行字说一下，大大增加了理解成本，有很多名词、解释都说的模棱两可，难以理解。使得技术在后续的时间需要向产品经理确认。有很多可能被误解的名词，最好在文档头部进行说明 。
可读性强
文档注意
PRD文档
当有多个规则时，会有默认的规则。这个不用单独列出，只需列在取值/交互/显示规则当中即可。
一般不用单独列出，只需列在取值/交互/显示规则当中即可，当然可以通过加粗等方式说明，以提醒读者
职业：IOT PM 本科
0 条评论
回复 删除
下一页
