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