本文翻译自 Hostile Patterns in Error Messages,主要是介绍错误信息展示的 UI 设计原则。过早显示的错误信息、过于激进样式的字段以及不必要的干扰性系统状态信息,都会让用户感到不礼貌,并在本应简单的任务中增加认知负担。
没有人愿意犯错 —— 无论是在生活中还是在使用应用程序或浏览网站时。犯错是生活中自然而然的一部分,尽管在错误中能汲取经验教训,但它也可能造成损害,导致繁琐的额外工作,甚至让人因为不知道如何正确完成某件事而感到慌乱或羞愧。
因此,Jakob Nielsen 在十大可用性原则中有两条是专门针对错误的:
原则5:错误预防 该原则指出,我们应该通过消除容易出错的条件或在用户执行具有严重后果的操作之前提供确认选项,来防止问题的发生。
原则9:帮助用户识别、诊断和恢复错误 错误信息应以通俗易懂的语言表达,清楚地说明问题并提供解决方案,同时使用视觉样式帮助用户注意到它们。
在设计数字体验时,优先考虑错误预防和恢复是一种值得称赞且有价值的策略。然而,一些试图遵循这些原则的好心设计却可能做得过头,给用户带来过于激进的模式,这些模式不仅没有帮助,反而令人沮丧和分心。
通过遵循以下两条准则,可以避免过于激进的错误预防和恢复模式:
本文提供了避免这些陷阱的示例和指导原则。
过早显示的错误信息是指系统在用户尚未真正犯错或未达到工作流程中的合理节点之前,就提前显示的错误信息。
以用户填写表单为例——这是许多网站和应用程序中的常见任务。在技术条件允许的情况下,最好在用户犯错时实时告知他们表单中的错误。然而,许多表单验证机制过于冲动,在用户尚未完成填写字段之前就显示错误信息。
一个典型的例子是,当系统在用户尚未完成输入符合预定正确格式的值时,就显示错误信息。例如,用户在电话号码字段中输入“2”时不应触发错误信息;而在电话号码字段中输入字母时显示错误信息则是合理的。
例如,LG的结账流程在用户开始在邮政编码字段中输入数字时,就立即显示错误信息,并一直保持该错误信息,直到输入的字符数达到预定格式。虽然将错误信息内联显示(在相关字段旁边)是有用的,但错误信息本身是不必要的:用户并未犯错。(更糟糕的是,表单底部还会触发并显示第二条冗余的错误信息。)
Labcorp(一家医疗账单公司)在其支付门户上使用了类似的模式。一旦在电子邮件地址字段中输入字母,错误信息“无效的电子邮件地址”就会立即弹出,给用户带来不必要的干扰。
另一个例子是,在 Sorel 的结账过程中,尝试填写出生日期信息时会触发内联错误信息“请输入有效日期”。
一般来说,避免在用户完成字段输入并移至下一个字段之前显示错误信息。在用户输入时显示错误信息会让人感觉像是无端的责备,可能会引起用户的反感。
更令人沮丧的一种过早内联验证是,错误信息在用户甚至尚未开始输入时就出现。这种错误信息要么在用户点击字段时立即触发,要么更糟糕的是,在表单的默认状态下就已经显示出来。在这些情况下,用户甚至没有机会开始填写字段就被警告了。
在 Conradnewyork.com 酒店的预订过程中,点击“姓氏”字段会导致字段被红色边框包围,并触发内联错误信息“请输入姓氏”。如果用户跳过该字段并尝试提交表单,这些错误提示是有用的,但它们不应仅仅因为点击字段而触发。(更糟糕的是,所有字段在用户与之交互之前都显示“可选”字样,即使是显示内联错误信息的“姓氏”字段也是如此。)
在更为激进的设计中,Xpress-pay 患者支付门户在用户甚至尚未与字段交互时,就显示错误信息“金额不能为空”。此外,除了错误信息外,还有三个冗余的指示器表明“金额”字段是必填的:字段标签旁的星号、字段最右侧的感叹号图标以及字段本身的红色粗边框。
当然,在任何表单中,我们建议明确传达哪些字段是必填的 —— 但通常一个星号就足够了。提供冗余或过于激进样式的必填字段指示器毫无意义,反而会让人感到对抗性。内联错误信息 “金额不能为空” 如果是在用户尝试提交未填写必填字段的表单后显示,则是有用的。过早显示则显得过度,甚至令人厌烦。
另一种激进的设计模式是在未发生错误的情况下使用类似错误的视觉处理。
一种情况是对非关键的系统状态信息使用更适合警告和错误的视觉处理。
关键错误信息和警告应具有侵入性。当错误显示时,用户可能正在专注于当前任务,而不是考虑错误,因此错误信息应足够引人注目,以引起用户的注意。因此,使用侵入性的错误样式(例如红色文字、警告符号等)是合理的。
但传达非关键信息的常规系统状态信息不应具有侵入性。它们应易于发现,但不应该打扰用户。
在以下的人力资源应用程序中,信息“没有附件可显示”被设计得像一个警告。由于黄色的视觉处理和警告符号,这条信息看起来比实际更重要。遇到此消息的用户会被打断,停下来思考“是否应该有附件?”(因为在这种情况下上传附件是可选的,答案是:无所谓。)
黄色和警告图标(例如三角形中的感叹号)最好保留用于警告,即在发生或可能发生故障或重大变化但尚未或不会造成不可逆转损害的情况下使用。例如,Amazon Glow 应用程序适当地使用黄色警告图标来通知用户通话失败。
Amazon Glow 的移动应用程序 使用黄色警告图标来指示通话失败
另一个例子是,在在线书店 Thrift Books 的结账过程中,点击“账单地址”下的任何表单字段都会触发信息“请确保您的地址正确,订单提交后无法更改”。虽然这条信息是有用的,但红色的视觉处理和警告符号使其看起来像一条错误信息。用户必须停下来处理这条信息,仔细检查是否发生了错误,而实际上没有任何需要修复的地方。此外,这条信息还引发了疑问:为什么地址不能更改?(这违反了错误恢复的原则。)
与此类似的非错误相关信息最好避免使用类似错误的视觉处理。例如,在 Paypal 的移动应用程序中,类似的信息使用灰色背景和信息图标(圆圈中的小写字母“i”)来显示,而不是红色字体或背景。
这些激进的错误预防和恢复策略,就仿佛是站在用户身后对用户大喊 “你做错了!”。它们会让用户感到被冒犯,并引起用户不必要的挫败感。
我们应该帮助用户,而不是责备他们。
遵循以下准则,可以有效支持错误预防和恢复,而不会让用户感到被攻击或羞愧:
等到用户离开字段后再显示与格式相关的错误信息,(例如邮政编码、电子邮件地址)。
提供约束条件,不要等到用户开始输入或尝试提交时才告知。
使用星号标记必填字段,或用“必填”字样注释, 不要用多个指示器(例如星号、红色边框和内联验证信息)让用户感到负担。仅在用户尝试提交未填写必填字段的表单或页面后,才显示额外的元素。
保留用于错误的视觉处理(例如红色文字、警告符号),用于中断用户的关键系统状态信息。