高手PRD自查:分支流程+元素备要+异常场景
共 4280字,需浏览 9分钟
·
2022-03-17 21:03
问:
把大象放进冰箱需要几步?把长颈鹿放进冰箱需要几步?
答:
把大象放进冰箱共需要3步,把长颈鹿放进冰箱共需要4步。
把大象放进冰箱,第一步:打开冰箱门;第二步:把大象装进去;第三步:关好冰箱门。
把长颈鹿放进冰箱,第一步:打开冰箱门;第二步:把大象取出来;第三步:把长颈鹿装进去;第四步:关好冰箱门。
把这个顺序交给人去干,一般没问题。然而,把这个步骤直接描述给程序,一定出问题。
因为问题并没有想象的那么简单:
大象不肯进去怎么办? 冰箱太小装不下怎么办? 好不容易塞进去,冰箱门关不上怎么办……
于是交付给程序的实际流程图需要如下:
这就是在产品设计中常常会遇到的问题。
自信满满把PRD给到开发同学的时候,刚出去玩一会回头就发现满满的漏洞等着补。
只有手忙脚乱地,开始各种填坑……
这本质是马克思所说的事物矛盾的普遍性导致的。解决办法就是辩证看待,对立统一。
落地一点说,主要得兜住三个方面:分支流程穷尽+元素备要+异常情况穷尽。
下面正文,4.3千字,文末资料
本文目录:
1 分支流程
2 元素备要
3 异常情况
4 PRD自查
5 获取自查表(资料)
一、分支流程
当然我们做设计的时候,主要精力肯定是应该集中在主要任务和流程上,分支流程虽说是小概率事件,但是也要有所考虑,不然方案就会不完整。
解决这个问题,根本上是场景的穷尽。
需要注意:现实业务的场景枚举,与设计方案的枚举没有绝对对应性。也就是穷举场景可能是四个,但是实际上只需要三个方案就能覆盖。
但是场景枚举之间和分支方案之间存在MECE的属性。
案例:
OMS系统与亚马逊店铺对接的前提是:亚马逊店铺可用、对OMS系统已授权、OMS系统开启对接。
成功对接后,来自亚马逊的某些操作,会导致对接异常。此时通过接口返回错误提示,可以展示在OMS系统的店铺上,提醒商户处理。
那么这里有多少分支场景呢?
这个是第一性的,此后才能判断功能是否覆盖到上述场景。
针对场景到功能设计,本质是一种映射:y=f(X)
二、元素备要
如何一网打尽才是重要的。大多数是把每个流程都是按前、中、后进行要素的齐备。
1. 设计前
主要检查点:用户类型、帐号体系。
未登录:登录和未登录按钮权限差别,需要登录后才可操作的功能是否备注。
用户权限:需要读取权限吗?如何描述读取内容让用户读?不同权限管理。
2. 设计中
2.1 框架阶段
主要检查点:层级关系、信息区分、扩展性。
2.2 流程阶段
主要检查点:角色,入口,目的,操作,离开、中断。
「我是谁?从哪里来?要到哪里去?怎么去?还有谁?」。
要看流程有没有短路,如果过程中有中断,中断后要怎么提示,如果有不同的权限和角色,还得检查相互之间有没有相通和关联的地方,共同的关键节点。以及逆向操作。不同角色不同场景的任务流程一定要单独梳理。
2.2 内容显示
主要检查点:数据显示、缓存、内容、状态(特别是为空、初始)、显示(各种极限情况)。「为空、初始、极限情况」。
2.3 反馈通知
主要检查点:通知,提醒,界面反馈,用户反馈入口。
「操作的任何阶段(前、中、后被中断)都要防止用户发呆」。
2.4 文本控件
主要检查点:表意清晰、使用一致。「结合流程检查要符合操作的前后情景,符合用户的常规认知和习惯」。
三、异常情况
1、异常流程
退出、撤销、重置、返回、不通过、过期失效
返回:从哪里来是否可以回到那里去 保存:复杂任务流是否支持保存或自动保存;意外退出前保存提示 复杂状态之间的变化关系:子流程梳理辅助说明
2、刷新和加载
刷新:自动还是手动刷新?每次刷新加载多少条内容?刷新失败如何提示? 无线刷新:顶部下拉、底部上拉,安卓有刷新按钮 加载:复杂页面是否有副列表加载?预览、保存、提交的完成时间若超过3S是否有加载的过渡状态?新加载内容是否有高亮底纹显示?
没有网络(无网)
网络超时(断网)
网络太慢(弱网)
网络环境变化:从WiFi到数据流量环境时是否需要切换视图
加载失败:是否自动重新加载?
4、操作异常
连续多次点击给予反馈、统一设备登录多个账号验证码、统一IP;连续破坏性操作n项内容时是否需要身份验证。 数据相关:进入页面后服务器获取不到数据;搜索无结果状态;数据加载时间较长时预设默认图片、状态、内容框架; 错误提示页:404页面、即将上线、页面失效、服务下线、系统繁忙,考虑出错页面内容情感化表达以减弱用户的受挫感。
需限定输入的范围,做输入校验。
示例:最多输入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)完整
流程是否存在断头路。
比如当正常流程无法传输的时候,是否可以用导入的机制救急。业务高峰的系统,是否有降级处理逻辑。
默认:是否给予了默认值。
比如设置规则功能业务未设置怎么办?
4、其他
自查的方式还有很多,比如也可以按照“增、查、改、删、显、传、算”自查等。
-完-
——推荐阅读——