logo标签列表

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

user-interfaceruntime-errorerror-reportingui-design
181
如果你为非技术人员编写程序，你会发现自己面临着一个很高的风险，那就是用户不会仔细阅读你精心措辞和启迪性的错误信息，而只是在沮丧的耸肩中点击第一个可用的按钮。
所以，我想知道您能推荐哪些好的做法，以帮助用户实际阅读您的错误消息，而不是简单地将其搁置。我能想到的想法可能是：
  • 当然，格式化有所帮助；也许是一个简单、简短的消息，带有一个“了解更多”的按钮，该按钮会导向更长、更详细的错误消息
  • 所有错误消息都链接到用户指南的某个部分（有点难实现）
  • 不要发布错误消息，只需拒绝执行任务（这是一种有点“苹果”式处理用户输入的方式）
编辑：我考虑的受众是一个相当广泛的用户群体，他们不经常使用软件，也不是被困住的（即没有内部软件或狭窄的社区）。关于这个问题的一个更通用的形式在slashdot上提出过，因此您可能想要check there看看其中的一些答案。
3
你的软件针对哪个受众？比如几家公司或者互联网用户？你能与用户建立关系吗？ - Janusz Skonieczny
@WooYek：在我的情况下，这将是一个相当庞大的用户群，但使用时间有限（即它不是你经常使用的软件，更多的是“偶尔使用”，具有潜在的大量用户群）。 - F'x
这些错误信息是像有人没有填写表单的所有字段那样的错误消息，还是像某些东西爆炸了那样的错误消息？ - Tom
为什么要说“针对非技术人员的受众”？你已经发现了让技术用户阅读错误信息的诀窍吗？如果是这样，请分享，因为这可能有助于找到针对非技术人员的解决方案！ - Ken
对于技术人员，选择是不同的，因为他们对自己的选择负责。或者应该这样！ - F'x
25个回答
2

通常我会把错误信息显示为红色（在设计允许的情况下）。

红色代表“警告”等，因此更容易引起注意。

3
那么对于色盲的人怎么办？ - Natrium
1
作为一个色盲者，我甚至不确定“红色”是什么颜色。 - MikeJ
红色并不是普遍被解释为警示。例如，有些文化将其解释为幸福。在选择颜色时，请注意您潜在用户的身份。 - Bryan Oakley
1
@MikeJ：显然，Tyzak应该让它闪烁。那样会更有帮助。其他人说是“红色”的区域和他们说是“透明”的区域之间存在价值（亮度）差异，不是吗？ - Phil Miller
@PhilMiller，让它闪烁？我真的希望这是一种讽刺的评论！ :-) - not2savvy
显示剩余2条评论
2
要开始，编写用户实际能够理解的错误信息。"Error：1023"不是一个好的例子。我认为更好的方法是记录错误，然后使用一些“花哨”的代码向用户显示它。或者，如果无法记录错误，则为用户提供将错误详细信息发送到支持部门的适当方式。
此外，要简短明了。不要包含一些技术细节。不要向他们显示不能使用的信息。如果可能，提供一个解决错误的方法。如果不行，请提供默认路由。
如果您的应用程序是Web应用程序，则设计自定义错误页面是一个好主意。他们会给用户带来更少的压力，以Stack Overflow为例。您可以在此处获取有关如何设计良好错误页面的一些想法：http://www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/。
2
根据我的经验：你无法让用户（尤其是非技术用户）阅读错误消息。无论你显示多么清晰易懂、加粗、红色闪烁的消息，大多数用户都会点击任何不熟悉的东西，即使它是“您真的要删除所有内容吗？”。我曾看到用户甚至点击“窗口关闭”图标，而不是“确定”或“取消”，尽管他们甚至不知道这样做选择了哪个选项...
如果你真的需要强制用户阅读你显示的内容，我建议使用JavaScript倒计时直到按钮可点击。这样用户就可以利用等待时间来认真阅读他应该阅读的内容。不过要小心：大多数用户会更加恼怒 :)
此外，我还喜欢你的“阅读更多”链接的想法，尽管我怀疑这并不能让那些只想尽快摆脱消息的用户更感兴趣...
仅供参考：有些用户确实会阅读错误消息，但他们太害怕了，不会采取任何行动。我曾经接到一个支持电话，客户向我读出一条错误消息，问我该怎么办。“那你有哪些选项？”，我问。“窗口上只有一个'确定'按钮。”他回答。...嗯，这个有点难 :)
12
这种"JavaScript倒计时"是你可以做的最恼人的事情。用户会讨厌“不得不等待时钟倒数”，几乎无法专注于错误文本而感到愤怒。 - bl4ckb0l7
2
2
除非你能够为用户提供一些简单的解决方法，否则最好不要显示任何错误信息。因为90%的用户都不会在意它说了什么。
另一方面，如果你确实可以向用户显示有用的解决方法，那么强制他们在10秒左右后启用“确定”按钮是一种方式，就像Firefox在你尝试安装新插件时所做的那样。
如果是一个完全崩溃，你无法从中恢复，那么用非常通俗易懂的语言告知用户：
“对不起，我们出了点问题，我们想发送一些关于这个崩溃的信息，你允许我们这样做吗？是/否”
此外，尽量不要让你的错误信息超过一句话。当人们（包括我）看到整段讲述错误的文字时，我的大脑就会关闭。
随着社交媒体和信息过载的增加，当人们看到一堵墙的文字时，他们的思维就会停滞。
编辑：
有人最近还建议在想要展示的信息旁边使用漫画，比如从Dilbert中挑选一个与你可能遇到的错误类型相似的漫画。
1
您可以在此处搜索相关的Dilbert漫画：http://www.bfmartin.ca/finder - SLaks
十秒钟？看一下时钟，数十秒。当你试图完成某些该死的工作时，这是一个永恒。 - Mike Daniels
1
Mike，这只是一个例子，不是铁板钉钉的。你可以选择任何超时时间。或者，你有安装Firefox插件吗？那个倒计时真的让你很烦吗？我没有听到太多人抱怨。 - 7wp
1
@Mark，正是因为这个Stack Overflow问题被提出的原因。太多人轻易点击而不去阅读消息及其后果，最终做了他们本不想做的事情。Mark，你知道并理解你所点击的内容。然而，曾经在惠普技术支持工作过的我知道，有些人只是因为可以而随意点击。延迟强制用户停下来看一下消息，而不是说“是啊，好的，我会点击确定，走吧”。 - 7wp
@Mark和@EveryoneElse，我并没有说每个消息都应该使用10秒超时。我的意思是在重要且不可避免的消息上使用它。这些消息是程序员希望用户阅读的，因为它们影响应用程序功能的某些重要方面。 - 7wp
显示剩余4条评论
2

我想补充一件事。

在关闭错误消息时，使用动词作为您的操作按钮，而不是感叹号，例如不要使用“好的！”、“关闭”等。

1
有些平台不允许你这样做。对于这些限制，几乎都有很好的理由。 - Phil Miller
我强烈支持Novelocrat的评论。标准化的用户界面对用户有好处（因此也对您有好处）。我认为坚持使用标准按钮标签可以实现一些你不想失去的东西，即使是为了吸引注意力（除非在特殊情况下）。 - F'x
你不需要使用JS alerts()来显示错误信息。你可以构建自己的对话框窗口。此外，使用动词而不仅仅是感叹词的目的是因为如果你看到“确定”作为一个按钮，你将不得不阅读对话框的内容。问题是有些用户不会花时间去做这件事，所以他们会直接点击确定。如果你使用动词来描述动作，那么用户就知道发生了什么，而不必阅读对话框。 - Mark
关闭是一个动词。你在自己的句子中使用了它；“关闭你的错误消息”。 - Ricket
但是，@Mark，这个问题是关于让他们阅读它的 :p - Bart van Heukelom
1
添加一个“高级”按钮，以启用一些更多的技术细节，将为那些认为自己是技术人员的目标受众提供阅读的动力。
1

我们告诉用户他们的经理已经被联系了（这是一个谎言）。它起作用的效果有点太好了，所以必须将其删除。

1

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

然而，真正的目标应该是设计您的应用程序，使用户无法犯错。不要让他们采取导致错误消息的行动并要求他们回退。作为一个简单的例子，在需要填写所有字段的 Web 表单中，不要在用户点击发送按钮时弹出错误消息，而是在所有字段都包含有效内容之前不启用发送按钮。这意味着在后台需要更多的工作，但它会带来更好的用户体验。

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

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

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

你绝不能简单地将系统错误消息传递给用户，这是最糟糕的事情之一。例如，当你的Java程序抛出异常时，不要简单地将程序员术语传递到UI并暴露给用户。捕获它，并由您的用户辅助开发人员创建清晰的消息，以便向用户呈现。

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

1

减少错误

如果一个应用程序经常向您抛出错误，您会对此变得免疫，错误会成为令人恼火的背景音乐。如果错误是罕见事件，它将引起更多关注。

排除任何不重要的问题，删除所有这些警告，找到理解用户意图的方法，尽可能减少决策。我有一些应用程序，我继续以这种方式简化它们。开发人员认为每个错误都很重要，但从用户的角度来看，这并不是真的。寻找用户对问题的常见反应，并捕获它，将其部署为您的响应。

如果您确实需要引发错误：简短、简洁、低恐怖因素，不要使用感叹号。段落是失败的。

没有万能药，但您需要进行社交工程，使错误变得重要。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接