今天，和大家聊一聊产品中的错误预防机制。

一个良好的错误预防机制可以极大的减少用户出错的几率，将「非可控的错误流」尽可能的转变为「可控的异常」。

实践

错误预防机制主要有两方面的内容组成，即错误的发现及错误的预防。

接下来，我们就了解一些关于错误预防机制的具体实践。

自动完成

人们最熟悉的错误预防机制，应该就是「自动完成」了，被广泛的应用在搜索、电商等众多的产品中。原因也是显而易见的 —— 人们在输入关键字进行搜索时，由于对自己的目标不够熟悉等原因，常常会出现描述不够完整的情况；而不完整的描述往往就导致产品展示给用户的是错误的结果。而「自动完成」的应用，就是为了及时发现和预防这种情况的发生。

百度

淘宝

用户只需要输入开头的几个字，产品就可以提供出相关的建议。也许有些时候建议不是那么的靠谱，但大多数情况下已经够用了。

相似提示

相似关键字的提示，常与自动完成搭配使用。

搜搜

易迅

当用户因为输入法等种种原因，在产品中输入了错误的关键字时，与其展示给用户一个残酷的错误结果，不如友好的告诉用户「你是不是输错了？」，并大胆的猜测一下用户想找的正确结果。

自动替换

我们都知道，擅自去更改用户输入、提交的内容，一般情况下都是「非常忌讳」的一种行为。但在某些特定的情况下，这种行为反而是对用户友好的一种体现。

由于某些原因，很多产品都加入了一些「内部审查」机制，当用户输入的内容包含某些敏感词语时，就禁止该内容的发布。

一亩田

提交失败会增加用户的挫败感，辛辛苦苦填写的内容，只是因为使用了个别词语就没了；而且只是提示用户有敏感词，而不告诉他们哪些是敏感词，更会让用户无所适从，不知道该如何修改。

「X姐」不合适，那就自动替换成「女士」；不能说「廉X」，就换成「便宜」。虽然内容上有所缺失，但至少可以让用户成功的进行提交。

用户「鼓足了勇气」迈出了第一步，我们应该让他的这一步更好的迈出去，而不是上来就告诉他「你迈腿的方式不对」。

而只有那些真正「恶意」的内容，才应该拒绝将它发布出去。

隐藏与禁用

刚才说了三种针对「关键字」的错误预防机制，接下来我们继续聊聊其他的形式。

在设计用户界面时，我们可以将一些界面元素加以隐藏或禁用，以减少用户错误的发生。

Google Play 未安装时

未安装时，会显示“安装”按钮。

Google Play 已安装时

已安装时，则会显示 打开及卸载 按钮。

简化流程

这种错误预防机制和刚才讲的「隐藏与禁用」方法看上去很接近，但出发点还是有些差异的。

「隐藏与禁用」的方法，更多的是从用户界面上「阻止」用户去进行可能会出错的操作；而「简化流程」的方法，则是从更上一个层面下手，杜绝用户出错的可能。

啪啪

例如现在也挺常见的扫描二维码下载。最早的做法是给出 iPhone 及 Android 两个版本各自的二维码下载地址，由用户选择适合自己的进行扫描、下载。

而简化后的流程，不再需要用户选择去扫描 Android 的还是 iPhone 的，而是扫描同一个二维码，之后由服务器去判断用户是用的 Android 还是 iPhone 手机，自动给出相应的下载地址。

不再让用户参与选择，自然也就杜绝了选择出错的可能。

步骤提示

有些时候，由于种种原因，我们可能无法简化用户操作的流程。这时，我们也可以采取「步骤提示」的方法，给予用户相应的指导，以防止用户操作错误。

iTools 进入DFU模式

向用户讲解每个步骤应该进行怎样的操作，并对每步操作的时间加以提示。虽然不够完美，但也已经很好了。

总结

其实错误预防机制的方法还有很多，在这里就不再一一进行列举了。总体来说，错误预防机制最重视的是发现错误和预防错误的过程。弄明白用户为什么会出错、会在哪里出错以及会出现怎么样的错误，也就知道我们可以采用什么样的方法加以预防了。

用户体验绝不仅仅只是产品功能的堆砌，往往就体现在那些一不留神就会被忽略，但在使用中却会让用户觉得无比贴心的地方。

并不是说我们的产品只要加上「自动完成」等错误预防机制，就立马变得「高端大气上档次」了。在产品的初始阶段，我们甚至会去「刻意」的忽略这些地方 —— 只需要能够验证我们的假设就可以了；但是当我们一旦验证了我们的假设，要沿着这条路继续走下去时，对用户体验的追求就是在所难免的了。

文章来自：CocoaChina

原文转自简书，作者：Ziya