产品需求文档自查表

距离上次发文似乎已经是4个月前了,距离上次发产品经理的文似乎已经是十几个月前了吧,这期间发过HTTP协议讲解、物联网平台讲解、视频流讲解、带宽讲解、自动驾驶讲解…这些几乎都伴随着我的职业生涯的方向调整而变化,于是随着环境一路暴力前行,从产品、运营、项目、方案、供应链…(可以看得出来一路的波折了)…

但是人嘛,也要时常停下来好好反思,究竟什么是产品经理,什么是本心,经过一番思索,我还是决定彻头彻尾来一次空杯,从最基本的产品需求文档开始,一来为了整理一下过去的经验,二来为了重新思考一下产品经理是什么,逐步寻找一下最初的梦想和信仰。

1.目的

本文的目的,就在上边,写太多太矫情,写太少不深刻,总之就是一个字,空杯心态,从基础开始回归。

2.PRD自查表

大家都知道,产品经理是最细的男人,什么意思呢,就是说,产品经理的工作其实某种程度而言,需要极致的细致,才能打磨出极致的产品,就像乔布斯老爷子一样。

PM千万工作中,其中有一样最能体现细致,那就是PRD。随着工作的推进,你可能已经很久习惯了一句话需求,习惯了口口相传,随着工作内容和工作经验的提升,这固然是必然,但知道如何细而不做,和已经忘了什么是细,终归还是两码事。到这里,有的小朋友要说了,一个原型有啥可细致的,那么提问,我们经常用的淘宝,点击搜索,这里发生了什么交互?我们仔细想想,淘宝搜索框:

  • 有默认推荐的商品:那推荐的规则是什么。

  • 点击后:会跳转一个新的页面,为什么要跳转新的页面。

  • 跳转之后:你的焦点还停留在搜索框,这时候默认推荐的商品消失了吗?

  • 如果这时候输入了内容会怎么样,直接点击搜索会怎么样,点击返回之后页面跳转到哪里,跳转之后推荐的商品变了吗?他是怎么变的…

这么多细节,岂能是简单一句搜索讲清楚的,那么接下来,我们就,我们就不讲淘宝搜索,我们讲讲PRD自查表,从需求审查表的角度一起来梳理一下,做一个设计,写一份PRD需要从哪些角度来评判一份文档的“细”度,同样面对一份设计,可以从自查表的角度来确认自己的设计是否为完整细致的。

我们先来从整体角度明确一下PRD的内容:

 

阶段 目的 Checklist
需求分析 判断需求真伪 是否符合当前核心业务场景,是否符合用户画像和用户故事
是否存在类似竞品,是否完成竞品分析
当前方案是否是同类场景下共性需求
量化收益 对核心用户的影响程度,尽可能量化
核心业务的贡献程度,尽可能量化
整体开发难度,结合收益分析是否值得
整体维护难度,结合收益分析是否值得
判断可行性 当前技术是否可以支持
当前业务是否可以支持
功能风险评估 存量功能变更:是否存在关联功能的改造点
功能影响:是否完整梳理当前规划内容上线后的影响点
高并发处理措施:是否已经预估业务高并发时的处理措施
验证方法:是否已经计划好功能上线后的验证方法
外部风险评估 否引发诸如骚扰、欺诈等安全隐患
是否存在负面舆情
是否存在法律法规风险
优先级 用户覆盖度
使用频率
核心场景影响
对核心用户的影响
对核心场景的影响
实际收益的高低
现难度的高低
信息架构设计 信息架构设计 否结合了用户画像、用户习惯、业务场景等因素
架构层次是否清晰,是否足够扁平,是否容易理解
所有信息均需要进行重要性评级
整个结构是否高内聚、低耦合
架构可拓展性是否足够强,对信息模块进行调整时是否容易实施
流程设计 产品流程设计 主干流程是否最简化,是否覆盖了足够多的场景
是否有特殊流程(例如逆向流程、分支流程等)
是否有异常流程
操作节点、交互点 是否归纳了所有的操作节点、数据交互点
操作点是否足够精简易理解
是否考虑了操作节点的容错性
交互点是否依赖其他系统
特殊、异常流程是否需要增加切换流程的引导
相关流程的用户体验路径是否一致
美观规范 图形形状、字号是否统一
程图均以开始框开始,以结束框结束,无虎头蛇尾
流程图遵从从左到右,从上到下排列
流程线无交叉
流程结束后是否进行了场景验证,是否符合用户预期
需求文档设计 业务流程 完整流程是否形成闭环
逆向功能 功能流程是否可逆,如果可逆,是否考虑对应的机制
常机制 各个步骤可能出现预期外的情况
歧异文案 文档的语法、功能文案、名词等是否容易理解,是否存在争议
兼容 不同干系人是否都能接受,各个系统之间是否兼容,新老业务或功能是否兼容
备用 是否有备用方案,备用选项
穷尽 业务场景和可能的原因是否已经穷举完毕
脱敏 是否存在敏感信息,是否需要脱敏
精确 文案描述要精确,不得出现可能、也许、大概之类的词语
精练 需求文档要精练,非必要内容不用体现在文档内,避免给读者带来困扰
版本发布自查 / 确认完需求后,是否已经告知相关干系人,是否已通知何时可以交付版本
是否已经落实应用商店图、欢迎页、新功能引导页等
确认埋点是否已经全部清除
确认新功能的数据统计功能是否明确
以上为PRD的整体角度,那对于一份描写产品设计的PRD而言,我们需要对每一个设计细节进行核对和检查,下边我们就从具体设计角度来看看PRD的检查表。
类型 子类型 内容
账号状态及用户权限自查 基本状态 不同账号状态说明:登录状态、非登录状态不同情况是否说明完
不同用户等级和权限说明是否完整,例如非会员、会员、不同等级会员
不同账号状态切换是否有特殊提示
多账号切换时,本地缓存是否需要清空
用户登录是否考虑数据同步
特殊和异常状态 是否允许多端登录同一账号,如果允许,如何应对操作同一数据时产生的冲突
是否考虑多账号切换问题
是否支持第三方账号登录
网络状况 网络状况 WIFI网络、移动网络
集团局域网、公共网络
连接超时,多久算为超时
是否给用户引导网络检查或重试的按钮
网络变化时候是否提醒,例如wifi变5g时
服务器问题 服务器问题 服务器问题返回数据失败时,是否给予用户提示或重试按钮
件权限 件权限 位提示是否打开定位
相机提示是否打开相机
闪光灯是否提示调用闪光灯
蓝牙提示是否打卡蓝牙
设备数据是否需要调用,例如步数、心率等。
设备 竖屏 是否支持横竖屏操作,是否需要锁定屏幕
分辨率 分辨率不同是否需要适配,如何适配
系统性 操作过程是否卡顿
系统版本 系统版本不同是否支持
存储 有SD卡或无SD卡、存储空间已满、存储位置等
硬件按键 硬件不同造成物理按键不同衍生的操作
特殊场景 无图模式 络加载慢的情况下是否需要无图显示效果
夜间模式 是否需要考虑夜间模式下的展示效果
编辑模式 是否需要无图模式、是否需要无模式模式
意外中断 编辑模式下出现意外情况是否需要保存信息
屏幕亮度 是否需要特殊情况下调高或调低屏幕亮度
全局 修改页面时,考虑在系统中其余地方是否有相同的业务,是否需要统一修改
控件 全局控件央视是否具有一致性
交互 全局控件交互行为是否具有一致性
操作反馈 是否周全考虑了所有操作成功的反馈
否周全考虑了所有操作失败的反馈
触发提示类型 控件触发的提示类型是否恰当
按钮 按钮是些死还是服务端配置
是否有默认的按钮文案
按钮文字超过按钮大小如何处理
按钮样式是否有特殊要求,例如带icon和不带icon的情况
考虑按钮点击之后的效果
点击按钮后出现的情况是否与页面其他元素有冲突,例如弹窗等。
内容型文案 / 内容是静态或静态
内容是否完整、顶部标题、按钮、输入提示、悬浮提示等
内容还在方式描述是否完整,如本地缓存或网络加载情况等
内容违禁如何处理
内容是否考虑换行,超度过长怎么处理
内容是否需要考虑单词换行(有时候一个单词会出现不换行的情况)
内容长度如何限制
描述型文 / 必填或非必填
若为非必填,界面样式如何
定义文案的行数或字数
文案的截断策略是否考虑,超行字数或行数如何展示或处理
出现同一场景时,提示文案是否保持一致
文案由服务端控制还是客户端控制
是否有默认文案
是否易理解、是否有错别字、是否有歧义
型文字 / 输入文字是否有默认值,是否有输入提示
输入框内容为空时如何显示
输入框获得焦点时,默认文字消失还是保留
输入框获得焦点时,默认弹出键盘的样式
输入焦点丢失和存在时是否有展示内容的差异
输入文字是否存在极限长度或最低长度
输入文字是否可存在特殊字符。若用户输入如何处理
输入文字是否存在对敏感词、违禁词的禁用或过滤
输入文字后是否需要一键清空操作
输入文字后是否显示辅助结果,如果需要,提供辅助词的搜索规则
输入文字后遇到流程打断的情况是否保留输入记录
是否说明了键盘唤醒后需要页面的滚动来避免输入框的遮挡。(移动端常见)
输入型图片 上传前限制 是否强制要求上传图片的必须参数,例如尺寸、格式、大小
是否设置了不符合尺寸的提示,图片过大或过小,格式错误等
上传后反馈 是否提供上传完成图片的预览
是否提供了再次编辑操作,引导是否明显
上传失败的情况是否给予用户提示,引导再次上传
上传完成后遇到流程打断的情况是否保留已上传的记录(断网、退出、关闭浏览器等)
页面跳转 / 页面跳转流程是否完整流畅,流程中间是否有页面缺失
页面跳转是否有提示和引导说明
页面跳转加载的loading展示是否友好
页面跳转动作是否有跳转特效
页面跳转的方式是什么,滑动等
页面加载不出来时展示什么内容
页面点击过程中是否包含权限限制,如果有如何提示
页面跳转尽量要减少跳转次数,缩短用户操作流程,尽可能在一个页面内完成
一个页面内是否有功能冗余的内容
页面跳转时是否需要进行辅助性说明
列表 排序 列表排序方式,时间正序或倒序或其他
元素定义 列表中的元素是否都定义清楚
数据来源 列表中设计的数据来源定义
空状态 列表数据为空时的展现形式
后台配置 部分元素为后台配置,则配置前后的情况定义
加载方式 列表数据是否粉也展示还是一次性加载,单页加载数量是否有限制,下拉加载或其他
源与加载 数据的来源,来源于具体后台的哪个地方
展示数据是否使用的是服务器数据,或使用的是本地缓存数据
展示数据是否是初次加载读取的静态数据,或实时,定时展示的动态数据
数据未加载出来前展示了什么
据格式 是否规划数据为空时的展示效果
数据的极值情况如何处理
数据度是否有限制等
数据排 若为多个数据,如何排序
数据选取 是否选取全部数据或部分数据,数据根据什么搜索规则筛选出来
其他 对过期的缓存数据是否需要告知用户刷新
前置场景的不同是否对当前展示数据产生影响,不同场景是否需要展示不同数据
动端从后台唤醒应用时,是否需要刷新当前页面数据
数据展示条件 数据在什么条件下进行展示
数据是否分页展示
数据去重 数据去重策略
数据请求 什么时候开始请求数据
数据更新机制 什么情况下触发更新数据
数据更新频次?是定时更新还是实时更新?
数据过滤 是否有部分数据需要过滤掉不展示?是否对特殊内容进行过滤、标记
数据删除 数据被删除后,展示的状态如何
数据缓存 期的缓存数据如何处理,定时清理还是继续保存
弹窗 发条件 么时候触发弹窗
关闭条 什么时候弹窗消失
元素定义 弹窗内的元素是否清楚
次数 是否每次满足条件都出发弹窗还是只触发一次
优先级 多个弹窗时弹窗触发的优先级
轮播图 图片资 片数据为后台配置或客户端写死
图片排序 图片排序如何
点击是否有跳转,跳转页面为内部链接或外部链接
频次 轮播图轮播频次
展示方式 轮播图切换时的展示形式
异常 轮播图为空时如何展示
等等
写在最后,我们巴拉巴拉讲了这么多,可能大家心里会想,这里面什么轮播图我也用不上啊,嗯,对,我是做摄像头的,哈哈哈哈哈哈,这份表格当然不是万能的,这份表格更多的是提供一个思路,那就是——自顶向下,模块分解,逐步细化,渐进明细
处于不同行业的同学、所属业务线不同的同学所需要的PRD自查表当然是不同的,但我们依然可以用这种思路来整理属于自己的自查表,这样,即便是长期奔波在一线,忙碌于战场,等到回过头来仔细看看,依然会发现,这其实也是一道靓丽的风景线。

原创文章,作者:王得宇AIPM,如若转载,请注明出处:https://www.pmtemple.com/silence/13654/

(2)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
王得宇AIPM的头像王得宇AIPM高级产品经理
上一篇 2022年2月12日 上午9:41
下一篇 2022年4月12日 上午9:41

相关推荐

发表回复

登录后才能评论
微信公众号
微信公众号
edgesensor_high 小程序
小程序
分享本页
返回顶部