如何让用户阅读错误消息？[已结束]

我经常将错误显示为红色（当设计允许时）。

红色代表“警报”等，因此它更常被阅读。

首先，编写用户可以实际理解的错误消息。“错误：1023”不是很好的例子。我认为更好的方法是记录错误，而不是用一些“花哨”的代码向用户显示它。或者，如果无法进行日志记录，请为用户提供将错误详细信息发送给支持部门的正确方法。

另外，要足够简短和清晰。不要包含一些技术细节。不要向他们展示他们无法使用的信息。如果可能，请提供错误的解决方法。如果不提供默认路由，则应采用默认路由。

如果应用程序是 Web 应用，则设计自定义错误页是个好主意。他们给用户的压力较小，以 SO 为例。你可以在这里得到一些关于如何设计一个好的错误页面的想法：http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

根据我的经验：你不会让用户（尤其是非技术用户）阅读错误消息。无论您显示的消息多么清晰易懂、粗体、红色和闪烁，大多数用户都会点击他们不习惯的任何内容，即使是“你真的想删除所有内容吗？我见过用户点击“窗口关闭”图标而不是“确定”或“取消”，即使他们甚至不知道他们选择了哪个选项......

如果你真的需要强迫用户阅读你显示的内容，我建议你使用JavaScript-Countdown，直到一个按钮可以点击。这样一来，用户就有望利用等待时间来真正阅读他应该阅读的内容。但要小心：大多数用户会对这种:)感到更加恼火

此外，我还喜欢您关于“阅读更多”链接的想法，尽管我怀疑这会让用户更感兴趣，他们只是想通过各种方式摆脱该消息......

只是为了记录：有些用户确实阅读了错误消息，但非常害怕他们不会对它做任何事情。我曾经接到一个支持电话，客户会向我宣读一条错误消息，问我他应该怎么做。 “好吧，你有什么选择？”，我问。“窗口只有一个'OK'按钮，”他回答说。...嗯，硬一:)

让它们变得有趣。（考虑到我们所在的网站，这似乎是相关的:)）

根据我的观点和经验，是高级用户不阅读错误消息。我认识的非技术受众会最仔细地阅读屏幕上的每条消息，此时的问题主要是：他们不理解它。

这一点可能是你体验的原因，因为在某个时候他们会停止阅读它们，因为“反正他们不理解它”，所以你的任务很简单：

使错误消息尽可能易于理解，并将技术部分隐藏在引擎盖下。

例如，我传输了一条消息，如下所示：

ORA-00237：不允许快照操作：新创建的控制文件 原因： 尝试使用使用 CREATE CONTROLFILE 新创建的当前装载的控制文件调用 cfileMakeAndUseSnapshot。 动作： 装载当前控制文件并重试该操作。

像这样：

由于数据库出现暂时性问题，无法处理此步骤。请联系（您的管理员|技术支持人员|任何可以联系开发人员或管理员解决问题的人）。对此造成的不便，我们深表歉意。

简短的回答：你不能。

不那么简短的回答：让它们可见、相关和上下文（突出它们搞砸了什么）。但是，你仍然在打一场失败的战斗。人们不是在电脑屏幕上阅读，而是扫描，并且他们已经接受过单击按钮的训练，直到对话框消失。

根据您的用户群，编写有趣/粗鲁/个人的错误消息可以很好地工作。

例如，我编写了一个应用程序，使我们的人力资源人员能够更好地跟踪员工的雇用/解雇日期。[我们是一家小公司，非常悠闲]。

当他们输入错误的日期时，我会写：

嘿，笨蛋，学习如何输入日期！

编辑：当然，更有用的消息是说：“请输入日期为mm / dd/yyyy”，或者可能在代码中尝试找出他们输入的内容以及他们是否输入“blahblah”以显示错误。然而，对于我个人认识的人力资源人员来说，这是一个非常小的应用程序。因此，人们再次阅读这篇文章的第一行：取决于您的用户群......

我最近在艺术学院的一个项目上工作，所以错误信息是针对观众的，例如：

巴洛克时期之前的大多数艺术是 无符号。然而，我们超越了 现在的巴洛克时期，所以所有领域都必须 完成。

基本上，如果可能的话，请将其适合您的听众，并避免无聊，因为所有超凡脱俗的一般错误，例如：“请输入电子邮件”或“请输入有效的电子邮件”。

除非您可以为用户提供一些简单的解决方法，否则根本不会费心向用户显示错误消息。根本没有意义，因为 90% 的用户不会在乎它说了什么。

另一方面，如果您实际上可以向用户展示一个有用的解决方法，那么强制他们阅读它的一种方法是在 10 秒左右后启用“确定”按钮。有点像Firefox在你尝试安装新插件时的做法。

如果这是一个完全崩溃，你无法优雅地从中恢复，那么用非常外行的语言通知用户说：

"对不起，我们搞砸了，我们想发送一些关于这次崩溃的信息，你会允许我们这样做吗？是/否"

此外，尽量不要让错误消息超过一句话。当人们（包括我）看到一整段谈论错误时，我的大脑就会关闭。

由于社交媒体和信息过载如此之多，当人们看到一堵文字墙时，他们的大脑会冻结。

编辑：

最近有人也建议使用连环画以及您想要显示的任何信息。例如来自 Dilbert 的内容，它可能接近您可能遇到的错误类型。

向用户展示错误消息具有含义，这是向他们提供帮助的一种方式，他们会阅读它。如果这只是行话或通用的废话，他们将学会轻率地驳回它们。

我了解到，包含一个带有默认操作的错误对话框以发送（例如通过电子邮件）详细的诊断信息是非常好的做法，如果您快速回复这些电子邮件并提供有价值的信息或解决方法，他们会崇拜您。

这也是一个很好的学习工具。在将来的版本中，您可以解决已知问题，或者至少提供就地解决方法信息。在那之前，用户将了解到此消息是由 X 引起的，并且问题可以由 Y 解决 - 这一切都是因为有人向他们解释了这一点。

当然，这在大规模应用程序上行不通，但在只有几百个用户的企业应用程序中，以及在精益敏捷、经常发布早期版本的环境中，效果非常好。

编辑：

由于您拥有广泛的用户群，我建议您提供能够完成用户正在/可以期望它做的事情的软件，例如。如果电话号码格式不正确，请不要向他们显示错误消息，如果对于他们，请重新格式化。

我个人喜欢不会让我思考的软件，当偶尔你（开发人员）无能为力来解释我的意图时，提供一个非常好的书面（并由实际用户审查）的消息。

众所周知，人们不阅读文档（当你插入家用电器时，你是否连续阅读了说明？），他们试图一种方法来快速获得结果，当失败时，你必须抓住他们的注意力（例如，禁用默认按钮一段时间）有意义和有用的信息。他们不在乎你的软件故障，他们想得到结果，现在。

这是一个很好的问题，值得我+1。这个问题尽管很简单，但涵盖了最终用户性质的许多方面。它归结为许多因素，这些因素将使您和软件本身受益，当然也对最终用户有利。

• 不要在状态栏中放置错误消息 - 尽管它们用颜色等装饰了它，但它们永远不会读取它们。他们会永远想念他们！不管你多么努力......在 Win 95 UI 测试启动前的某个阶段，MS 进行了一项实验来读取 UI（编辑 - 应该注意的是，该消息在“看椅子下面”的上下文中明确说明），一张 100 美元的钞票贴在受试者坐的椅子底部......没有人在状态栏中发现该消息！
• 使消息简短，不要使用诸如“警报：系统遇到问题”之类的恐吓性词语，最终用户将按下紧急按钮并会反应过度......
• 无论你多么努力，都不要用颜色来识别信息......从心理上讲，这类似于向公牛挥舞红旗！
• 使用中性发音的词语来传达最小的反应以及如何进行！
• 最好显示一个对话框，列出中性错误消息，并包含一个复选框，指示“您是否希望将来看到更多这些错误消息？”，最终用户最不希望看到的就是在软件中间工作，被弹出消息轰炸，他们会感到沮丧，并被应用程序关闭！如果勾选了该复选框，请将其记录到文件中...
• 让最终用户了解将出现哪些错误消息...这意味着......培训和文档...现在这是一个棘手的问题......您不希望他们认为会出现“问题”或“故障”以及万一该怎么办......他们一定不知道会有可能的错误，这确实很棘手。
• 总是，总是，当平安无事发生时，不要害怕寻求反馈 - 例如“当错误编号 1304 出现时，您有什么反应？你的解释是什么“——这样做的好处是，最终用户可能会给你一个更连贯的解释，而不是”错误 1304，数据库对象丢失！“，相反，他们可能会说”我点击了某某，然后有人不小心拉动了机器的网线“，这将提示您必须处理它，并可能修改错误说”哎呀， 网络连接已断开'...你明白了。
• 最后但并非最不重要的一点是，如果您想针对国际受众，请考虑错误消息的国际化 - 因此这就是为什么保持中立的原因，因为这样翻译会更容易，避免同义词、俚语等会使翻译变得毫无意义 - 例如，菲亚特福特，汽车公司正在销售他们的品牌菲亚特福特平托，但注意到南美没有销售，事实证明，平托是那里的俚语，意思是“小阴茎”，因此没有销售......
• (编者注）在标题为“错误消息”或“纠正措施”或类似内容的文档的单独部分中记录预期的错误消息列表，按正确的顺序列出错误编号，并附上一两条关于如何继续的陈述......
• (编者注）感谢 Victor Hurdugaci 的投入，请保持消息礼貌，不要让最终用户感到愚蠢。这与杰克·马尔凯蒂（Jack Marchetti）的回答相反，如果用户群是国际性的......

编辑：特别感谢gnibbler，他也提到了另一个极其重要的点！

• 允许最终用户能够选择/复制错误消息，以便他们可以根据需要通过电子邮件发送给帮助支持团队或开发团队。

编辑#2：我的错！哎呀，多亏了 DanM 提到关于这辆车，我把名字弄混了，它是福特平托......我的坏...

编辑#3：已由 ed 突出显示以指示附加或附录，并归功于其他人的输入......

编辑#4：作为对 Ken 评论的回应 - 这是我的看法...... 不，不是，使用中性标准 Windows 颜色......不要追求华丽的颜色！坚持使用带有黑色文本的正常灰色背景颜色，这是 Microsoft 规范中的正常标准 GUI 指南。请参阅 UX 指南（编辑）。

如果你坚持使用华丽的颜色，至少要考虑到潜在的色盲用户，即可访问性，这是残疾人的另一个重要因素，屏幕放大友好的错误信息，色盲，那些患有白化病的人，他们可能对华丽的颜色敏感，以及癫痫患者......可能患有可能引发癫痫发作的特定颜色的人......

向他们显示消息。尽职调查等等，但将每个错误记录到一个文件中。用户不记得他们在做什么，也不记得事件发生后几秒钟的错误消息是什么，这就像目击者对攻击者的描述。

提供一种允许他们通过电子邮件或将日志上传给您的好方法，以便您可以帮助他们协调问题。如果它是一个 Web 应用程序：更好的是，您可以在任何人报告问题之前收到有关情况的信息。

警报/弹出窗口很烦人，这就是为什么每个人都会点击他们看到的第一个按钮。

让它不那么烦人。示例：如果用户输入的日期不正确，或者输入了需要数字的文本，则不要弹出消息，只需突出显示该字段并在其周围某处写一条消息即可。

创建自定义消息框。永远不要使用系统的默认消息框，例如 Windows XP 消息框本身很烦人。创建一个新的彩色消息框，其背景颜色与系统默认值不同。

非常重要：不要坚持。有些消息框使用模式对话框并坚持让你阅读它，这很烦人。如果可以将消息框显示为警告消息，那就更好了，例如，Stack Overflow 消息显示在页面顶部，通知但不烦人。

更新
：使消息有意义和有用。例如，不要写“未找到键盘，按 F1 继续”之类的内容。

我们在错误框中放置了一个简单易记的图形：不是图标，而是相当大的位图，并且与标准的 Windows 消息图标完全不同。没有人能记住消息框的措辞（如果消息框有一个可以按下的“确定”按钮，大多数人甚至不会阅读它），但大多数人都记得他们看到的图片。因此，我们的支持人员可以问客户“你看到喝咖啡的人了吗？”或“你看到空桌子了吗？”。至少这样，我们大致知道出了什么问题。

我想补充一件事。

使用动作按钮的动词来关闭错误消息而不是感叹号，例如不要使用“Ok！“关闭”等。

最好的 UI 设计将是您几乎从不显示错误消息的地方。软件应适应用户。通过这种设计，错误消息将是新颖的，并且会吸引用户的注意力。如果你用这样毫无意义的对话来刺激用户，你就是在明确地训练他们忽略你的消息。

我建议您在犯错后立即提供反馈（说明用户犯了错误）。（例如，在输入日期字段的值时，请检查该值，如果值错误，则使输入字段在视觉上有所不同）。

如果页面上有错误（我更喜欢 Web 开发，因此我将其称为“页面”，但它也可以称为“表单”），请显示“错误摘要”，解释存在错误和项目符号列表到底发生了什么错误。但是，如果每条消息的单词超过 5-6 个，则不会阅读/理解这些单词。

如何使按钮状态为“单击此处与将帮助您解决此问题的支持技术人员交谈”。

有许多网站提供与真人交谈的选项。

我们告诉用户已经联系了他们的经理（这是一个谎言）。它工作得有点太好了，必须删除。

好吧，直接回答你的问题：不要让你的程序员写你的错误信息。如果您遵循这条建议，您将累计节省数千小时的用户焦虑和生产力以及数百万美元的技术支持成本。

然而，真正的目标应该是设计你的应用程序，使用户不会犯错误。不要让他们采取导致错误按摩并要求他们备份的行动。举个简单的例子，在需要填写所有字段的 Web 表单中，不要启用“发送”按钮，而不是在用户单击“发送”按钮时弹出错误消息，直到所有字段都包含有效内容。这意味着在背面需要做更多的工作，但它会带来更好的用户体验。

当然，这是一个理想的世界。有时，程序错误是不可避免的。当它们确实发生时，您需要提供清晰、完整和有用的信息，最重要的是，不要将系统暴露给用户，也不要责怪用户的行为。

一个好的错误消息应该包含：

1. 问题是什么以及为什么会发生。
2. 如何解决该问题。

您可以做的最糟糕的事情之一就是简单地将系统错误消息传递给用户。例如，当您的 Java 程序抛出异常时，不要简单地将程序员传递给 UI 并将其公开给用户。抓住它，并由您的用户帮助开发人员创建一条清晰的消息，您可以将其呈现给您的用户。

在我的上一份工作中，我很幸运地与一个程序员团队合作，他们不会考虑编写自己的错误消息。每当他们发现自己处于需要的情况下，并且程序无法设计以避免这种情况时（通常是因为资源有限），他们总是来找我，解释他们需要什么，并让我创建一个清晰并遵循公司风格的错误消息。如果这是每个程序员的默认思维方式，那么计算世界将是一个好得多的地方。

我学到的一个很好的技巧是，你应该像写报纸文章一样写一个对话框。不是在规模意义上，而是在重要性意义上。让我解释一下。

你应该先写下最重要的东西，然后提供更详细的信息。

换句话说，这不好：

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

Do you want to retry opening the file?

相反，请更改顺序：

Problem loading file, do you want to retry?

There was a problem loading the file, the file might have been deleted, or
it might be present on a network share that you don't have access to at
your present location.

这样一来，用户就可以随心所欲地阅读，或者打扰，并且仍然对所问的内容有所了解。

减少错误

如果一个应用程序经常向你抛出呕吐物，你就会对它免疫，错误就会变成令人讨厌的背景。如果错误是罕见的事件，它将引起更多关注。

摒弃任何无关紧要的事情，抛出所有这些警告，找到理解用户意图的方法，尽可能地做出决定。我有一些应用程序，我继续以这种方式简化。开发人员认为每个错误都很重要，但从用户的角度来看，事实并非如此。查找用户对问题的共同响应并捕获该响应，将其部署为响应。

如果您确实需要提出错误：简短、简洁、低恐怖因素，没有感叹号。段落不及格。

没有灵丹妙药，但你需要进行社会工程，使错误变得重要。

我在 slashdot 上读到了一个最可怕的解决方案的候选者：

我们发现，唯一的办法是 让用户承担责任 错误是给他们一个惩罚 强制错误消失。为 启动器，在可能的情况下，错误 除非我们 输入管理员密码即可 离开，如果他们重新启动以摆脱 它（任务管理器在所有 客户端 PC）计算机无法打开 崩溃了 15 的应用程序 纪要。当然，这一切都取决于 关于您正在处理的用户类型 与，作为技术更熟练的用户 不会接受这种制度， 但在尝试了多年之后 让用户承担责任 崩溃并确保 IT 部门了解它们是为了 在问题变得太严重之前解决问题 难以管理，这些是唯一的 有效的步骤。现在，我们结束了 用户知道，如果他们忽略 错误，他们将为此而受苦 它自己。

添加一个“高级”按钮，支持更多技术细节，这将为那些认为自己是技术的目标受众提供阅读它的动力

“注意！注意力！如果你不阅读错误信息，你就会死！

尽管接受的答案中有所有建议，但我的用户继续点击他们能找到的第一个按钮。所以现在我展示这个：

用户必须在“确定”按钮出现之前做出选择

如果他选择第三个选项，他可以继续，否则应用程序将退出。