生活中犯错在所难免，用户在使用产品的时候，也常常会遇到一些报错的情况。如果产品没有处理好，用户碰到报错的时候是会很郁闷的。所以一款好用的产品应该能够妥善处理用户的错误操作。

在本文中我会给出一些建议，如果能够遵守的话，报错信息对于用户来说也就没那么讨厌了。

报错信息要清晰，不能模糊

报错信息一定要写的清晰易懂，让用户在阅读的时候能够清楚的明白其中的意思。如果信息很模糊，用户根本弄不明白怎么回事，自然也就没办法进行修复的操作，用户体验会很糟糕。

Windows的报错信息没有给出任何线索和解决方案

Autodesk的报错信息非常模糊，没有任何有用的信息

报错信息要简短有用

报错信息只需包含必需信息即可，大多数时候用户是不愿意阅读长篇大论的。简明扼要的把问题描述清楚，给用户解决方案。避免说的太多，不要过度传达问题。

简明扼要的报错信息让人容易理解

用户根本无法理解这种信息

报错信息也不能简短到一点细节都没有了

不要使用专业术语

大多数用户对于问题的技术细节并不感兴趣，如果报错信息含有专业术语，用户看了之后会很困惑。尽量使用简洁的、通俗易懂的语言描述问题。如果不得不使用技术性的复杂信息，请将其置于故障排除部分，并指导用户以便他能够快速解决问题。

技术细节的描述使得报错信息愈发复杂

包含专业术语的报错信息

谦和一点，不要责怪用户

好的报错信息语气要委婉，温和地把问题传达给用户就可以了，不要责怪用户。用户可能会重复进行错误的操作，我们设计的责任就是以一种温和地方式告诉用户他错了。

右图不友好的语言让用户很不舒服

这两则报错信息语气不友好

避免使用否定的词汇

在用户界面中，有一些否定的词汇我们要避免使用。出现报错一般都是由于用户做了错误的操作，所以系统就很有可能对用户很不礼貌。John Ekman给出了一个使

用“是”和“否”的非常好的例子：

几年前，我在斯德哥尔摩的机场办理登机手续时，我问柜台的女服务员是否有可能升级到商务舱。 她的回应：“我很抱歉，不可能的，你得额外付费。”

检查回程航班，我再次尝试了同样的事情，但这一次的答案是：“当然，先生！ 你想怎么支付呢？”

因此，虽然情况一模一样，我得到了两个完全不同的答案：一个是“是”，另一个是“否”。

这条消息不清晰，还很负面

给用户指导

一个好的报错信息有三部分组成：定位问题；如果有帮助，请提供详细信息；如果可能，请提供解决方案。不论何时出现了错误，用户都是希望快速解决的。报错信息最好给予用户一定的指导，让用户指导怎么才能修复错误。当然，消息还可以将用户引导至其他地方或人员，从那里他可以得到关于该问题的详细帮助。

应该展示完整的信息

这条报错信息中既没有错误原因也没有解决方案

细致、相关

报错信息必须包含相关信息-准确指出问题所在，用户应该如何一步步解决问题。如果含有模糊的信息，用户会疑惑不解，也就无从解决问题了。

包含不必要、不相关的信息

这条信息给了三个可能的原因，会把用户弄糊涂

这条消息对用户的指导非常精确

避免使用大写字母

大写的文本很难阅读，会给用户带来冲击。报错消息是用户被告知某些关键场景的地方，因此使用大写字母可能会让他感到灰心。

大写字母看上去对用户有冲击

提供适当的行动

行为是报错信息的重要组成部分，适当的行为指示能让用户知道下一步该做什么。行动是解决问题的可能途径，报错消息可以包含用户的一个或多个操作。

如果用户必须执行特定操作才能删除错误，请使用与按钮标题相同的操作名称。

这条报错信息中给出了清晰而准确的行为指南

使用渐进式披露法

有些详细信息与报错信息相关，但是用户可能并不想看得这么细，请将其放入“显示/隐藏”部分， 对于需要了解技术细节的高级用户可能会有用。

用户第一眼可能并不想了解细节

位置要恰当

将错误消息放在距离它所属区域较近的地方，这样用户在读完消息后就不用到处找它到底在说什么了。例如，当用户在填表格的时候，把提示的错误信息对应的放在所属控件的附近是比较好的。否则，用户还得先找到控件，然后再来解决问题。

报错信息应该设置的明显一点，即使用户将视图滚动到顶部或底部，仍会在当前视图中显示出现在屏幕上的消息。

将错误信息放在控件的旁边

总结

Thomas Fuchs说“最好的报错信息就是从不出现的那种”，完全避免错误当然好，但我们生活在人类的世界中，是人就会犯错。

不过呢，只要遵守上述法则，我们就能将错误信息带来的不愉快降低到最小程度，让用户仍有一个不错的体验。

翻译：熊小熊（微信公众号：集创堂）