如何让用户阅读错误消息？

如果您的程序是为非技术用户编写的，那么您会发现自己面临很大的风险: 用户将不会阅读您精心编写的、具有启发性的错误消息，而只是带着沮丧的心情点击第一个可用按钮。

因此，我想知道您可以推荐哪些好的实践来帮助用户实际阅读您的错误消息，而不是简单地将其放在一边。我能想到的主意大致如下:

  • 格式化当然有帮助; 可能是一个简单的短消息，带有一个“ learn more”按钮，导致更长、更详细的错误消息
  • 将所有错误消息链接到用户指南的某个部分(有点难以实现)
  • 只要不发出错误消息，只要拒绝执行任务(一种有点“苹果”的方式来处理用户输入)

编辑: 我心目中的用户群是一个相当广泛的用户群，他们不经常使用软件，也不受限制(例如，没有内部软件或狭窄的社区)。这个问题的一般形式是在 斜杠上提出的，所以你可能想从 检查那里获得一些答案。

5788 次浏览
小开

我经常用红色显示错误(当设计允许时)。

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

小开

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

还有，要简洁明了。不包括一些技术细节。不要向他们展示他们无法使用的信息。如果可能的话，为错误提供一个解决方案。如果没有提供默认路由，则应采用。

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

小开

根据我的经验: 不要让用户(特别是非技术用户)阅读错误消息。无论你显示的信息多么清晰易懂，多么醒目，多么红色，多么闪烁，大多数用户还是会点击他们不习惯的任何东西，即使是“你真的想删除所有东西吗?”.我见过用户点击“窗口关闭”-图标，而不是“确定”或“取消”，即使他们甚至不知道他们选择了哪一个选项，这样做..。

如果你真的需要强迫用户阅读你正在显示的内容，我建议使用 JavaScript 倒计时，直到按钮可以点击为止。这样，用户就有希望利用等待时间来真正读取他应该读取的内容。不过要小心: 大多数用户会对此更加恼火:)

我还喜欢你的“阅读更多”的想法-链接，虽然我怀疑这会让用户更感兴趣，只是想摆脱消息的一切手段..。

仅供记录: 有些用户确实读取了错误消息，但是他们非常害怕不会对其做任何事情。有一次我接到一个支持电话，客户给我读了一条错误信息，问我他应该怎么做。“那你有什么选择?”我问。“窗口只有一个‘ OK’按钮。”他回答道。... 嗯，难的一个:)

小开

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

小开

根据我的观点和经验，是高级用户不会阅读错误消息。我认识的非技术人员会非常仔细地阅读屏幕上的每一条信息，现在的主要问题是: 他们不理解。

这一点可能是你经历的原因，因为在某些时候他们会停止阅读，因为“他们无论如何都不会理解”，所以你的任务很简单:

使错误信息尽可能容易理解，并保持技术部分的引擎盖下。

例如，我传递这样一条信息:

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

比如:

由于数据库暂时出现问题，无法处理此步骤。请联系(你的管理员 | 帮助台 | 任何人可以联系开发人员或管理员解决问题)。抱歉给你带来不便。

小开

简短的回答: 你不能。

简短的回答: 让他们可见，相关，和上下文(突出他们搞砸了)。但你还是在打一场注定失败的战斗。人们不在电脑屏幕上阅读，他们扫描，他们已经被训练点击按钮，直到对话框消失。

小开

根据你的用户基础，写有趣的/粗鲁的/个人的错误信息可以很好的工作。

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

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

嘿，笨蛋，学学怎么参加约会吧！

编辑: 当然，更有用的信息是说: “请输入日期为 mm/dd/yyyy”，或者在代码中尝试找出他们输入了什么，如果他们输入“ blahba”显示一个错误。然而，对于我个人认识的一个人力资源人员来说，这是一个非常小的应用程序。因此，再次人们，阅读这篇文章的第一行: 取决于你的用户基础..。

我最近参与了一个艺术学院的项目，因此错误信息是面向观众的，比如:

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

如果可能的话，基本上把它装备给你的听众，并且避免像所有不可思议的常见错误一样令人厌烦，比如: “请输入电子邮件”或“请输入有效的电子邮件”。

小开

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

另一方面，如果 可以实际上向用户展示了一个有用的解决方案，那么强制用户阅读的一种方法是在10秒左右后启用 OK 按钮。类似于 Firefox 在您尝试安装新插件时的做法。

如果这是一个完全崩溃，你不能优雅地恢复，然后通知用户在非常通俗的术语说:

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

此外，尽量不要让您的错误消息长于一个句子。当人们(包括我在内)看到一整段都在谈论这个错误时，我的大脑就会关闭。

有这么多的社交媒体和信息超载，当人们看到一大堆文字时，他们的思维会停滞不前。

编辑:

有人最近还建议使用连环漫画连同任何你想要显示的信息。比如来自 呆伯特的一些信息，它们可能与您可能遇到的错误类型非常接近。

小开

向用户显示错误 信息是有意义的，这是一个方法到 为他们提供协助，他们将读取它。如果只是一些行话或者无意义的信息，他们就会学会迅速地忽略它们。

我已经学到了一个非常好的做法，包括一个错误对话框与默认行动发送(例如通过电子邮件)详细的诊断信息，如果你快速回应这些电子邮件与有价值的信息或解决方案，他们会崇拜你。

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

当然，这不适用于大规模应用程序，但是适用于只有几百个用户的企业应用程序，并且适用于精益敏捷、经常发布早期版本的环境。

编辑:

因为你有一个广泛的用户基础，我建议提供软件，做什么用户是/可以期望它做，例如，不要显示他们的错误信息，如果电话号码格式不好，重新格式化，如果为他们。

我个人喜欢 不会让我觉得软件，当有时你(开发人员)无法解释我的意图，提供一个非常好的写(和审查的实际用户)消息。

众所周知，人们不阅读文档(当你插入家庭电器的时候，你有没有背对背地阅读说明书?)，他们尝试一种方法，以获得结果快速，当失败时，你必须抓住他们的注意力(例如禁用默认按钮一段时间)与 有意义和 很有帮助信息。他们不关心你的软件故障，他们想要的是结果，现在就要。

小开
最佳答案

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

  • 不要把错误信息的状态栏-他们将永远不会阅读他们，尽管有它与颜色等活泼起来... 他们将永远错过他们！不管你怎么努力尝试... 在 Win 95用户界面测试发布前的一个阶段，MS 进行了一个读取用户界面(Ed - 应该注意的是，信息明确指出，在上下文中“看看椅子下面”)的实验，把一张100美元的钞票贴在实验对象所坐的椅子下面... 没有人发现状态栏中的信息！
  • 短消息，不要使用恐吓的话，如“警报: 系统遇到问题”，最终用户将按下恐慌按钮，将过度反应..。
  • 无论你多么努力，不要用颜色来识别信息... ... 从心理上来说，这类似于向公牛挥舞红旗！
  • 使用中性发音的词语来传达最小的反应和如何进行！
  • 最好显示一个列出中性错误消息的对话框，并包含一个表示“您希望在将来看到更多这些错误消息吗?”的复选框？最终用户最不想看到的就是在软件中间被弹出消息轰炸，他们会感到沮丧，并且会被应用程序关闭！如果勾选了复选框，则将其记录到一个文件中..。
  • 让最终用户知道会有什么错误消息... 这意味着... 培训和文档... 现在这是一个棘手的通过... 你不希望他们认为，将有“问题”或“故障”，以及在这种情况下该怎么办... 他们一定不知道，有可能会有错误，确实很棘手。
  • 总是，总是，不要害怕要求反馈时，平安无事的发生-如’当错误号码1304显示，你是如何反应？什么是你的解释’-奖金与此同时，最终用户可能会给你一个更连贯的解释，而不是“错误1304，数据库对象丢失!”相反，他们可能会说“我点击了这个，然后有人意外地拉了机器的网络电缆”，这将提示你必须处理它，并可能修改错误说“哎呀，网络连接断开”... 你得到漂移。
  • 最后但并非最不重要的，如果你想针对国际受众，考虑到国际化的错误信息-因此这就是为什么保持中立，因为这样更容易翻译，避免同义词，俚语等，这将使翻译毫无意义-例如，菲亚特福特，汽车公司销售他们的品牌 菲亚特福特平托，但注意到没有销售发生在南美洲，结果，平托是一个俚语“小阴茎”，因此没有销售..。
  • (Ed)在标题为“错误信息”或“纠正措施”或类似的文档的单独部分中记录预期的错误信息列表，以正确的顺序列出错误编号，并附上一两条关于如何继续的陈述..。
  • (Ed)感谢 Victor Hurdugaci的输入，保持信息礼貌，不要让终端用户感到愚蠢。如果用户基础是国际性的，这与 杰克 · 马切蒂的答案相反..。

编辑: 特别感谢 小点心提到的另一个极其重要的观点！

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

编辑 # 2: 我的错！哎呀，多亏 丹提到了那辆车，我把名字搞混了，是福特平托... 我的错..。

编辑 # 3: 由 Ed突出显示以指示附加内容或附录，并记入他人的输入..。

编辑 # 4: 回应肯的评论——这是我的看法..。 不，它不是，使用中性的标准窗口颜色... 不要去华而不实的颜色！坚持使用带黑色文本的正常灰色背色，这是 Microsoft 规范中的标准 GUI 指南。.见 用户体验指引(Ed)。

如果你坚持使用华丽的颜色，至少要考虑到那些可能有色盲的用户，比如那些有残疾的人，屏幕放大率友好的错误信息，色盲，那些患有白化病的人，他们可能对华丽的颜色很敏感，还有癫痫病人... ... 他们可能患有某种特定的颜色，可能会引发癫痫... ..。

小开

给他们看信息。尽职调查和所有，但记录每一个错误的文件。用户在事件发生几秒钟之后就不记得他们在做什么，也不记得错误消息是什么，这就像是运营商的目击者帐户。

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

小开

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

使它 更少恼人 。例如: 如果用户输入的日期不正确，或者输入的文本中预期的数字，然后 不要弹出一条消息，只需突出显示该字段并在其周围某处写入一条消息。

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

非常重要: 不要坚持。一些消息框使用模态对话框，并坚持让你阅读它，这是非常恼人的。如果您可以使消息框显示为一个警告消息，那么它会更好，例如，Stack Overflow 消息显示在页面的顶部，通知但不恼人。

更新
使消息有意义且有帮助 。例如，不要写诸如“找不到键盘，按 F1继续”之类的内容

小开

我们在错误框中放置了一个简单易记的图形: 不是图标，相当大的位图，和标准的 Windows 消息图标完全不同。没有人能记住一个信息框的措辞(大多数人甚至不会读它，如果它有一个“确定”按钮，他们可以按下) ，但大多数人确实记得他们看到的图片。因此，我们的支持人员可以问客户“你看到那个喝咖啡的家伙了吗?”或者“你看到那张空桌子了吗?”.至少这样我们大致知道哪里出了问题。

小开

我想补充一点。

使用动词作为动作按钮来关闭错误信息而不是感叹号，例如不要使用“ OK!”“关闭”等等。

小开

最好的用户界面设计将是您实际上从不显示错误消息的地方。这个软件应该适合用户。使用这种设计，错误消息将是新颖的，并将吸引用户的注意力。如果你用这种毫无意义的对话框来麻烦用户，你就是在明确地训练他们忽略你的信息。

小开

我建议你在错误发生后立即给出反馈(说明用户犯了一个错误)。(例如，当输入一个日期字段的值时，检查该值，如果错误，则使输入字段在视觉上不同)。

如果页面上有错误(我更喜欢 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年的应用程序 当然，这一切都取决于 你交易的用户类型 作为技术上更熟练的用户 不会接受这种制度, 但是经过几年的努力 让用户承担责任 系统崩溃，并确保信息技术 部门知道他们的顺序 在事情变得更糟之前解决问题 很难管理，这是唯一的 成功的步骤，现在，我们所有人 用户知道，如果他们忽略 错误，他们将为此受到惩罚 它们自己。

小开

添加一个“高级”按钮，使一些更多的技术细节，将提供一个激励阅读的目标受众的一部分，认为自己是技术

小开

“注意! 注意! 如果你不阅读错误信息，你将死亡!”

小开

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

Read this!

用户 已经在 OK 按钮出现之前做出选择

Chose the correct option

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


提交答案