错误消息从来都不是一件让人愉快的事情。但是，写得不好的错误消息可能会对用户造成干扰，甚至损害你的品牌形象。在 Sketch，我们决心通过一些计划、团队合作，当然还有巧妙的 UX 文案，来摆脱糟糕的错误消息！
为什么错误消息很重要
与大多数其他类型的文案相比，错误消息对用户的影响更大，因为
- 你获得了用户的全部注意力，这种情况在最好的情况下也很少发生，因此你需要充分利用这种糟糕的情况。
- 你在用户工作时打断他们，如果问题不容易解决，并且成为障碍，这将尤其令人沮丧。
- 用户期望你在错误消息中解释失败点，无论谁是错误的（软件、用户或第三方）。
从更广泛的层面来看，错误消息是网站或应用程序整体抛光程度的良好指标。仅仅一个写得不好的错误消息就足以破坏用户的体验，而且这种体验不会很快被遗忘。
通过混合信号发送错误的信息
现在，让我们来看几个糟糕的错误消息的例子，以及如何改进它们。
问题与解决方案
我们先从一个常见的内联错误开始，你可能以前见过它
第一个错误消息的作者将其表述为一个问题陈述，而且是一个抽象的问题陈述。这把责任推给了用户，而且没有特别有用。相反，可以简单地要求用户执行你要求他们执行的操作，这在第二个例子中很清楚。
当你空间不足时，直接进入解决方案，而不是用绕弯的方式解释问题。专注于引导用户，而不是羞辱他们。
保持错误消息清晰
接下来，这是一个来自旧操作系统的错误消息
第一个消息示例几乎处处都做错了。它很正式，而且含糊不清。虽然假装成一个非法黑客可能很酷，但我们真正想告诉用户什么？相反，我们可以使用第二个例子。
换句话说：你正在使用的应用程序刚刚崩溃，所以尝试关闭它并重新打开它。如果这不起作用，请联系提供商（或选择查看详细信息）。
了解你的受众
这是另一个例子，来自照片编辑软件
看一下第一个错误消息，这可能是由一个开发者为另一个开发者编写的。但是，大多数最终用户对枚举的突变不感兴趣。甚至“确定”按钮似乎也认命于发生了什么的谜团。
可悲的事实是，有时没有人真正知道出了什么问题。是一个单一的故障？还是一个无法解决的毁灭性的多集群？错误是由用户引起的？还是由于一个讨厌的错误导致的罕见的后台问题？
如果你没有答案，通常最好使用像第二个错误消息这样的通用消息。
当然，这不是一个令人满意的结局，但这是一个用户理解并可以采取行动的结局。
不友好的错误消息令人反感
最后一个例子，来自一家在线零售商
虽然第一个错误消息的边缘攻击性的语气让我们忍俊不禁（“我们警告你！这个密码根本不可接受！”），但在现实世界中遇到这个错误的用户可能并不觉得它很有趣。
我们建议使用类似第二个例子这样的方法，它采用了一种更友好的方式。
密码错误是每个人都会犯的小错误，而且通常很容易解决。把它当作这样处理。使用友好的语气，不要指责任何人，也不要过度解释他们错在哪里。
糟糕的词语是错误
所以，糟糕的错误消息无处不在，我们甚至承认，我们在 Sketch 这里也有一些需要修复的错误。但我们决心消除它们，因为糟糕的错误消息是错误，我们需要修复它们。
展示你的工艺
消除错误的第一条规则是学会识别它们。如果你是一名作者，花点时间向你的团队展示糟糕的错误是什么样子的，特别是向开发者展示。创建一些模板和示例，帮助其他人区分良好的错误和写得不好的错误。
别忘了 QA 的同事！只要进行一些培训，你友好的 QA 分析师就可以成为强大的盟友，在这些错误意外泄露到现实世界之前，就抓住它们。
分享爱
由于糟糕的错误消息是错误，这意味着你的团队中的每个人都可以帮助发现和修复它们。例如，UX 设计师 应该在设计和测试过程中记录预期的错误场景（或者更好的是，在错误发生之前，围绕错误进行设计）。
糟糕的错误消息是错误，我们需要修复它们。
同时，开发者应该分享在前端或后端可能出现的已知错误场景。对于特别模糊的错误，开发者和作者应该一起创建错误。任何开发者都不应该独自编写错误消息。
创建一个真相来源
如果你还没有，你需要一个错误存档，一个单一的真相来源，在那里你存储你的副本生态系统随着时间的推移而积累的所有错误消息。
如果你幸运的话，你将拥有一个集成的 CMS，它可以神奇地提取和显示你的错误字符串。如果没有，只需将你的错误记录在一个可共享的电子表格或文档中。你把它们放在哪里并不重要，只要把它们放在某个地方，避免在以后遇到类似的（甚至相同的）错误场景时重复工作。
错误存档当然应该包含字符串本身。但它还应该包含有用的元数据，例如用于更轻松跟踪的唯一 ID、描述、类别标签以及与相关设计文档或 GitHub 问题相关的链接。
修复错误是一个团队工作
糟糕的错误消息是生活中不可避免的事实，它们不会很快消失，但它们不必成为痛苦的体验，无论是对你还是对你的用户。无论你是编写新的消息还是修复旧的消息，请记住，你正在修复将改进产品的错误。这值得付出努力。
祝你寻找错误愉快！
