高手PRD自查:分支流程+元素备要+异常场景

5 评论 4270 浏览 105 收藏 18 分钟

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

问:把大象放进冰箱需要几步?把长颈鹿放进冰箱需要几步?

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

把大象放进冰箱,第一步:打开冰箱门;第二步:把大象装进去;第三步:关好冰箱门。

高手PRD自查:分支流程+元素备要+异常场景

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

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

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

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

高手PRD自查:分支流程+元素备要+异常场景

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

高手PRD自查:分支流程+元素备要+异常场景

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

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

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

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

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

一、分支流程

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

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

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

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

高手PRD自查:分支流程+元素备要+异常场景

案例:

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

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

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

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

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

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

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

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

y=f(X)

映射是分层的。

高手PRD自查:分支流程+元素备要+异常场景

功能,是将业务进行功能层面的映射;

产品,是对若干业务段在产品层面的映射;

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

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

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

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

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

二、元素备要

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

1. 设计前

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

高手PRD自查:分支流程+元素备要+异常场景

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

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

2. 设计中

1)框架阶段

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

高手PRD自查:分支流程+元素备要+异常场景

2)流程阶段

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

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

高手PRD自查:分支流程+元素备要+异常场景

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

3)内容显示

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

高手PRD自查:分支流程+元素备要+异常场景

4)反馈通知

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

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

高手PRD自查:分支流程+元素备要+异常场景

5)文本控件

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

高手PRD自查:分支流程+元素备要+异常场景

文本内容:

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

控件:

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

表格:

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

3. 设计后

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

高手PRD自查:分支流程+元素备要+异常场景

从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协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 非常实用,感谢楼主分享😋

    来自广东 回复
  2. 写的很棒,不愧是我关注的pm😋

    来自浙江 回复
  3. 很简单实用,值得收藏好好学习!不过很多细节方面还要在打磨

    来自安徽 回复
    1. 哪些细节方面需要再打磨呢?

      来自广东 回复
    2. 哈哈哈我意思如果我操作的话

      来自湖北 回复