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

boyka 2023-08-06 05:03:28

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

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

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

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

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

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

产品经理，产品经理网站

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

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

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

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

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

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

原因不外乎如下3种：

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

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

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

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

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