1.6 容错性

用户在使用产品的过程中，难免会犯错。一个好的产品可以降低用户犯错的概率，以及提升解决错误的效率。通俗一点说就是帮助用户避开操作过程中的“坑”，即使用户掉进“坑”里，也能让他们很快地爬出来。这就是产品设计中的容错性原则。

为了方便读者理解，我将容错性原则分为三个阶段：引导、报错和解决。首先通过简洁、易懂的引导来帮助用户规避那些错误；当用户不得已犯错之后，会给予提示，告知用户犯错的原因及解决方案，如图1-47所示。

1.6.1 引导

我发现很多交互设计师在设计产品的时候很容易犯一个毛病，觉得用户什么都懂，因此忽视了引导的重要性。

一提到引导，读者可能会想到引导页、弹框、浮层等。这些都是常见的引导方式，确切地说是主要针对新用户，让他们很快地了解该产品的核心功能及主要的操作方式，帮助他们更快地上手，如图1-48和图1-49所示。

但是引导功能的实现方式不仅限于此，输入框中的输入提示也是常见的引导样式。输入框是用户完成信息录入的主要途径之一，有录入才有报错，有报错才需要引导。

以日期录入为例，如果我们不给用户提供日期选择组件，那么必须要在输入框里提供日期格式。因为日期（如2018年6月10日）可以有多种录入格式，如果不以输入提示的方式予以明确，那么用户就不知道该怎么输入，如图1-50所示。

类似的案例还有在用户注册新账户时，当用户设置登录密码后点击“注册”按钮时却通知用户密码强度不够。因为用户的密码里没有大写字母，但是这个密码的设置规范并没有在用户录入之前告知他，所以他才会犯错。

以上说的都属于狭义上的引导，用户还停留在被动地接受引导的阶段。其实引导归根结底是为了避免用户在操作过程中犯错，而用户的操作过程又可以被看成不断做决策的过程，要想做出正确的决策，必须要消减信息的不对称性。所以，我们可以把引导功能理解为就是消减信息的不对称性，让用户做出正确的决策。

例如如图1-51所示，用户想要买水果，与其他商品不同的是，水果的保质期很短，所以，用户会很看重水果的配送时间。如果用户觉得这家店铺的菠萝价格公道，将其添加到了购物车中，等到临近付款的时候才发现原来是后天才送达，有些用户可能会取消订单，之前填写的重量、种类等操作都白费了。这其实也可以算作是“错误操作”，因为用户选择了错误的商品。

为了避免出现这种情况，配送时间这个信息必须在用户做“加入购物车”这个决策之前就展示给用户。总而言之，会影响用户做决策的因素必须要及时反馈给用户。

如果你确定对用户足够了解，在用户录入信息的时候就可以设置合理的默认值。因为对用户来说，填写信息永远都不是一件有趣的事情，设置合理的默认值可以节省用户的操作时间，更能避免用户犯错。

例如，用户在9月下旬打开某个APP要预订机票，那么出行日期可以直接默认为10月1日，返程日期可以默认为10月7日，因为这符合大部分用户的预期。当然，如果日期跟用户的实际行程不符，用户也可以手动更改，这不会增加任何额外的操作步骤。

当用户在文本框里输入时，可以设置让系统猜测可能的答案，显示可选列表，如图1-52所示。自动完成信息填写可以为用户节省时间、精力和记忆成本，避免犯错。

此外，还要特别注意文案的使用，因为用户对于信息的获取主要依靠的就是文案。呆板、机械的文案有的时候会让用户迷惑。如图1-53所示，在实名认证的阶段，需要用户补全身份证信息，而这里的“起始时间”和“结束时间”很难让用户明白是什么意思，更不知道应该怎么填。其实这里的“起始时间”和“结束时间”指的是身份证的签发时间和有效期。

1.6.2 报错

报错就意味着引导失效了，用户掉进“坑”里了。对于报错，下面主要从两个方面进行分析：报错方式及报错时机。

主要的报错方式就是使用弹框，可能我们会觉得只要了解了弹框的使用方法，就知道怎么设计报错流程了。这个说法不严谨，因为忽视了报错时机这个因素。

以图1-54为例，用户在注册账户的时候要录入手机号，我在这一步故意少输了一位数字，直接点击“同意协议并注册”按钮后，竟然可以进入下一个页面。当我滑动滑块验证的时候才出现一个Toast告诉我格式错误，如果要修改，则还要回到上一个页面，这种反馈效率无疑是非常滞后的。

如果用户输入的手机号不是以1开头或者位数不对，那么对于这种低级错误，输入框应该立即校验出来，并且提示用户，如图1-55所示。至于如何提示用户，方式是多种多样的。如何选择合适的报错方式，需要从以下三个方面进行分析：重要性、字数和指向性。

很多设计师倾向于使用Toast来作为报错样式，因为Toast非常轻量，不会打断用户正常的操作流程。但是，如果报错信息非常重要，那么千万不要使用Toast。例如，在用户转账的时候，发生了系统故障，为了避免重复转账，在这种场景下的报错信息必须要保证用户可以看到。而我们发现，在某些安卓手机中，用户在系统设置时可能会在无意之中把Toast给禁用了。其实用户的本意只是想禁用通知或者浮窗，没想到把Toast也给关了。所以，对于一些非常重要、必须保证用户可以看到的报错信息，最好不要使用Toast。

因为Toast显示一段时间就会消失，所以不利于承载过多的文字。不同的产品对字数有着不同的限制，我倾向于设置15个字，也就是说Toast最多只可以显示15个字。当然会有人说，Toast的持续时间是可以控制的，可以让开发人员设置一下，让持续时间跟字数成正比。但是这里有一个问题，用户对于Toast已经形成了心理暗示，认为Toast会很快消失，所以很难静下心来阅读其中显示的大段文字。就算能安心读完，那么持续显示近10s的Toast就完全失去了其轻量化的优点，我们为什么还要使用Toast？

不是每一个场景的报错信息都是需要通过弹框来展示的。例如，用户在用手势解锁时，当解锁失败后，如果使用弹框的样式来报错，则用户每次必须点击“确定”按钮关闭弹框才可以重新解锁，增加了操作步骤。如果直接使用文字提示，就会方便很多，如图1-56所示。

以上举例的报错针对的都是单一对象，如果在一个表单中，用户需要输入多个项目，那么在这种情况下的报错要具有指向性，要让用户可以快速明白到底是哪一个项目在报错。

下面来看一个案例。如图1-57所示，如果用户的邮箱格式填写错误，那么此APP会通过Toast提示用户，并且邮箱地址选项也会被标红。如果我们只使用Toast，那么用户还要寻找报错的项目，这里的标红使报错具有了指向性。在项目特别多的表单中，具有指向性的报错可以省去用户的查找时间。

此外，有的报错场景是通过一个页面来展示的，其实我不是很喜欢这种样式，因为专门做一个页面来传递报错信息过于浪费了。当然这只是我个人的观点，用一个页面来展示一个失败操作流程的终点也没什么不可以。

当用户碰到报错提示时，可能心情会非常郁闷和烦躁，所以，在报错的同时还要注意安抚用户。图1-58所示的这种报错样式我不是很认可，因为置身于报错场景中的用户本身就很烦躁了，使用大面积的红色会刺激用户的情绪。就像电脑在出现故障时，会出现蓝屏而不是红屏，因为蓝色可以帮助用户平复焦虑的心情。

1.6.3 解决

前面介绍了报错的方式和时机，现在到了解决这一步，解决方法是撰写合适的报错文案。我梳理一些过产品中的报错文案，发现很多报错文案都只描述了报错场景，告诉用户“对不起，你掉进‘坑’里了”，没有解释为什么掉进“坑”里，怎么爬出来，以及下次如何避免再次掉进“坑”里。

如图1-59所示，在此APP中绑定银行卡要输入预留的手机号，当用户输错的时候告诉用户手机号不符，连续输错好几次之后结果通知用户尝试次数过多。既然错误次数是有限制的，那么就应该告诉用户还剩多少次机会。

此外，“尝试次数过多”是一个很笼统的提示，到底尝试几次才是“尝试次数过多”，是不是24小时之后用户又可以重新输入了？用户是不是可以咨询客服来解除这个冻结的状态，这些都没有提示。

所以报错文案不能只描述场景，还必须包含报错原因及解决方案，报错文案要简洁、干练、概括性强。

例如，新浪金融APP中的实名认证流程可以分为三个步骤：一是验证身份证信息；二是绑定银行卡；三是验证手机号。其中在绑定银行卡的页面中，如果用户输入了错误的银行卡号，就会出现对话框告诉用户“实名信息不正确”，这种模棱两可的提示让我误以为是身份证号输错了，然后返回到上一页，检查后发现身份证号是对的。这时我才想起来可能是我的银行卡号输错了，但是返回来之后之前的信息又要重新录入，如图1-60所示。从这个例子中我们可以发现，在报错文案中如果没有明确报错原因，则容易造成用户误操作。

当然，如果可以给出具体的解决方案，报错原因其实并没有那么重要。例如，如果因为公安网维护导致从今晚22点到次日8点无法提供服务，则可以直接简化成“系统维护中，今晚22点至次日8点暂停服务”。其实用户不在乎具体是什么原因，他们在乎的是什么时候可以恢复服务。

如果解决方案需要发生跳转动作，那么为了方便用户操作，要尽量提供跳转超链接。例如，当用户输错支付密码超过次数限制，导致支付密码被锁，需要重置支付密码时，我们不能给用户一句提示就完了，因为用户可能不知道到哪里重置支付密码。为了提升产品的易用性，可以给用户提供超链接让用户直接跳转到重置支付密码页中，如图1-61所示。

此外，如果是系统可以帮助用户完成的操作，则尽量由系统来完成。举个例子，我们经常会看到“××失败，请重试”的报错场景，其实每次遇到这个场景时我都会很头疼。因为我不知道“重试”这个动作是在当前页面就可以完成，还是需要返回上一个页面后再进来“重试”。

又例如，在拍照识别银行卡号的时候，出现了一个Toast提示用户“识别失败，请重试”。这种模棱两可的报错文案让用户无法获知具体的错误原因是因为系统故障，还是因为用户刚才拍照的时候手抖了。如果是因为系统故障，那么用户可能需要退出页面重新打开手机摄像头再识别一次；如果是因为手抖，那么用户只需要保持稳定的姿势重新拍摄就行了，不需要返回上一级页面。在这里如果是因为系统故障，那么应该直接退回到上一级页面，在上一级页面中提示用户重试，而不是在当前页面提示用户重试。

另外，有些报错属于系统内部的报错，用户无法自己解决，需要客服的介入，我们应该给用户提供在线客服或者帮助中心的超链接。很多产品都选择在页面的右上角提供帮助中心的入口，入口最好统一，入口不一致会增加用户的操作成本，如图1-62所示。

其实说实话，报错文案很难写。之前我们上线了一个卡券，但是有些用户被系统判断为风险等级较高导致无法领取。针对这个报错文案，我们改了好几版，但是每次都会有用户投诉。他们询问为什么自己无法领取，直接告诉他们是高危用户也不太合适，因为用户是执行了某些操作才被判定为风险等级较高的。而我们在用户操作前并没有告知，直接告诉他们是高危用户可能会引起新的投诉。最合理的方法就是提前判断用户状态，如果被判定为高危用户，则直接不展示这个卡券，也就不会出现报错场景。