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

Question

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

user-interfaceruntime-errorerror-reportingui-design

181

如果你为非技术人员编写程序，你会发现自己面临着一个很高的风险，那就是用户不会仔细阅读你精心措辞和启迪性的错误信息，而只是在沮丧的耸肩中点击第一个可用的按钮。

所以，我想知道您能推荐哪些好的做法，以帮助用户实际阅读您的错误消息，而不是简单地将其搁置。我能想到的想法可能是：

当然，格式化有所帮助；也许是一个简单、简短的消息，带有一个“了解更多”的按钮，该按钮会导向更长、更详细的错误消息
所有错误消息都链接到用户指南的某个部分（有点难实现）
不要发布错误消息，只需拒绝执行任务（这是一种有点“苹果”式处理用户输入的方式）

编辑：我考虑的受众是一个相当广泛的用户群体，他们不经常使用软件，也不是被困住的（即没有内部软件或狭窄的社区）。关于这个问题的一个更通用的形式在slashdot上提出过，因此您可能想要check there看看其中的一些答案。

- F'x

3

你的软件针对哪个受众？比如几家公司或者互联网用户？你能与用户建立关系吗？ - Janusz Skonieczny

@WooYek：在我的情况下，这将是一个相当庞大的用户群，但使用时间有限（即它不是你经常使用的软件，更多的是“偶尔使用”，具有潜在的大量用户群）。 - F'x

这些错误信息是像有人没有填写表单的所有字段那样的错误消息，还是像某些东西爆炸了那样的错误消息？ - Tom

为什么要说“针对非技术人员的受众”？你已经发现了让技术用户阅读错误信息的诀窍吗？如果是这样，请分享，因为这可能有助于找到针对非技术人员的解决方案！ - Ken

对于技术人员，选择是不同的，因为他们对自己的选择负责。或者应该这样！ - F'x

25个回答

17

展示给他们这条信息。尽职调查之类的，但是要将每个错误记录到文件中。用户在事件发生几秒钟后无法记住他们在做什么或错误消息是什么，就像对罪犯的目击证言。

提供一个良好的方式让他们通过电子邮件或上传日志来协助您解决问题。如果它是一个 Web 应用程序：更好的是，您可以在任何人报告问题之前收到关于情况的信息。

- MikeJ

2

这个非常赞！请注意，开发人员部分可以包含完整的堆栈跟踪和其他细节。如果需要，甚至可以捕获应用程序屏幕截图（特别是针对内部WinForms应用程序）。 - TrueWill

我有点不愿意认为“捕获应用程序截图”是一个好建议：毕竟，这听起来像是严重泄露私人数据（即使你的应用程序从一开始就没有设计处理NSA级别的信息）... - F'x

我认为这更多是由领域用户处理的业务/政策决策，而不是通过提供“黑匣子”崩溃诊断支持来提供更好支持的技术方面。我预计内部LOB应用程序与外部客户支持关系中涉及敏感信息的不同问题/目标可能会有所不同。 - MikeJ

11

简短回答：你不能。

稍微长一点的回答：让它们变得明显、相关和有上下文（强调他们搞错了什么）。但是，你仍然在打败的征途中。人们在电脑屏幕上不是读，而是扫描，并且他们已经习惯了点击按钮直到对话框消失。

- Matt Garrison

那种习惯性点击对话框的行为是旧版IE ActiveX安装对话框的一个真正问题。 - Alex Jasmin

10

根据您的用户群，编写有趣/粗鲁/个人化的错误消息可能非常有效。

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

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

嘿，蠢货，学着如何输入日期吧！

编辑：当然，更有帮助的信息是说：“请将日期输入为mm/dd/yyyy”，或者在代码中尝试确定他们输入了什么，“blahblah”来显示错误。然而，这是针对我个人认识的人力资源人员的一个非常小的应用程序。因此，再次强调，请阅读本帖子的第一行：根据您的用户群...

最近我参与了一个艺术学院的项目，因此错误消息是针对观众而设计的，例如：

巴洛克时期之前的大多数艺术作品都没有签名。但现在我们已经超过了巴洛克时期，所以所有字段都必须填写。

基本上，请尽可能针对您的观众进行调整，避免极其无聊的通用错误，例如：“请输入电子邮件”或“请输入有效的电子邮件”。

- Jack Marchetti

8

学习如何输入日期！- 当然，但请给我一些提示。我不应该猜测正确的格式。 - Alex Jasmin

不仅如此，还不要强制我首先输入日期。做一个假设（*）。如果假设是错误的，最坏的情况是你告诉用户不输入日期的后果。如果你只是稍微聪明一点，你的很多用户会接受你的猜测，你将节省他们的时间而不是浪费他们的时间。（*）不适用于安排导弹发射或婚礼。 - Bryan Oakley

2

我不确定我喜欢那种信息...毕竟，为什么我要学习如何输入日期呢？ - F'x

1

不要要求用户去弄清日期格式，多花几分钟时间教导你的软件如何解析多种格式的日期。计算机很聪明——让它来帮助用户，而不是指责他们。 - Bryan Oakley

@FastAl - 幽默肯定有帮助，这要看网站的情况。比如，还记得Winamp吗？[它真的很厉害！] 这真是太好笑了。或者他们的网站曾经说过“它有点能工作，我们想”。这简直太棒了。幽默的信息更容易被阅读。 - Jack Marchetti

显示剩余3条评论

10

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

让它变得更加不那么烦人。例如：如果用户输入了错误的日期或输入了数字应该在的位置上的文本，则不要弹出消息，只需突出显示该字段并在其周围写一条消息。

制作自定义消息框。不要使用系统的默认消息框，例如Windows XP消息框本身就很烦人。制作一个新的有颜色的消息框，背景颜色与系统默认颜色不同。

非常重要：不要坚持。某些消息框使用模态对话框，并坚持让您阅读它，这很烦人。如果您可以将消息框显示为警告消息，那将更好，例如Stack Overflow消息直接出现在页面顶部，提供信息但不烦人。

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

- mohdajami

2

1和3很好。2因为可访问性原因有问题。系统标准控件可以被特殊处理，但你的变量不能。 - Phil Miller

1

@Novelocrat，如果你的应用程序剩下的部分是可访问的，那么你的自定义错误对话框也会是可访问的。而且，如果你的应用程序已经存在无障碍问题，那么再加上一个有问题的对话框也不会有什么影响。 - Mike Daniels

@Novelocrat，我主要是在谈论Web应用程序，而不是默认的JavaScript警告框，您可以创建一个新的时尚框，并赋予它相同的属性。但是，如果目的是强制阅读消息，则相同的想法也适用于桌面应用程序。 - mohdajami

1

和Novelocrat一样，我也不太喜欢答案中的“永远不要使用系统UI”这部分。人们想要感觉自己处于熟悉的领域。 - F'x

而且，对于系统UI来说，可访问性总是更好的。 - F'x

10

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

- Bob Moore

1

我对这个想法的问题在于它打破了人们期望的UI统一性。此外，他们怎么知道“空桌子”比“喝咖啡的人”更具威胁性？ - F'x

我们制作单一用途的系统（应急控制中心），因此我们只关注该系统内的UI统一性。无论如何，这里并不意味着对威胁的层次结构。目的只是为了易于记忆。这两个图形实际上代表类似的不活动情况（操作员离开桌子，操作员可能在休息），因此它们将有意义...但这不是它们的真正目的。我们只想让它们易于记忆。也许我不应该提到跳舞老鼠 :-)。 - Bob Moore

8

最好的UI设计是在您几乎从不显示错误消息的情况下。软件应该适应用户。采用这种设计，错误消息将是新颖的，会吸引用户的注意力。如果您频繁地向用户展示无意义的对话框，那么您明确地在训练他们忽略您的信息。

- Bryan Oakley

7

在我看来和经验中，不读错误消息的是那些高级用户。而我所认识的非技术人员会仔细阅读屏幕上的每一条消息，但此时问题大多是：他们不理解它。

这可能是你经验的原因，因为他们最终会停止阅读它们，因为“反正他们也不理解”，所以你的任务很简单：

尽可能使错误消息易于理解，并将技术部分隐藏起来。

例如，我将一个消息转换成这样：

此步骤无法处理，因为数据库出现瞬时问题。请联系（管理员|帮助台|任何能够联系开发者或管理员解决问题的人）。对此给您带来的不便，我们深表歉意。

- bl4ckb0l7

2

然后管理员/帮助台等人听到这条消息，会问：“我该怎么办？”你的第二条消息太过笼统，毫无用处。至于前者，虽然我从未使用过Oracle软件（根据前缀猜测），但我仍可以推测出我应该怎么做。 - Phil Miller

帮助台可以通知开发人员修复问题。在错误信息中写入技术性的消息，这对客户或帮助台有帮助吗？此时用户想要知道的只是：发生了什么事情，如果不是他造成的错误（错误输入或其他原因），他在哪里可以得到帮助。当然，在表现层上这是要传达的信息。在服务器日志中，会有具体的错误信息，这将有助于您进行修复。 - bl4ckb0l7

1

@Novelocrat，不错。你经常会听到技术支持人员喊：“但我就是系统管理员，我完全不知道问题出在哪里！”最好在错误提示中添加一个“展示技术术语”的选项。 - Mike Daniels

当出现商业现成应用程序且错误信息不包含任何有用信息时，技术支持部门无法提供太多帮助。 - Mike Daniels

5

展示用户错误信息的含义，这是为他们提供帮助并让他们阅读它的一种方式。如果只是术语或常见的无意义信息，他们会很快忽略它们。

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

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

当然，在大规模应用程序上这种方法不适用，但在具有几百个用户的企业应用程序中以及精益敏捷、尽早发布和经常发布的环境中非常有效。

编辑：

由于您有广泛的用户群，我建议提供软件，使用户可以期望它所做的事情，例如如果电话号码格式不正确，则不要显示错误消息，为他们重新格式化。

我个人喜欢那些不需要让我思考的软件，偶尔如果开发者不能理解我的意图，也要提供非常好的（并由实际用户审核过的）消息。

众所周知，人们不会阅读文档（当你插入家用电器时是否曾经反复阅读说明书？），他们会尝试快速获得结果，失败后你必须用有意义的和有帮助的信息吸引他们的注意力（例如暂时禁用默认按钮）。他们不关心你的软件故障，他们想要立即获得结果。

- Janusz Skonieczny

3

我学到的一个好建议是，你应该像写报纸文章一样编写对话框。不是在大小意义上，而是在重要性意义上。让我解释一下。

你应该首先写最重要的内容，然后提供更详细的信息。

换句话说，这样做是不好的：

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.

这样，用户可以阅读他想要或感兴趣的部分，并仍然了解所提出的问题是什么。

- Lasse V. Karlsen

太好了！用户会阅读第一句话，或者前半句话，如果句子结构过于复杂，或者技术性太强以至于他们无法理解，或者与他们打算做的事情不相关，他们肯定会跳过剩下的内容。我甚至会在解释部分之前加上一句话，比如说：“这可能是发生的情况” - 更好的方法是提出解决方案，告诉用户可以做什么：“检查文件是否已移动，或者需要重新连接所在的网络驱动器”。 - not2savvy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- t0mm13b · Accepted Answer

这是一个非常好的问题，值得我点赞。尽管这个问题看似简单，实际上涵盖了很多有关终端用户本质的方面。它归结于以下几个因素，这些因素对您和软件本身以及最终用户都有好处。

不要将错误消息放在状态栏中——即使你为其添加了颜色等修饰，用户也永远不会去读它们……他们总是会错过！无论你如何努力……在 Win 95 UI 发布之前的某个阶段，微软进行了一项实验，试图读取界面（请注意，在此情况下消息明确指出：“看看椅子底下”），并在被试坐的椅子的底部贴上一张100美元的钞票……没有人注意到状态栏中的消息！
让消息变短，不要使用令人生畏的词汇，如“警告：系统遇到问题”，终端用户会按下紧急按钮并过度反应……
无论你如何努力，都不要使用颜色来标识消息……从心理学角度来看，这就像向公牛挥舞红旗！
使用中性的措辞来传达最少的反应和如何进行！
最好显示一个对话框，列出中性的错误消息，并包括一个复选框，指示“您是否希望在将来看到更多这样的错误消息？”终端用户最不想做的就是在软件中间被弹出窗口消息轰炸，他们会感到沮丧并对应用程序失去兴趣！如果复选框被选中，请将其记录到文件中……
让最终用户了解将有哪些错误消息……这意味着……培训和文档……这确实是一个棘手的问题……你不希望他们认为会有“问题”或“故障”，以及在发生这种情况时该怎么做……他们不能知道可能会出现错误，这真是棘手。

无论何时，都要勇于寻求反馈，尤其是在出现不好的情况时——比如，“当错误代码1304出现时，你是如何反应的？你是怎么解释它的？”——这样做的好处是，最终用户可能会给您一个更连贯的解释，而不仅仅是“错误1304，数据库对象丢失！”，他们可能能够说：“我点击了这个什么的，然后有人意外地拉断了机器上的网络电缆”，这将提示您需要处理它，并可能修改错误为“糟糕，网络连接已断开”...你明白了。

最后，如果您想面向国际受众，请考虑错误消息的国际化——因此保持中立很重要，因为这样将更容易进行翻译，避免使用同义词、俚语等使翻译毫无意义的词语——例如，“Fiat”汽车公司销售他们的品牌“Fiat Pinto”，但发现在南美没有销售量，原来，“Pinto”在那里是指“小鸡鸡”，因此没有销售...

（编辑）在文档的单独部分中记录预期的错误消息列表，标题为“错误消息”或“纠正操作”等，按正确顺序列出错误号，并附有一两句话说明如何继续操作...

（编辑）感谢Victor Hurdugaci的贡献，请保持信息礼貌，不要让最终用户感到愚蠢。如果用户群是国际性的，这与Jack Marchetti的回答相反...

（编辑）再次特别感谢gnibbler提出的另一个极其重要的观点！

允许最终用户能够选择/复制错误消息，以便他们可以自愿将其电子邮件给帮助支持团队或开发团队。

编辑#2:对不起！糟糕，感谢 DanM 指出在汽车方面的错误，我把名称搞混了，它是福特Pinto...我错了...

编辑#3:通过ed突出显示补充说明，并归功于其他人的贡献...

编辑#4:回应Ken的评论 - 这是我的看法... 不是，使用中性标准Windows颜色...不要使用花哨的颜色！坚持使用正常的灰背景色和黑色文本，这是Microsoft规范中常见的GUI指南..请参见UX Guidelines (ed).

如果您坚持使用花哨的颜色，请至少考虑到潜在的色盲用户，即残疾人士的另一个重要因素——可访问性，屏幕放大友好的错误消息，色盲者，那些患有白化病的人可能对花哨的颜色敏感，以及癫痫患者...他们可能会因为某些颜色而引发癫痫发作...