编辑导语：经常会有这样的情况，当你自信满满地把PRD给开发，自以为十分完美了，然而事与愿违，不一会儿就发现有满满的漏洞等着补。要走出这个困境，应该注意分支流程穷尽+元素备要+异常情况穷尽，一起来看看吧。

问：把大象放进冰箱需要几步？把长颈鹿放进冰箱需要几步？

答：把大象放进冰箱共需要3步，把长颈鹿放进冰箱共需要4步。

把大象放进冰箱，第一步：打开冰箱门；第二步：把大象装进去；第三步：关好冰箱门。

把长颈鹿放进冰箱，第一步：打开冰箱门；第二步：把大象取出来；第三步：把长颈鹿装进去；第四步：关好冰箱门。

把这个顺序交给人去干，一般没问题。然而，把这个步骤直接描述给程序，一定出问题。

因为问题并没有想象的那么简单：

• 大象不肯进去怎么办？
• 冰箱太小装不下怎么办？
• 好不容易塞进去，冰箱门关不上怎么办……

于是交付给程序的实际流程图需要如下：

这就是在产品设计中常常会遇到的问题。

自信满满把PRD给到开发同学的时候，刚出去玩一会回头就发现满满的漏洞等着补。

只有手忙脚乱地，开始各种填坑……

这本质是马克思所说的事物矛盾的普遍性导致的。解决办法就是辩证看待，对立统一。

落地一点说，主要得兜住三个方面：分支流程穷尽+元素备要+异常情况穷尽。

一、分支流程

当然我们做设计的时候，主要精力肯定是应该集中在主要任务和流程上，分支流程虽说是小概率事件，但是也要有所考虑，不然方案就会不完整。

解决这个问题，根本上是场景的穷尽。

需要注意：现实业务的场景枚举，与设计方案的枚举没有绝对对应性。也就是穷举场景可能是四个，但是实际上只需要三个方案就能覆盖。

但是场景枚举之间和分支方案之间存在MECE的属性。

案例：

OMS系统与亚马逊店铺对接的前提是：亚马逊店铺可用、对OMS系统已授权、OMS系统开启对接。

成功对接后，来自亚马逊的某些操作，会导致对接异常。此时通过接口返回错误提示，可以展示在OMS系统的店铺上，提醒商户处理。

那么这里有多少分支场景呢？

场景一：店铺被亚马逊封了，接口返回店铺异常信息。需用户在亚马逊处理。

场景二：店铺被用户在亚马逊关闭了。接口返回店铺异常信息。 需用户在平台处理。

场景三：店铺被用户在亚马逊自行注销了。接口返回店铺异常信息。需用户在平台处理。

场景四：OMS系统授权失败或者亚马逊变更了授权信息。接口返回店铺异常信息。需在OMS系统以正确的信息重新授权。
这个是第一性的，此后才能判断功能是否覆盖到上述场景。

针对场景到功能设计，本质是一种映射：

y=f（X）

映射是分层的。

功能，是将业务进行功能层面的映射；

产品，是对若干业务段在产品层面的映射；

数据层面，设计一个数据表，是对实体属性的描述，E-R图 (Entity Relationship Diagram，实体-联系图)就是实体到数据层面映射的示意图；

而字段层面，字段与属性之间也建立映射关系；

数智层面，数字孪生、VR、AR都是对事物的图像化映射和展示；

云计算层面，云服务是对实体物理技术设备生产力的虚拟化映射。

一些细致末梢的流程可能会采用放弃，或者粗鲁的兜底方案。但这不代表放弃。而是每个流程在方案层面都有所交代。

二、元素备要

如何一网打尽才是重要的。大多数是把每个流程都是按前、中、后进行要素的齐备。

1. 设计前

主要检查点：用户类型、帐号体系。

未登录：登录和未登录按钮权限差别，需要登录后才可操作的功能是否备注。

用户权限：需要读取权限吗？如何描述读取内容让用户读？不同权限管理。

2. 设计中

1）框架阶段

主要检查点：层级关系、信息区分、扩展性。

2）流程阶段

主要检查点：角色，入口，目的，操作，离开、中断。

「我是谁？从哪里来？要到哪里去？怎么去？还有谁？」。

要看流程有没有短路，如果过程中有中断，中断后要怎么提示，如果有不同的权限和角色，还得检查相互之间有没有相通和关联的地方，共同的关键节点。以及逆向操作。不同角色不同场景的任务流程一定要单独梳理。

3）内容显示

主要检查点：数据显示、缓存、内容、状态（特别是为空、初始）、显示（各种极限情况）。「为空、初始、极限情况」。

4）反馈通知

主要检查点：通知，提醒，界面反馈，用户反馈入口。

「操作的任何阶段（前、中、后被中断）都要防止用户发呆」。

5）文本控件

主要检查点：表意清晰、使用一致。「结合流程检查要符合操作的前后情景，符合用户的常规认知和习惯」。

文本内容：

• 文本长度：是否有限制？
• 文案内容：是否完整、通俗易懂、有趣
• 超过负载时如何显示？
• 核心词汇是否统一（如各种用户角色名称）
• 重要、复杂的操作内容是否有清晰的解释说明？
• 浏览到内容底部的情感化表达

控件：

• 按钮类型：主按钮、次按钮、幽灵按钮、虚线按钮是否按需区分使用（一般一个界面或视窗中只有一个主按钮）
• 按钮状态：默认、经过、点击、置灰、选中、加载中（提交按钮）；其中不同状态下按钮的置灰，是否有说明为什么不可用？以及按钮激活条件是什么？
• 链接：点击后颜色是否有变化
• 选择组件：单选、多选、tab选，是否有默认选中项
• 输入框：输入及时校验，有错误时定位；有特殊输入条件限制的输入框是否有明确说明

表格：

• 基础表格：内容项过多时，考虑将次要身份鉴别类信息隐藏，鼠标浮动到对应字段后浮窗显示
• 表格排序：默认排序和切换排序，核心字段的默认宽度
• 表格操作：考虑在当前表格内完成（页内编辑）；批量操作时对于互斥的选项处理
• 对齐：一般文字左对齐，数字右对齐
• 折叠、展开：主要内容在列内显示，更多内容点击展开显示
• 分页：表格内容翻页展示还是无限加载？若分页每页显示多少条内容？

3. 设计后

检查点：设备、中断情况、网络情况、特殊状态、刷新方式、异常操作。「多页面通用内容放在一页一起搞定」。

从A状态到B状态：

• 触发源：操作按钮在当前界面中是否明确？
• 触发区域：操作按钮是否易操作易触达？
• 未释放状态：考虑内容过多或展示过快时支持长按停留内容；是否可以取消，例如发送语音消息，此时是否允许用户取消发送？

三、异常情况

1. 异常流程

退出、撤销、重置、返回、不通过、过期失效

• 返回：从哪里来是否可以回到那里去
• 保存：复杂任务流是否支持保存或自动保存；意外退出前保存提示
• 复杂状态之间的变化关系：子流程梳理辅助说明

2. 刷新和加载

• 刷新：自动还是手动刷新？每次刷新加载多少条内容？刷新失败如何提示？
• 无线刷新：顶部下拉、底部上拉，安卓有刷新按钮
• 加载：复杂页面是否有副列表加载？预览、保存、提交的完成时间若超过3S是否有加载的过渡状态？新加载内容是否有高亮底纹显示？

3. 网络异常

• 没有网络（无网）
• 网络超时（断网）
• 网络太慢（弱网）
• 网络环境变化：从WiFi到数据流量环境时是否需要切换视图
• 加载失败：是否自动重新加载？

4. 操作异常

• 连续多次点击给予反馈、统一设备登录多个账号验证码、统一IP；连续破坏性操作n项内容时是否需要身份验证。
• 数据相关：进入页面后服务器获取不到数据；搜索无结果状态；数据加载时间较长时预设默认图片、状态、内容框架；
• 错误提示页：404页面、即将上线、页面失效、服务下线、系统繁忙，考虑出错页面内容情感化表达以减弱用户的受挫感。

四、PRD自查

1. 按功能插件自查

1）输入框

需限定输入的范围，做输入校验。

示例：最多输入10个数值，输入不合规则的内容，则在输入框下方红色字体提示，比如：“请不要输人汉字！”。

2）下拉框

下拉的同时是否支持输入搜索，是否支持多选。

3）导入文档

表头校验、自校验、与系统校验、写入逻辑（全部不予导入或部分导入)、下载结果文档；

4）已有功能的逻辑规则变更

则要考虑旧数据兼容或初始化。

5）基础数据删除

则要考虑基础数据被调用的地方，删除和编辑怎么处理。

比如：商品分类中维护的“商品类型”被删除，那么再编辑和删除该分类下的历史数据的时候就可能报错，所以基础数据维护时候要校验调用情况。

6）设置规则

考虑规则去重、规则优先级。一般情况下，没有优先级的话，规则的去重和命中次序校验起来比较麻烦。（在<后端产品经理宝典>一书中有专门介绍）。

7）列表的数据的排序

一般按照修改时间的倒叙排列，也可以用数据库id代替序号。用数据库id的好处是，方便用户和技术协作追溯数据。

8）异常机制

每时每刻都要有逆向思维，告诉开发人员什么算异常？异常了怎么标示出来。

比如：表1字段A，匹配表2字段B，将匹配成功的数据写入表3。就要考虑表1中字段A为空的情况该怎么办。

9）页面长期不登录

则给自动退出。主要考虑到后端系统的保密性。

10）凡是带操作的

一般都要设置页面权限。最简单的方式是所有系统的权限都分三个等级：不能查看、只能查看、可以编辑。

11）功能修订

比如规则变更，需要考虑旧数据是否要按照新规则进行初始化。

2. 按需求类型自查

1）功能需求

需要穷尽功能覆盖的使用场景，穷尽本功能相关联的各个系统模块，穷尽本功能的用户角色、权限。

2）性能需求

• 数据量较大时的系统压力、反应速度；
• 批量上传、下载要考虑数量上限，考虑是否异步处理；
• 考虑浏览器兼容性；
• 考虑调用接口超时的备用策略等。

3）安全需求

敏感词屏蔽（同步过滤和异步召回）、防刷单机制、数据补推机制、风险预警等。

3. 关键词提醒自查

笔者不完全罗列了几个关键词，可以作为自查的维度。

1）完整

流程是否存在断头路。

2）逆向

功能流程是否可逆，如果逆向操作，是否考虑对应的机制：比如退款、退货操作。

3）异常

即异常机制。各个步骤都可能出现预期外的情况。

4）歧义

需求文档的语法、功能文案、名词是否易懂，是否存在歧义。

5）兼容

是否存在兼容问题：不同业务人员对功能都能接受吗？各个系统之间兼容吗？新旧功能的兼容吗（比如历史数据要不要初始化）？

6）备用

是否有备用方案，次级选项。比如当正常流程无法传输的时候，是否可以用导入的机制救急。业务高峰的系统，是否有降级处理逻辑。

7）穷尽

业务场景和可能原因是否穷举完毕。

默认：是否给予了默认值。

比如设置规则功能业务未设置怎么办？

8）脱敏

是否存在敏感信息，是否有脱敏机制。

4. 其他

自查的方式还有很多，比如也可以按照“增、查、改、删、显、传、算”自查等。

#专栏作家#

唧唧歪歪PM，公众号：唧唧歪歪PM（ID：jjyypm），人人都是产品经理专栏作家，2019年年度作者。《后端产品经理宝典》作者，药学硕士转行互联网产品多年；熟悉跨境电商业务，医药领域；擅长大型后台体系，社交APP。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载

题图来自pixabay，基于CC0协议。