编辑导语：本篇文章聚焦在校验规则及提示信息，帮助新手B端体验设计师快速了解提示信息的触发规则及注意事项，搭配复杂案例助力融会贯通。欢迎感兴趣的小伙伴们一起阅读分享。
业务性强，内容复杂度高是ToB产品的典型特征。当用户需要在产品流程中录入大量数据信息时，业务本身的复杂性会大大增加录入成本。
作为体验设计师，通过系统引导性提示和校验性提示信息帮助用户快速完成工作是我们的职责所在。下面我们一起来看看复杂的校验性提示信息如何去做：
一、提示信息存在的必要性
提示信息是系统与用户之间信息反馈的载体，告知用户当前操作的可行性，减少操作损失，引导用户进行。
提示信息是反馈组件的一部分，属于反馈组件，但不包含所有的反馈组件。因为只有在录入内容出现报错、阻断时才需要提示信息。
1.B端产品的校验规则为什么复杂？
C端产品的提示信息除了提示以外还起到安抚用户的作用，适当进行情感化的设计帮助留住用户。
而B端提示信息只有在必要时才会展示，能不要提示尽量不要提示，不要给用户额外的“负担”，提升工作效率和使用效率才是我们的目标。所以提示信息的设计需要谨慎，谨慎的事情必然伴随一定的复杂性。
2.常见的校验规则
提示信息分为系统性提示和校验性提示，我们这次只针对校验性提示进行讲解。
提示信息跟随校验结果出现，本质上也是一种信息反馈。
3.基本原则
信息校验一般分为前端校验和后端校验。举个例子，前端校验就像我们登录邮箱，输入了密码，主观判断输入正确，但是提交后发现后输入错误。如果这里系统强制要求是12位数密码，你只输入了11位，那么这里提示：“请输入12位数的登录密码”就属于前端校验，而提交后提示的：“账号或密码错误”是属于后端校验。
前端校验常见的有：字段校验、必填项校验、完成度校验、产品业务数据校验等等。比如电话号码少填写一位数、必填内容未完成、一共三个步骤只填写了两步。
当产品业务数据校验放在前端去做时，多半是因为校验内容过多，想给后端校验跑数据时减轻压力，将一些简单的业务功能性校验放在前端去做。但是这里要注意，要跟前端工程师沟通好，并不是所有内容都适合放在前端进行校验的。
后端校验涉及到用户信息确认、业务数据确认等需要跑通数据库的校验内容。
常见的比如保险理赔中我们报案提交理赔的时间，不能早于事故发生的日期，这方面的数据存储于后端数据库，所以需要后端调取数据进行核实才能出校验结果。
4.提示信息的出现顺序
校验步骤的基本规则是先前端校验，再后端校验。基础内容完成后，再进行复杂信息的校验。
校验出现以下3种情况，才会对应展示提示信息：
（1）Error错误类
具有强打断性，如果错误内容未做修改，是不能继续提交进行下一阶段的，所以Error类是最先进行报错并提示的。
（2）提示无需确认
不会被强制打断，但是会作为普通提示告知用户。比如我们在校验用户身份信息时，会根据用户提供的证件类型来判断校验的内容，若用户未填写，需要提示用户必须先录入证件信息才能编辑其他内容。
（3）提示需要确认
具有打断性，这时的提示信息一定要给出用户明确提示，以及提交保存或确认后影响的内容。因为强打断，所以需谨慎。但是也不用畏手畏脚，该提示的必须提示，掌握好这个分寸。
前端校验与后端校验提示信息出现的顺序基本一致：Error错误类–提示需确认提示无需确认，只是前端无法调用复杂数据只能做简单的字段校验，而后端校验涉及到的是数据库保存的内容信息。
二、校验提示的三类情况及表现形式
校验后的提示信息一般伴随用户录入信息页面时出现（交互三原则之一：操作后有反馈），录入过程又分为录入中校验和阶段提交校验；提示信息也分为需要确认和无需确认两种情况。下面是综合两者进行的三种形式分类：
1.录入过程中，提示无需确认
当信息录入中，有些小错误给用户简单的提示即可。比如“需要录入身份证信息，才能查看您的用户数据”，这时候给一个全局提示，不需要用弹窗、气泡卡片这种打断性强的内容。
（1）提示无需确认使用的反馈组件
①警告提示
基本定义和使用规则：展示需要