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

TO B产品设计专题：报错体系 一、为何需要建立体系化的报错模块 无论哪种IT系统，无论面向哪类人群，系统中最常见的功能就是“报错”，可能不少小伙伴会说，报错so easy！ 哪需要专门讨论。可在深入设计产品之后，经历过从0到1去设计一款产品的时候。你一定会发现。报错远远没有这么简单。报错体系涉及到多方面问题。 比如报错内容标准化问题、报错样式体验最佳问题、报错方案自助解决率问题、报错转换器问题等等。 报错需要体系化的产品设计。特别是一些TO B的产品。因为业务复杂、行业专业、对接频繁、投入有效。更需要一套优秀的报错设计模块。 二、背景分析：哪些不良的报错设计 首先，我们需要做一个报错模块的背景分析，围绕报错这种业务形态，我们可以分析下有哪些经常出现的不良点。从背景上去推演我们需要一款什么样的报错产品。 1. 报错内容不良问题：报错指向位置不明、报错内容泰国专业、报错内容和原因存在1对多情况 很多TO B产品因为业务非常复杂、关联外部系统接口较多、行业比较专业。故而在报错层面经常会出现报错内容太专业的情况。比如银行系统、财务系统、供应链系统等； 然后报错内容也存在指向不明的情况、比如不知道哪个位置、不知道哪个原因。 还有的不良情况就是报错内容和报错原因存在1对多情况，比如报错内容为“预算不足、无法实现扣减”，而实际的报错原因可能存在多种情况，有预算部门选错了、有日期选错了、有确实没有预算、有冲销未关联问题造成。而系统粗暴的说了一个报错内容，发生原因让用户去猜测。这也无形之中增加了企业的运营成本。 2. 报错样式不良问题：报错位置不统一、强弱控图标不统一、报错颜色不规范 人类是感官动物，而且经过千百年的感官训练。人类已对一些固有的颜色、固有的图标有很强的辨识力和归属定位。比如红色代表警告和禁止、绿色代表通过和赞同。叉叉图标代表不允许、感叹号图标代表提醒。系统也要沿用固有的设计模式，不要去挑战常规认知。 不过有些系统并没有这么做，经常会出现图标不规范、颜色不规范的问题。同时也会存在报错位置不统一问题。比如报错在页面顶部、报错在页面居中、报错在输入框下面、报错在右下角等等。让人琢磨不透。 3. 报错无闭环方案问题：只是报错不提供方案、只有方案无跳转路径、只有方案没有制度说明 这种不良问题是最为常见的，只有报错问题，没有解决方案。 原因不外乎如下3种： 第一种为产品经理没有经验，只是给出问题； 第二种为系统很多报错是无法在产品侧定义好，而产品和开发又没有形成协同机制； 第三种为团队不关注经营，只负责IT系统搭建，缺失问题解决率、用户应用体验度、系统运营成本的考量。 4. 报错无扩展性设计问题：报错采用硬编码形式 这种是产品设计问题，整个系统缺失整体架构。所以报错均采用硬编码形式，全部写在代码上。结果一上线后，发现报错看不懂、不好用。又需要花费时间去代码上修改。而且针对多语言环境没有综合考虑，增加一种新的语言环境后，要所有的代码均要去修改报错。这造成整个团队的开发效率低下、系统灵活性不足、运营成本偏高。 5. 报错无法分析问题：无数据分析意识、无数据分析埋点 这种不良是很多IT团队最为忽略的。很多IT团队在企业内不受到待见、其实有一部分原因就是IT团队缺失产品运营思维。在整个产品价值链之中，干得最具有技术性的活、而职责却自我定位为执行者。软件好不好用我不管、软件可不可用我不屑。当然就不会去关注报错的可分析性。 报错是最能体现软件可用性的内容了，报错是实际运营中的数字化反映，哪里模块报错最为频繁、哪个时间点报错最多。可以第一时间定位出产品优化方向。 三、调研：哪些报错场景 经过背景分析后，下来就需要对整个系统的报错场景做一次整理，归纳下报错的类型。从而对接下来的报错做体系化的设计。 1. 按照是否影响正常运作 强控报错形式：出现了该异常后，则系统会无法正常运作、该类报错必须在事故发生的那一刻得到解决。若忽略或由后期流程进行补充，则会存在事故风险和规则风险。 弱控警告形式：出现了该异常后，则系统依然正常运作、用户可以选择忽略；或者这是一种偏提醒类问题，用户只需要知悉即可。 2. 按错误的触发原因 自身的系统逻辑：这类异常是系统本身的逻辑要求，不受到外部系统的影响，在系统内通过代码修正、配置调整即可修复。 外部的系统要求：外部接口报错；这类异常不是系统本身的逻辑要求，而是由外部系统引发的，比如很多系统均要对接SAP、而在传输数据到SAP的时候，则SAP会返回报错信息。这类异常大部分是由于数据不同步、数据为空造成。 人为的报错形式：审批人的驳回原因报错，这类异常不是系统逻辑造成的，而是在业务流转过程中，由人工维护的。比如在流程审批中、审批人驳回给填单人，则填单人收到的驳回原因。这类异常若无标准，也会造成大量的运营成本。 底层框架的标准：系统底层