收藏◎大厂PRD三步法:场景/要素/自查!——直接套用!

共 9396字,需浏览 19分钟

 ·

2024-05-10 07:00


问:

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


答:

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


你知道为什么吗?

关注公众号 “产品参赵” 右上角置为星标,开启进阶之旅
关注后  回复 1 即抽取50份电子书
回复 2 加我进群 
本文4.3K字,文末是一批免费资料


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


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

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

因为问题并没有想象的那么简单:
  • 大象不肯进去怎么办?
  • 冰箱太小装不下怎么办?
  • 好不容易塞进去,冰箱门关不上怎么办……


于是交付给程序的实际流程图需要如下:
这就是在产品设计中常常会遇到的问题。
自信满满把PRD给到开发同学的时候,刚出去玩一会回头就发现满满的漏洞等着补。
只有手忙脚乱地,开始各种填坑……

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

落地一点说,主要得兜住三个方面:分支流程穷尽+元素备要+异常情况穷尽
下面正文,4.3千字,文末资料
本文目录:
1 分支流程
2 元素备要
3 异常情况
4 PRD自查
5 获取自查表(资料)

一、分支流程


当然我们做设计的时候,主要精力肯定是应该集中在主要任务和流程上,分支流程虽说是小概率事件,但是也要有所考虑,不然方案就会不完整。
解决这个问题,根本上是场景的穷尽。
需要注意:现实业务的场景枚举,与设计方案的枚举没有绝对对应性。也就是穷举场景可能是四个,但是实际上只需要三个方案就能覆盖。

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


案例:

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

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

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

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

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

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

场景四:OMS系统授权失败或者亚马逊变更了授权信息。接口返回店铺异常信息。 需在OMS系统以正确的信息重新授权。

这个是第一性的,此后才能判断功能是否覆盖到上述场景。

针对场景到功能设计,本质是一种映射:y=f(X)

映射是分层的。


功能,是将业务进行功能层面的映射;产品,是对若干业务段在产品层面的映射;数据层面,设计一个数据表,是对实体属性的描述,E-R图 (Entity Relationship Diagram,实体-联系图)就是实体到数据层面映射的示意图;而字段层面,字段与属性之间也建立映射关系;数智层面,数字孪生、VR、AR都是对事物的图像化映射和展示;云计算层面,云服务是对实体物理技术设备生产力的虚拟化映射。

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


二、元素备要


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

1. 设计前
主要检查点:用户类型、帐号体系。



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

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

2. 设计中

2.1 框架阶段
主要检查点:层级关系、信息区分、扩展性。


2.2 流程阶段
主要检查点:角色,入口,目的,操作,离开、中断。
「我是谁?从哪里来?要到哪里去?怎么去?还有谁?」。


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

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


2.3 反馈通知
主要检查点:通知,提醒,界面反馈,用户反馈入口。
「操作的任何阶段(前、中、后被中断)都要防止用户发呆」。


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


a、文本内容
 
文本长度:是否有限制?
文案内容:是否完整、通俗易懂、有趣
超过负载时如何显示?
核心词汇是否统一(如各种用户角色名称)
重要、复杂的操作内容是否有清晰的解释说明?
浏览到内容底部的情感化表达
 
b、控件
 
按钮类型:主按钮、次按钮、幽灵按钮、虚线按钮是否按需区分使用(一般一个界面或视窗中只有一个主按钮)
按钮状态:默认、经过、点击、置灰、选中、加载中(提交按钮);其中不同状态下按钮的置灰,是否有说明为什么不可用?以及按钮激活条件是什么?
链接:点击后颜色是否有变化
选择组件:单选、多选、tab选,是否有默认选中项
输入框:输入及时校验,有错误时定位;有特殊输入条件限制的输入框是否有明确说明
c、表格
基础表格:内容项过多时,考虑将次要身份鉴别类信息隐藏,鼠标浮动到对应字段后浮窗显示
表格排序:默认排序和切换排序,核心字段的默认宽度
表格操作:考虑在当前表格内完成(页内编辑);批量操作时对于互斥的选项处理
对齐:一般文字左对齐,数字右对齐
折叠、展开 :主要内容在列内显示,更多内容点击展开显示
分页:表格内容翻页展示还是无限加载?若分页每页显示多少条内容?
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、其他

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

-完-


资料时刻
1、《交互自查表》一份excel共5个sheet

获取方法:

Step1:分享本文/点赞/在看

Step2:对本公众号【产品参赵】发送消息“自查”,等待返回百度云盘的下载链接。


2、如果觉得不过瘾,看看下面这些大厂文档:

获取途径:

加入星球,无限更新


——推荐阅读——

结合32个案例,提升产品经理决策能力!

SaaS 定制化与标准化思路+案例

真实的“产品总监”简历啥样:这有两份!【保真】


浏览 120
1点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
1点赞
评论
收藏
分享

手机扫一扫分享

分享
举报