产品经理需求自查表
内嵌表格
| 类型 | 列2 | Checklist |
|---|---|---|
| ①需求分析 | 判断需求真伪 | 是否符合当前核心业务场景、是否符合用户画像和用户故事? |
| 是否存在类似竞品，是否完成竞品分析? | ||
| 当前方案是否是同类场景下的共性诉求? | ||
| 量化收益 | 对核心用户的影响程度，尽可能量化。 | |
| 对核心业务的贡献程度，尽可能量化。 | ||
| 判断可行性 | 当前技术是否可以支持 | |
| 当前业务是否可以支持 | ||
| 风险评估-功能风险 | 是否存在关联功能的改造点? | |
| 是否完整梳理当前规划内容下线后的影响点? | ||
| 是否已预估业务高峰数据爆发量级，及其处理措施? | ||
| 是否已计划好功能上线后的验证方法? | ||
| 风险评估-外部风险 | 是否引发诸如骚扰、欺诈等安全隐患? | |
| 是否存在负面舆情风险? | ||
| 是否存在法律及合规风险? | ||
| 排定优先级 | 用户覆盖度 | |
| 使用频率 | ||
| 对核心场景的影响 | ||
| 对核心用户的影响 | ||
| 实际收益的高低 | ||
| 对KP的影响 | ||
| 实现难度的高低 | ||
| ②架构设计 | 信息架构设计 | 设计时是否结合了用户画像、用户习惯、业务场景等因素。 |
| 架构层次是否清晰，是否足够扁平，是否容易能使用户理解。 | ||
| 所有信息均需要进行重要级评定，以决定在界面和功能中的重要程度 | ||
| 信息分类是否合理、 一定要"高内聚，低耦合"。 | ||
| 架构拓展性是否足够大，后续对信息模块进行增删改查时，是否容易施行 | ||
| ③产品流程 | 产品流程设计 | 主干流程是否最简化，是否覆盖了足够多的场景 |
| 是否有特殊流程(分支流程、逆向流程) | ||
| 是否有异常流程 |
内嵌表格
| 类型 | 列2 | Checklist |
|---|---|---|
| ③产品流程 | 操作节点、交互点 | 是否归纳出所有的操作节点、数据交互点。 |
| 操作节点是否足够精简易理解。 | ||
| 是否考虑了操作节点的容错性(二次确认、撤销操作) | ||
| 数据交互点是否依赖其它系统。 | ||
| 特殊、异常流程是否需要增加切换流程的引导，避免流程断头。 | ||
| 相关流程的用户体验路径是否一致 | ||
| 美观规范 | 各图形形状/字号统一。重点内容可特殊标识，关键节点增加注释说明 | |
| 流程均以开始框开始，以结束框结束，避免断头风险。 | ||
| 流程图从左到右、从上到下排列。 | ||
| 流程线尽量不要交叉 | ||
| 流程完成后是否进行了场景验证，是否符合用户预期。 | ||
| ④细节交互 | 页面流 | 页面跳转的描述说明是否完整，是否需要页面流转图辅助说明 |
| 页面内容是否完整，是否符合信息架构设计，是否存在缺失 | ||
| 页面是否存在空值状态 | ||
| 页面加载状态展示的loading图是否友好，是否可打断加载状态 | ||
| 页面加载状态是否可操作部分原生控件(移动端) | ||
| 页面的逆向操作是否有完整的路径，返回是否会造成死循环 | ||
| 页面的跳转是否需要转场动效 | ||
| 是否添加全局特效的交互操作， iOS右滑返回 | ||
| 移动端单页面中的功能是否有冗余，单页面主功能仅限 | ||
| 后端web页尽量在一个页面中展示更多相关信息，单页面可完成或多次相关操作 | ||
| 文案 | 是否易理解，是否有歧义，是否有错别字 | |
| 句式、用词是否准确一致 | ||
| 文案是否与产品调性一致 | ||
| 数据展示 | 展示数据是否使用的是服务器数据，或使用的是本地缓存数据 | |
| 展示数据是否是初次加载读取的静态数据，或实时、定时展示的：动态数据 | ||
| 是否规划数据为空时的展示效果，是否增加用户引导 | ||
| 是否规划数据字数超长展示效果，是否有超长限制 | ||
| 对过期的缓存数据是否需要告知用户刷新(活动过期) | ||
| 是否规划数据极限值的展示效果 | ||
| 是否规划了数值的特定展示格式 | ||
| 是否存在敏感数据，敏感数据如何展示 | ||
| 是否对特殊内容进行过滤、标记(敏感、违禁的词语) | ||
| 前置场景的不同是否对当前展示数据产生影响，不同场景是否需要展示不同数据 | ||
| 移动端从后台唤醒应用时，是否需要刷新当前页面数据 数据按什么规则排序 | ||
| 数据表单 |
内嵌表格
| 类型 | 列2 | Checklist |
|---|---|---|
| ④细节交互 | 数据表单 | 数据是根据什么搜索规则筛选出 |
| 数据展示是否分页，单页展示数据量是否有限制 | ||
| 控件 | 控件是否符合用户认知 | |
| 全局控件样式是否具有一致性 | ||
| 全局控件交互行为是否具有一致性 | ||
| 控件的不可用状态如何展示 | ||
| 是否周全地考虑了所有操作成功的反馈 | ||
| 是否周全地考虑了所有操作失败的反馈 | ||
| 操作过程中是否允许取消 | ||
| 是否设计了必要且合理的动效 | ||
| 待操作按钮在当前界面中是否明确 | ||
| 待操作按钮是否易操作 | ||
| 控件触发的提示类型是否恰当(小红点、Toast、弹窗) | ||
| 控件触发的功能过程中是否可以随时取消(下载新版本、上传文件 | ||
| 文字输入 | 输入文字前是否有默认值，是否有输入提示 | |
| 输入焦点丢失和存在时是否有展示内容的差异 | ||
| 输入文字是否存在极限长度或最低长度 | ||
| 输入文字是否可存在特殊字符，若用户输入如何处理 | ||
| 输入文字是否存在对敏感词(密码、存款金额等)、违禁词的禁用或过滤展示 | ||
| 输入文字后是否需要一键清空操作 | ||
| 输入文字后是否显示辅助结果(辅助词),辅助词的搜索规则 | ||
| 输入文字后遇到流程打断的情况是否保留输入记录(断网、关闭页面等) | ||
| 是否针对输入的内容指定键盘类型，数字键盘，英文键盘(移动!端) | ||
| 是否说明了键盘唤起后需要页面的滚动来避免输入框的遮挡(移动端 | ||
| 图片输入 | 是否强制要求上传图片的必须参数(尺寸、格式等) | |
| 是否设置了不符合尺寸的提示，图片过大或过小，格式错误等 | ||
| 是否提供上传完成图片的预览 | ||
| 是否提供了再次编辑操作，引导是否明显 | ||
| 上传失败的情况是否给予用户提示，引导再次上传 | ||
| 上传完成后遇到流程打断的情况是否保留已上传的记录(断网、关闭页面等) | ||
| 弹窗 | 什么时候触发弹窗? | |
| 什么时候弹窗消失?(关闭按钮、返回按钮、手机系统返回按钮、点击页面空白处等) | ||
| 弹窗内的元素(文案、跳转等)是否都定义清楚 | ||
| 是否每次满足条件都触发弹窗?还是只弹一次? | ||
| 若该弹窗与其他弹窗同时满足条件触发，则优先级如何? |
内嵌表格
| 类型 | 列2 | Checklist |
|---|---|---|
| ④细节交互 | 轮播图 | 图片数据为后台配置or客户端写死? |
| 图片排序如何? | ||
| 点击是否有跳转?跳转页面为内部链接or外部链接? | ||
| 轮播的频次如何? | ||
| ⑤特殊因素 | 账号角色 | 是否存在不同登录状态下展示内容或操作有不同(登录、未登录、帐号异常状态) |
| 是否存在不同用户状态下展示内容或操作有不同(非会员、不同等级的会员，特殊付费会员等) | ||
| 是否考虑多账号切换，切换时，本地缓存数据是否需要同步清空。 | ||
| 是否允许多终端同时登录一帐号，若允许，操作同一数据时是否产生冲突 | ||
| 网络状况 | WiFi网络、移动网络(4G) | |
| 集团局域网、公共网络 | ||
| 连接超时，多久为超时 | ||
| 网络显示什么内容?是否给予用户友好引导检查网络或重试按曲 | ||
| 网络变化从WiFi到4G网络环境时是否需要提示 | ||
| 服务器问题 | 服务器出问题返回数据失败时，是否给予用户友好提示或重试按钮 | |
| 硬件设备 | 横竖屏是否有横屏展示的需要，如不需要需要锁定竖屏 | |
| 分辨率高低：分辨率情况下是否会有适配问题，是否备注清楚。 | ||
| SD卡Android手机、没有SD卡存储已满、存储已满、存储位置等情况是是否考虑并备注 | ||
| 硬件不同，手机物理按键的不同衍生不同操作。 | ||
| 系统版本的不同是否同步支持， iOS、Android、Windows及其不同版本 | ||
| 硬件权限 | 定位提示是否打开定位 | |
| 相机提示是否打开相机 | ||
| 闪光灯提示是否调用闪光灯 | ||
| 蓝牙提示是否打开蓝牙 | ||
| 设备数据是否需要调用，步数、心率等，主要在iOS设备中。 | ||
| 阅读模式 | 夜间\日间模式是否考虑光线较暗的场景。 | |
| 编辑模式下出现意外情况是否提示保存或自动保存已填信息。 | ||
| 无痕模式：不记录用户所有操作信息(实际是否记录根据数据需求来看 | ||
| 无图模式：节约用户流量，加快页面加载速度。 | ||
| ⑥辅助模块 | 数据埋点 | 数据埋点的字段内容及展示类型是否完整 |
| 数据埋点的时间范围和时间段是什么 | ||
| 上线后验证的数据是否都进行了埋点记录 | ||
| 是否需要进行数据漏斗模型分析报表生成 | ||
| 埋点数据后续如何提取出来 | ||
| 是否有自动通知机制，通知形式是什么 | ||
| 埋点不成功是否有报警机制 |
内嵌表格
| 类型 | 列2 | Checklist |
|---|---|---|
| ⑥辅助模块 | 通知机制 | 操作交互是否需要触发推送消息，推送内容是什么,推送时间节点是什么 |
| 是否确定当前通知的类型(短信、推送、微信消息) | ||
| 是否确定当前通知的失效策略 | ||
| ⑦发布自查 | 告知运营 | 确认完需求之后，要告知运营同事们有哪些新功能，何时能交付版本，这样方便运营童鞋们也好 对应的落实相关的运营工作。如果运营的部分/全部工作也是PM干的话，那么自己心里要有数 |
| 需求变更 | 确认这个项目中没有完成的需求或者中途协商修改的需求，都已经被记录下来，并且最好开始确 认没有解决的需求怎么办，修改的需求怎么办的问题； | |
| 埋点验证 | 确认该新功能的埋点列表是否给出； | |
| 每个版本都要观察上个版本的埋点数据是否正常，及时发现是否打错点，进行及时修正避免数据 浪 费 ； | ||
| 数据验证 | 确认新功能带来的相关新数据的查看地方以及方法，这里会涉及一些常用的统计平台； | |
| 告知业务 | 确认新功能带来的后台新的管理模块使用或者从某个地方切换到另一个地方的使用方法的切 换，培训过相关人员，且已经正确掌握； | |
| 应用商店 | 确认提交给应用商店的新功能文案是否有出； | |
| 确认最终提交给应用商店的应用商店图、新功能介绍更新了： | ||
| 确认各个渠道中的最新版确实为最新版本； |