编辑导语：细节设计对于提升用户体验方面十分重要，本篇文章作者针对校验的细节设计问题进行分析。通过列举具体案例进行分析，讲述了校验的设计类型和考察的维度等，一起来学习一下吧，希望对你有帮助。

为了让产品或者服务能够正常使用，产品经理总是会设计各种规范，控制和引导用户按照设计者的意图去进行操作。

譬如在各种输入框做校验，如果不符合规范则会有相应的提示。

这不是一个复杂的事情，但却是一个很影响用户体验的部分，细节才真正体现产品的实力。

所以校验的设计是很重要的，我们今天就聊一聊这个话题，重点是聊一聊校验设计的边界问题。

必要的铺垫还是要有，所以讲一讲校验设计的基础。

为什么要做校验？刚才讲过了，是为了让用户可以顺畅的使用产品和服务。

譬如最简单最常见的用户注册，大家现在都习惯用手机号注册，那么在手机号输入框的部分，用户输入之后一般会先对这个输入的内容进行格式校验，这样能最大程度保证系统发出验证码的时候用户是能收到短信的。

所以这种校验本身就是为了让用户更好的继续使用产品和服务。

校验有哪些类型？一般就三种：一种是规范校验，一种是一致性校验和安全性校验。

规范性校验就是前面讲的手机号校验这种，根据固定的要求进行校验，产品经理会给出这些规范，一般也就是字符类型、字符长度这样的规范。

一致性校验指的是实名校验、银行卡校验这种的，用户在输入信息之后会调用第三方的权威数据源进行校验，看输入的信息是否是真实的。

当然做一致性校验之前一般都会做规范校验。

安全性校验的话一般涉及到账号、敏感信息和交易（资金流动）的时候会出现，譬如使用微信支付或者支付宝支付的时候需要输入交易密码来验证是本人发起的交易。

但校验是有边界的，做不做校验、做到什么程度是有一些判断标准的，我们重点聊一聊这部分。

校验设计主要是考察三个维度，一个是必要性，一个是可行性，一个是成本可控。

必要性，这是最重要的考察维度，原则上规范性校验和安全性校验应验尽验，能校验的都要做校验，至于一致性校验则要看情况。

规范性校验虽然在开发和测试过程中会繁琐一点，但是对用户友好。

当然，这就要求产品经理在所有需要校验的地方都标出校验规则，不难但是繁琐。

• 譬如同样是输入框，姓名输入框和手机号输入框校验规则是不一样的。
• 譬如类似的输入框校验规则最好保持一致，如需要输入公司名称和公司地址，其实没必要做特殊要求，那么校验规则就可以保持一致，这样的话校验规则的类型就会尽可能的少，便于记忆和管理。

如果是后台系统的，最好也都做一下校验，避免在app端出现不必要的错误。

安全性校验那肯定是必须的，涉及到账户、敏感信息和资金安全的都是必须校验的。

一致性校验以实际使用场景和设计意图为准，譬如前面讲到的绑定银行卡这个操作，那么是必须要做一致性校验的，因为后续会涉及到交易或者资金流动。

但也有不做校验的，譬如微信支付的亲属卡。

亲属卡的操作流程是这样的：我的->服务->钱包->亲属卡->赠送->选择赠予对象(关系属性)->在好友中选择对象->设置支付额度->输入交易密码。

整个过程中实际上只在最后做了安全性交易，并没有做亲属关系是否真实的一致性校验。

为什么不做？没有必要做，实际上对于微信来说根本不关心用户选择的对象是不是真的是用户的亲属，微信设计这个功能的本意就不包含关系是否真实的考虑。

只要校验密码是对的，就表示这种关系的绑定是用户本人的意愿，这就可以了。

虽然从功能本身来说是，的确用户可以绑定任何好友，但是从实际的使用场景来说用户真的会给一般的朋友开通这个亲属卡的功能吗？

不存在的，只有亲属和恋爱对象这样的亲密关系才会给予开通，这是关系属性决定的。

再好的朋友也不可能每个月给零花钱吧？所以根本没有必要校验关系的真实性。

所以关于一致性的校验是以实际场景为准的，当然还包含了设计意图的考虑。

可行性，这也是很重要的考察维度，如果想校验但是做不到或者校验难度太大，那就肯定不校验了。

我举两个例子：

还是刚才前面的微信亲属卡的这个例子，假设微信觉得有必要校验用户绑定的亲属关系是否真实，微信自己肯定没有这个数据源可以校验真实性，第三方有没有，有的，公安机关的数据库里肯定有这个数据源。

但是公安机关也肯定不会开放给微信使用的，所以微信即便是想校验也做不到，那肯定就不校验了。

类似的，在个税app里申报个人所得税的时候，如果父母（其中有一位即可）超过60周岁是可以申报赡养老人专项扣除的，申报的时候只需要填写父母一方的身份证信息即可。

这种情况下，如果要校验的话是有可能做到的，税务机关和公安机关同属国家机关，理论上是可以协调的。

当然实际有没有校验我就不知道了，我不可能为了测试去绑定别人的身份证。

再譬如信贷系统中的风控系统，会设置很多风控规则，来判断哪些用户符合要求，哪些用户不符合要求。

有些组合的风控规则过于复杂，一个点一个点设置操作过于繁琐而且可能还不能满足需求。

这种情况下可能会让风控人员直接输入表达式(逻辑代码)来实现，一般人根本看不懂这个。

这种表达式的校验就属于校验难度太大的类型。能不能校验？理论上可以的，但是难度太大，出规则的难度大实现的难度也大，那就没有必要，还不如人工校验更简单一点。

成本可控，这是必须要考虑的，公司是商业组织，必须考虑资金成本的问题。

像绑定银行卡、或者身份证实名认证、活体识别这种调用三方数据源进行校验的必然是要付费的，付费就涉及到一个成本控制的问题。

当然实际上来说对于是否采用付费方案的考虑是几乎没有的，因为前面两个维度的重要性压过了这一条，只是在根据不同的安全性或者合规性要求采用不同的验证方案而已，尽可能控制成本。

譬如使用支付宝进行支付只验证交易密码，但如果查询公积金（支付宝小程序）的话就会要求做人脸识别，就安全性的要求来说肯定是支付>查询的，毕竟支付涉及到资金的流动，而查询只涉及到信息保护的问题，但是因为不同主体对合规性的要求不同，所以做法不同。

就实际来说，校验这个部分并不起眼，因为不可见，但是对于用户体验是有很大的影响的，而校验规则是否合理、是否全面和细致就是一个比较重要的关切点，所以要多做考量。

对于做不做这个问题大家其实不会有太多争议，但是对于怎么做、做到何种程度其实大家的认识是不一样的，我觉得大家可以重点从可行性和成本控制这个部分去考虑，尽可能在系统层面多做一点，保障用户体验。

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

题图来自 Unsplash，基于 CC0 协议