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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　原因不外乎如下3种：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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