一、为何需要建立体系化的报错模块
无论哪种IT系统,无论面向哪类人群,系统中最常见的功能就是“报错”,可能不少小伙伴会说,报错so easy!
哪需要专门讨论。可在深入设计产品之后,经历过从0到1去设计一款产品的时候。你一定会发现。报错远远没有这么简单。报错体系涉及到多方面问题。
比如报错内容标准化问题、报错样式体验最佳问题、报错方案自助解决率问题、报错转换器问题等等。
报错需要体系化的产品设计。特别是一些TO B的产品。因为业务复杂、行业专业、对接频繁、投入有效。更需要一套优秀的报错设计模块。
二、背景分析:哪些不良的报错设计
首先,我们需要做一个报错模块的背景分析,围绕报错这种业务形态,我们可以分析下有哪些经常出现的不良点。从背景上去推演我们需要一款什么样的报错产品。
1. 报错内容不良问题:报错指向位置不明、报错内容泰国专业、报错内容和原因存在1对多情况
很多TO B产品因为业务非常复杂、关联外部系统接口较多、行业比较专业。故而在报错层面经常会出现报错内容太专业的情况。比如银行系统、财务系统、供应链系统等;
然后报错内容也存在指向不明的情况、比如不知道哪个位置、不知道哪个原因。
还有的不良情况就是报错内容和报错原因存在1对多情况,比如报错内容为“预算不足、无法实现扣减”,而实际的报错原因可能存在多种情况,有预算部门选错了、有日期选错了、有确实没有预算、有冲销未关联问题造成。而系统粗暴的说了一个报错内容,发生原因让用户去猜测。这也无形之中增加了企业的运营成本。
2. 报错样式不良问题:报错位置不统一、强弱控图标不统一、报错颜色不规范
人类是感官动物,而且经过千百年的感官训练。人类已对一些固有的颜色、固有的图标有很强的辨识力和归属定位。比如红色代表警告和禁止、绿色代表通过和赞同。叉叉图标代表不允许、感叹号图标代表提醒。系统也要沿用固有的设计模式,不要去挑战常规认知。
不过有些系统并没有这么做,经常会出现图标不规范、颜色不规范的问题。同时也会存在报错位置不统一问题。比如报错在页面顶部、报错在页面居中、报错在输入框下面、报错在右下角等等。让人琢磨不透。
3. 报错无闭环方案问题:只是报错不提供方案、只有方案无跳转路径、只有方案没有制度说明
这种不良问题是最为常见的,只有报错问题,没有解决方案。
原因不外乎如下3种:
4. 报错无扩展性设计问题:报错采用硬编码形式
这种是产品设计问题,整个系统缺失整体架构。所以报错均采用硬编码形式,全部写在代码上。结果一上线后,发现报错看不懂、不好用。又需要花费时间去代码上修改。而且针对多语言环境没有综合考虑,增加一种新的语言环境后,要所有的代码均要去修改报错。这造成整个团队的开发效率低下、系统灵活性不足、运营成本偏高。
5. 报错无法分析问题:无数据分析意识、无数据分析埋点
这种不良是很多IT团队最为忽略的。很多IT团队在企业内不受到待见、其实有一部分原因就是IT团队缺失产品运营思维。在整个产品价值链之中,干得最具有技术性的活、而职责却自我定位为执行者。软件好不好用我不管、软件可不可用我不屑。当然就不会去关注报错的可分析性。
报错是最能体现软件可用性的内容了,报错是实际运营中的数字化反映,哪里模块报错最为频繁、哪个时间点报错最多。可以第一时间定位出产品优化方向。
三、调研:哪些报错场景
经过背景分析后,下来就需要对整个系统的报错场景做一次整理,归纳下报错的类型。从而对接下来的报错做体系化的设计。
1. 按照是否影响正常运作
- 强控报错形式:出现了该异常后,则系统会无法正常运作、该类报错必须在事故发生的那一刻得到解决。若忽略或由后期流程进行补充,则会存在事故风险和规则风险。
- 弱控警告形式:出现了该异常后,则系统依然正常运作、用户可以选择忽略;或者这是一种偏提醒类问题,用户只需要知悉即可。
2. 按错误的触发原因
四、设计:报错体系的产品设计方法论(双轮驱动模型)
笔者也针对报错体系总结了一套设计方法论,总结名称为“双轮驱动报错设计模型”,下图为该模型的结构图。
整个模型由两个轮组合而成,外轮为运营轮、内轮为设计轮。
在设计轮层面,要求报错产品要满足四个要素,报错的样式和内容是标准的、报错的解决是闭环的、报错的内容和方案是可配置的、报错的可用性是可分析的。
在有了这四个设计要素后,则所有的报错信息都要用运营三步闭环方法法进行推进。
五、运营:报错的数据化运营
报错在产品运营中也是非常重要的数据指标,笔者在做产品经理的时候,经常会去分析报错内容。个人总结有如下价值:
1. 价值1:寻找产品新的优化点
对报错做模块分类、时间分类、组织分类、人群分类。可以从报错上找出很多产品优化点。
2. 价值2:增强方案的说服力
在做需求评审、做方案研讨时,并不是谁的嗓门大,谁就更有话语权。若产品能在沟通中,甩出几个报错数据分析,是很具备说服力的。
3. 价值3:驱动业务资源投入
产品2/8原则在任何产品中都是适用的,20%的工作在软件开发中,80%的工作上线后运营。而通过分析报错,可以快速找到业务配合不良的地方,从而驱动业务配合产品推广、驱动业务调整工作机制。就比如抢单模式若不做薪酬改造,就很难推行。
六、总结复盘
报错虽然是整个系统中非常小的一个产品模块,也是产品人员最为忽略的一个产品模块。可细究下来、每一个产品对自己的产品不应该要对待自己的亲生孩子一样么,不仅负责他的生存、还得关注他的成长。
因隐私性要求,无法展开报错的技术架构图和产品原型给大家看。不过基本的报错产品设计理念在此已阐述清楚了。
希望每个产品可以拿着“双轮驱动报错设计模型”去审视一下自己产品的报错体系。相信会有更多的感悟。
给作者点赞,鼓励TA抓紧创作!
来源:https://www.woshipm.com/pd/5530203.html
本站部分图文来源于网络,如有侵权请联系删除。