TO B产品设计专题:报错体系

4 评论 2528 浏览 15 收藏 12 分钟

编辑导语:“报错”是系统中最常见的功能之一,报错体系也涉及到方方面面的问题。本文作者分享了有关报错体系的相关内容,讲述了建立体系化的报错模块的原因、报错设计、报错场景的类型以及设计报错体系的方法论和数据化运营价值等,一起来学习一下吧。

一、为何需要建立体系化的报错模块

无论哪种IT系统,无论面向哪类人群,系统中最常见的功能就是“报错”,可能不少小伙伴会说,报错so easy!

哪需要专门讨论。可在深入设计产品之后,经历过从0到1去设计一款产品的时候。你一定会发现。报错远远没有这么简单。报错体系涉及到多方面问题。

比如报错内容标准化问题、报错样式体验最佳问题、报错方案自助解决率问题、报错转换器问题等等。

报错需要体系化的产品设计。特别是一些TO B的产品。因为业务复杂、行业专业、对接频繁、投入有效。更需要一套优秀的报错设计模块。

二、背景分析:哪些不良的报错设计

首先,我们需要做一个报错模块的背景分析,围绕报错这种业务形态,我们可以分析下有哪些经常出现的不良点。从背景上去推演我们需要一款什么样的报错产品。

1. 报错内容不良问题:报错指向位置不明、报错内容泰国专业、报错内容和原因存在1对多情况

很多TO B产品因为业务非常复杂、关联外部系统接口较多、行业比较专业。故而在报错层面经常会出现报错内容太专业的情况。比如银行系统、财务系统、供应链系统等;

然后报错内容也存在指向不明的情况、比如不知道哪个位置、不知道哪个原因。

还有的不良情况就是报错内容和报错原因存在1对多情况,比如报错内容为“预算不足、无法实现扣减”,而实际的报错原因可能存在多种情况,有预算部门选错了、有日期选错了、有确实没有预算、有冲销未关联问题造成。而系统粗暴的说了一个报错内容,发生原因让用户去猜测。这也无形之中增加了企业的运营成本。

2. 报错样式不良问题:报错位置不统一、强弱控图标不统一、报错颜色不规范

人类是感官动物,而且经过千百年的感官训练。人类已对一些固有的颜色、固有的图标有很强的辨识力和归属定位。比如红色代表警告和禁止、绿色代表通过和赞同。叉叉图标代表不允许、感叹号图标代表提醒。系统也要沿用固有的设计模式,不要去挑战常规认知。

不过有些系统并没有这么做,经常会出现图标不规范、颜色不规范的问题。同时也会存在报错位置不统一问题。比如报错在页面顶部、报错在页面居中、报错在输入框下面、报错在右下角等等。让人琢磨不透。

3. 报错无闭环方案问题:只是报错不提供方案、只有方案无跳转路径、只有方案没有制度说明

这种不良问题是最为常见的,只有报错问题,没有解决方案。

原因不外乎如下3种:

  1. 第一种为产品经理没有经验,只是给出问题;
  2. 第二种为系统很多报错是无法在产品侧定义好,而产品和开发又没有形成协同机制;
  3. 第三种为团队不关注经营,只负责IT系统搭建,缺失问题解决率、用户应用体验度、系统运营成本的考量。

4. 报错无扩展性设计问题:报错采用硬编码形式

这种是产品设计问题,整个系统缺失整体架构。所以报错均采用硬编码形式,全部写在代码上。结果一上线后,发现报错看不懂、不好用。又需要花费时间去代码上修改。而且针对多语言环境没有综合考虑,增加一种新的语言环境后,要所有的代码均要去修改报错。这造成整个团队的开发效率低下、系统灵活性不足、运营成本偏高。

5. 报错无法分析问题:无数据分析意识、无数据分析埋点

这种不良是很多IT团队最为忽略的。很多IT团队在企业内不受到待见、其实有一部分原因就是IT团队缺失产品运营思维。在整个产品价值链之中,干得最具有技术性的活、而职责却自我定位为执行者。软件好不好用我不管、软件可不可用我不屑。当然就不会去关注报错的可分析性。

报错是最能体现软件可用性的内容了,报错是实际运营中的数字化反映,哪里模块报错最为频繁、哪个时间点报错最多。可以第一时间定位出产品优化方向。

三、调研:哪些报错场景

经过背景分析后,下来就需要对整个系统的报错场景做一次整理,归纳下报错的类型。从而对接下来的报错做体系化的设计。

1. 按照是否影响正常运作

  • 强控报错形式:出现了该异常后,则系统会无法正常运作、该类报错必须在事故发生的那一刻得到解决。若忽略或由后期流程进行补充,则会存在事故风险和规则风险。
  • 弱控警告形式:出现了该异常后,则系统依然正常运作、用户可以选择忽略;或者这是一种偏提醒类问题,用户只需要知悉即可。

2. 按错误的触发原因

  1. 自身的系统逻辑:这类异常是系统本身的逻辑要求,不受到外部系统的影响,在系统内通过代码修正、配置调整即可修复。
  2. 外部的系统要求:外部接口报错;这类异常不是系统本身的逻辑要求,而是由外部系统引发的,比如很多系统均要对接SAP、而在传输数据到SAP的时候,则SAP会返回报错信息。这类异常大部分是由于数据不同步、数据为空造成。
  3. 人为的报错形式:审批人的驳回原因报错,这类异常不是系统逻辑造成的,而是在业务流转过程中,由人工维护的。比如在流程审批中、审批人驳回给填单人,则填单人收到的驳回原因。这类异常若无标准,也会造成大量的运营成本。
  4. 底层框架的标准:系统底层报错(SQL层)、框架(Hibernate),这类异常是工具框架造成的,是一些工具性软件、硬件、服务器、操作系统的报错。该类报错对于大部分IT团队而言是束手无策的。当然这类问题发生的概率很低。

四、设计:报错体系的产品设计方法论(双轮驱动模型)

笔者也针对报错体系总结了一套设计方法论,总结名称为“双轮驱动报错设计模型”,下图为该模型的结构图。

整个模型由两个轮组合而成,外轮为运营轮、内轮为设计轮。

在设计轮层面,要求报错产品要满足四个要素,报错的样式和内容是标准的、报错的解决是闭环的、报错的内容和方案是可配置的、报错的可用性是可分析的。

在有了这四个设计要素后,则所有的报错信息都要用运营三步闭环方法法进行推进。

  1. 第一步先将报错进行分解;
  2. 第二步进行报错的配置;
  3. 第三步要通过实际运行进行分析,最后又回归到分析后,对报错进行更细颗粒度的分解。

五、运营:报错的数据化运营

报错在产品运营中也是非常重要的数据指标,笔者在做产品经理的时候,经常会去分析报错内容。个人总结有如下价值:

1. 价值1:寻找产品新的优化点

对报错做模块分类、时间分类、组织分类、人群分类。可以从报错上找出很多产品优化点。

2. 价值2:增强方案的说服力

在做需求评审、做方案研讨时,并不是谁的嗓门大,谁就更有话语权。若产品能在沟通中,甩出几个报错数据分析,是很具备说服力的。

3. 价值3:驱动业务资源投入

产品2/8原则在任何产品中都是适用的,20%的工作在软件开发中,80%的工作上线后运营。而通过分析报错,可以快速找到业务配合不良的地方,从而驱动业务配合产品推广、驱动业务调整工作机制。就比如抢单模式若不做薪酬改造,就很难推行。

六、总结复盘

报错虽然是整个系统中非常小的一个产品模块,也是产品人员最为忽略的一个产品模块。可细究下来、每一个产品对自己的产品不应该要对待自己的亲生孩子一样么,不仅负责他的生存、还得关注他的成长。

因隐私性要求,无法展开报错的技术架构图和产品原型给大家看。不过基本的报错产品设计理念在此已阐述清楚了。

希望每个产品可以拿着“双轮驱动报错设计模型”去审视一下自己产品的报错体系。相信会有更多的感悟。

 

本文由 @boyka 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 泰国专业(太过)是啥哈哈

    来自北京 回复
    1. 哈哈 谢谢指正!

      回复
  2. 报错虽然是整个系统中非常小的一个产品模块,也是产品人员最为忽略的一个产品模块。

    来自吉林 回复
    1. 是 很多产品运营成本高、也有这方面原因

      回复