收藏◎大厂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 定制化与标准化思路+案例


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


















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

手机扫一扫分享

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

手机扫一扫分享

分享
举报