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

如果您为非技术用户编程,您会发现自己处于高度风险之中,用户不会阅读您认真的措辞和启发性的错误消息,而只需点击第一个可用的沮丧的button即可。

所以,我想知道什么好的做法,你可以推荐帮助用户实际阅读你的错误信息,而不是简单地放弃一边。 我能想到的想法会落在以下几点:

  • 格式化当然有帮助; 也许是一个简单的短消息,带有“了解更多”button,导致更长,更详细的错误消息
  • 将所有错误消息链接到用户指南的某个部分(有点难以实现)
  • 只是不要发出错误信息,只是拒绝执行任务(一种有点“苹果”的处理用户input的方式)

编辑:我想到的观众是一个相当广泛的用户群,不太频繁地使用软件,不是俘虏(即没有内部软件或狭窄的社区)。 这个问题的一个更通用的forms被问到slashdot ,所以你可能想检查一些答案。

这是一个值得我从+1的优秀问题。 这个问题尽pipe很简单,涵盖了最终用户性质的许多方面。 这归结于许多因素,这些因素会使您和软件本身受益,当然也有利于最终用户。

  • 不要在状态栏中放置错误信息 – 尽pipe有颜色等等,他们将永远不会读取它们….他们总是会错过它们! 不pipe你有多努力,都会尝试…在Win 95 UItesting开始之前的一个阶段,MS进行了一个实验来阅读UI( 编辑 – 应该注意的是,这个消息在“看在椅子下面 ),一张100美元的钞票贴在椅子的下面,表示对象正坐在…没有人在状态栏中发现消息!
  • 使信息简短,不要使用吓唬的话,如“警报:系统遇到问题”,最终用户将打到恐慌button,将过度反应…
  • 不pipe你怎么努力,都不要用颜色去识别这个信息……心理上,这就像是给公牛挥动一面红旗!
  • 使用中立的声音来传达最小的反应,以及如何进行!
  • 最好是显示一个列出中性错误信息的对话框,并在最后一个用户想要的最后一个工作内容中join一个checkbox,指示“您是否希望将来会看到更多这些错误信息?”在popup消息的软件的中间,他们会感到沮丧,并将被closures的应用程序! 如果勾选了checkbox,请将其logging到文件中。
  • 让最终用户了解将会出现什么样的错误信息……这意味着……培训和文档logging……现在,这是一个棘手的问题……你不希望他们认为会有是“问题”还是“小故障”,以及如果发生这种情况……他们一定不知道会有可能的错误,确实是棘手的。
  • 总是,不要在平安的时候要求反馈 – 比如“当错误号1304出现了,你是怎么反应的? 你的解释是什么? – 这个奖金,最终用户可能会给你一个更为一致的解释,而不是'错误1304,数据库对象丢失',而不是他们可以说'我点击这个那么有人不小心把机器的网线拔了,这样就会提示你不得不处理这个问题,并且可能会修改错误,说出“Ooops,networking连接断开”……你得到了漂移。
  • 最后但并非最不重要的一点,如果你想瞄准国际观众,考虑到国际化的错误信息 – 因此,这就是为什么保持中立,因为这样会更容易翻译,避免同义词,俚语等,这将使翻译毫无意义 – 例如,汽车公司菲亚特·福特( Fiat Ford)出售他们的品牌菲亚特·福特·平托( Fiat Ford Pinto),但注意到南美没有销售,结果是,平托是一个“小阴茎”的俚语,因此没有销售…
  • ed )在标题为“错误消息”或“纠正措施”或类似文档的单独章节中logging预期的错误消息列表,并按照正确的顺序列出错误编号,并附上关于如何继续的声明。 ..
  • ed )感谢Victor Hurdugaci的投入,保持信息的礼貌,不要让最终用户感到愚蠢。 这与杰克·马尔凯蒂Jack Marchetti)的回答相反,如果用户群是国际的话。

编辑:感谢gnibbler谁提到另一个极其重要的一点特别的话!

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

编辑#2:我的不好! 哎呀,感谢DanM提到的那辆车,我把名字弄混了,那是Ford Pinto …我的坏…

编辑#3: ed已经突出显示加法或加法,并记入他人的input…

编辑#4:回应肯的评论 – 这是我的采取…不,它不是,使用中性标准的Windows颜色…不要去浮华的颜色! 坚持正常的灰色背黑色文本,这是微软规范中的常规标准GUI指南。参见用户体验指南 ( 编者 )。

如果你坚持浮华的色彩,至less要考虑到潜在的色盲用户,即残疾人的另一个重要因素 ,屏幕放大友好的错误信息,色盲,遭受白化病的人,他们可能对浮华的颜色敏感,癫痫也可能会受到特定颜色的刺激

向他们显示消息。 尽职尽责,但将每个错误logging到一个文件中。 用户不记得他们在做什么,或者事件发生后几秒钟的错误信息,就像是看pipe人员的目击者账户。

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

简短的回答:你不能。

简短的回答:让他们可见,相关和上下文(突出显示他们搞砸了)。 但是,你仍然在战斗中失败。 人们不会在计算机屏幕上阅读,他们会扫描,并且他们已经被训练去点击button,直到对话框消失。

我们把一个简单的令人难忘的graphics放在错误框中:不是一个图标,一个相当大的位图,没有像标准的Windows消息图标。 没有人能够记得一个消息框的措辞(如果框中有一个“确定”button,大多数人甚至不会阅读它),但大多数人都记得他们看到的图片。 所以我们的支持人员可以问客户:“你见过喝咖啡的人吗? 或者“你看到空桌子了吗?” 至less我们知道大概出了什么问题。

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

例如,我写了一个应用程序,让我们的人力资源人员更好地跟踪员工的雇佣/雇佣date。 [我们是一个小公司,非常悠闲]。

当他们input错误的date时,我会写:

嘿哑巴屁股,学习如何inputdate!

编辑:当然更有用的消息是说:“请inputdate为mm / dd / yyyy”,或者在代码中试图找出他们input的内容,如果他们input“blahblah”显示错误。 但是,对于我个人认识的人力资源人员来说,这是一个非常小的申请。 因此,再次的人,阅读这篇文章的第一行: 根据您的用户群…

我最近在一个艺术学院的项目上工作,所以错误信息是面向观众的,比如:

巴洛克时代之前的大部分艺术作品都没有签名。 但是,现在我们已经超越了巴洛克时代,所有的领域都必须完成。

如果可能的话,基本上要把它传达给你的听众,并避免所有非常普遍的错误,例如:“请input电子邮件”或“请input有效的电子邮件”。

警报/popup窗口很烦人,这就是为什么每个人都击中他们看到的第一个button。

让它less烦人 。 例如:如果用户错误地input了date,或者input了一个需要数字的文本,那么不要popup一条消息,只需突出显示该字段并在其周围写入消息。

制作自定义消息框 。 永远不要使用系统的默认消息框,例如Windows XP消息框自己讨厌。 创build一个新的彩色消息框,使用与系统默认不同的背景颜色。

非常重要:不要坚持 。 有些消息框使用modal dialog,并坚持让你阅读它,这是非常烦人的。 如果您可以使消息框显示为警告消息,则会更好,例如,显示在页面顶部的堆栈溢出消息,通知但不会令人讨厌。

UPDATE
使信息有意义且有帮助 。 例如,不要写下类似“找不到键盘,按F1继续”。

最好的UIdevise将是你几乎从不显示错误信息的地方。 软件应该适应用户。 有了这样的devise,错误信息将是新颖的,将吸引用户的关注。 如果你用这样的无意义的对话来胡说用户,你明确地训练他们忽略你的信息。

在我看来,经验是那些不阅读错误信息的高级用户。 我认识的非技术类读者最仔细地阅读屏幕上的每一条消息,这个问题大部分是:他们不理解。

这一点可能是你的经验的原因,因为在某些时候,他们将停止阅读,因为“他们不明白它”,所以你的任务很容易:

使错误信息尽可能容易理解,并将技术部分置于隐蔽之中。

例如,我传递一个消息,像这样:

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

像这样的东西:

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

向用户显示错误信息有意义 ,这是向他们提供帮助的一种方式,他们会阅读它。 如果这只是行话或一般的无意义的消息,他们将学习,消除他们quicly。

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

这也是一个很好的学习工具。 在将来的版本中,您可以解决已知问题,或至less提供就地解决方法信息。 在此之前用户将会知道这个消息是由X引起的,这个问题可以通过Y来解决,因为有人向他们解释了这个问题。

当然这不适用于大规模的应用程序,但对于几百个用户的企业应用程序来说效果很好,而且在精益敏捷的情况下,经常会发布早期版本的环境。

编辑:

由于你有广泛的用户基础,我build议提供软件,做用户可以/期望它做的,例如。 如果电话号码格式不正确,请不要显示他们的错误信息,请重新格式化。

我个人喜欢软件, 不会让我思考 ,偶尔也没有什么(开发人员)能够解释我的意图,提供一个写得很好(并由实际用户审阅)的消息。

众所周知, 人们不会阅读文档 (当你插入家用电器时,你是否连续阅读指令?),他们尝试一种方式来快速获得结果,当失败时你必须抓住他们的注意力(例如,禁用默认button一段时间)与有意义有用的信息。 他们不关心你的软件失败,他们现在想要得到结果。

让他们开心 。 (这似乎是相关的,给我们的网站:))

要开始,写入用户可以真正理解的错误消息。 “错误:1023”不是很好的例子。 我认为更好的方法是logging错误,而不是用一些“奇特”的代码向用户显示。 或者如果不能logging日志,请给用户正确的方式将错误详细信息发送给支持部门。

另外,要简短明了。 不要包含一些技术细节。 不要向他们展示他们不能使用的信息。 如果可能的话,为错误提供解决方法。 如果不提供默认路由,则应该采取。

如果您的应用程序是一个Web应用程序,devise自定义错误页面是一个好主意。 他们比较less强调用户,以SO为例。 你可以得到一些想法如何在这里devise一个好的错误页面: http : //www.smashingmagazine.com/2007/07/25/wanted-your-404-error-pages/

有一件事我想补充。

使用动词作为你的动作button来closures你的错误信息,而不是感叹号,例如不要使用“OK”。 “closures”等

我学到的一个好的提示是,你应该写一个像报纸文章的对话框。 不在规模意义上,而是在重要意义上。 让我解释。

你应该写最重要的东西来阅读,第一,并提供更详细的信息第二。

换句话说,这是不好的:

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的用户在这里的回应。

除非你能提供给用户一些简单的解决方法,否则不要麻烦向用户显示错误信息。 没有意义,因为90%的用户不会在乎它说什么。

另一方面如果你真的可以向用户显示一个有用的解决方法,那么强制他们读取它的一种方法是在10秒左右之后使“确定”button变为可用。 当你试图安装一个新的插件的时候,Firefox会怎么做。

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

对不起,我们搞砸了,我们想发一些关于这次事故的信息,你能让我们这样做吗?是/否

另外,尽量不要让错误信息比一个句子长。 当人们(包括我在内)看到一整段关于错误的话题时,我的思绪就会closures。

有了这么多的社交媒体和信息超载,当人们看到一堵文字的时候,心灵就会冻结。

编辑:

最近也有人build议使用连环画以及任何想要展示的信息。 比如说从迪尔伯特那里得到的东西可能接近你可能有的错误types。

根据我的经验:您不会让用户(尤其是非技术用户)阅读错误消息。 不pipe大家多么清楚,可以理解,大胆,红色和闪烁的信息,大多数用户只会点击他们不习惯的任何东西,即使是“你真的要删除所有东西吗?”。 我看到用户点击“窗口closures”图标,而不是“确定”或“取消”,即使他们甚至不知道他们select了哪个选项…

如果你真的需要强制用户阅读你所显示的内容,我会build议一个JavaScript的倒计时,直到一个button是可点击的。 这样用户将希望利用等待时间来真正阅读他应该的。 但要小心:大多数用户会更加恼火:)

我还喜欢你的“阅读更多”链接的想法,虽然我怀疑是否会让用户更感兴趣,只是想通过一切手段摆脱消息…

只是为了logging:有些用户可以阅读错误信息,但是很害怕,他们不会做任何事情。 我曾经有一个支持电话,客户会给我看一个错误信息,问我,他该怎么做。 “那么,你有什么select?”我问。 “窗户只有一个'OK'button。”他回答。 … mmh,很难:)

我经常以红色显示错误(当devise允许的时候)。

红色代表“警惕”等,所以更经常阅读。

那么,直接回答你的问题:不要让你的程序员写错误信息。 如果遵循这一条build议,那么累计可以节省数千小时的用户焦虑和生产力,以及数百万美元的技术支持成本。

但是,真正的目标应该是devise你的应用程序,以便用户不会犯错误。 不要让他们采取导致错误按摩的行为,并要求他们备份。 作为一个简单的例子,在一个web表单中,需要填写所有的字段,而不是在用户点击发送button时popup一个错误消息,直到所有的字段都包含有效的内容为止,不要启用发送button。 这意味着更多的背面工作,但它会带来更好的用户体验。

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

一个好的错误信息应该包含:

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

你可以做的最糟糕的事情之一就是将系统错误消息传递给用户。 例如,当您的Java程序引发exception时,不要简单地将程序员传递给UI,并将其暴露给用户。 抓住它,并有一个清晰的信息,由您的用户协助开发人员,您可以提供给您的用户。

在我上一份工作中,我很幸运能够和一个不想写自己的错误信息的程序员一起工作。 任何时候,他们发现自己处于一个需要的地方,程序不能被devise为避免(通常是因为资源有限),他们总是来找我,解释他们需要什么,让我创build一个错误信息,清晰,遵循公司风格。 如果这是每个程序员的默认思维模式,计算世界将是一个更好的地方。

更less的错误

如果一个应用程序会定期向你吐吐,你就会免疫,并且错误会变成恼人的背景muzak。 如果一个错误是一个罕见的事件,它将获得更多的关注。

反问任何不重要的事情,抛弃所有的警告,find理解用户意图的方法,尽可能地去做出决定。 我有几个应用程序,我继续这样简化。 开发人员将每个错误视为重要,但从用户的angular度来看这不是事实。 寻找用户对问题的共同回应,并捕获问题,并将其作为您的回应进行部署。

如果你确实需要提出一个错误:简短,简洁,低的恐怖因素,没有感叹号。 段落失败

没有银弹,但是你需要社交工程师来使错误变得重要。

我们告诉用户他们的经理已经联系了(这是一个谎言)。 它工作得太好了,不得不被删除。

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

我build议你在发现错误后立即给出反馈(说明用户犯了错误)。 (例如,inputdate字段的值时,请检查该值,如果错误,则使input字段在视觉上不同)。

如果页面上有错误(我更多的是网页开发,所以我把它称为“页面”,但也可以称为“窗体”),显示“错误摘要”,解释那里是错误和错误列表,究竟发生了什么错误。 但是,如果每封邮件的字数超过5至6个,则不会被读取/理解。

如何使button状态“点击这里与支持技术人员谁将会帮助你解决这个问题。

有许多网站提供与真人对话的选项。

我读了一个关于slashdot最可怕的解决scheme的候选人:

我们发现让用户对错误负责的唯一方法就是让错误消失。 对于初学者来说,在可能的情况下,除非我们inputpipe理员密码使其消失,否则错误将不会实际closures,如果他们重新启动以排除此错误(所有客户端计算机上的任务pipe理器都被禁用),计算机将无法打开应用程序崩溃了15分钟。 当然,这一切都取决于你正在处理的用户types,因为更多的技术熟练的用户不会接受这种系统,但在尝试从字面上的年份,让用户负责崩溃,并确保IT部门了解他们为了解决这个难题之前难以pipe理的问题,这些是唯一的工作步骤。 现在,我们所有的最终用户都知道,如果他们忽视错误,他们自己就会受苦。

“注意!注意!如果你不读错误信息,你会死!

尽pipe接受的答案中有所有的build议,我的用户继续点击他们可以find的第一个button。 所以现在我展示这个:

读这个!

用户必须在OKbutton出现之前做出select

选择正确的选项

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