2025上半年,最新 AI实践都在这!20+ 应用案例,任听一场议题就值回票价 了解详情
写点什么

如何编写有用的错误消息?

  • 2021-07-20
  • 本文字数:3176 字

    阅读完需:约 10 分钟

如何编写有用的错误消息?

错误消息的领域涉及很多方面的内容。它们需要将 UX 领域的几乎所有元素(信息、说明、界面、微文案)结合起来,并且用几句话将这些信息阐述清楚。所有这些元素都是为了一个共同的目标:在出现问题时帮助用户



错误消息需要快速、清晰地通知、指导和引导用户


但上面的说法还是太简单了,因为错误消息还需要包含以下内容:


  • 你的站点或系统的结构:用户和开发人员都不希望看到无穷无尽、含义各异的文本字符。所以你需要考虑为之编写错误消息的系统上下文。你需要找出系统的所有需求和约束,然后尽可能让错误逻辑保持简单和一致。

  • 整体体验:从现有的设计模式中汲取灵感,或共同打造一个新的设计模式来满足设计和内容需求。用户都喜欢熟悉的内容,并且重用各种语言模式就像重用各种设计模式一样会让大家都很满意。

  • 品牌和产品:消息应该反映你的品牌或产品的声音和基调,这些内容还要同上下文和用户心态保持平衡。


那么,如何编写对所有人和用户都有帮助的错误消息呢?你该从哪里入手?

(先)不要写任何东西!


什么都不管就开始打字是很诱人的做法。你觉得你的大脑每次只会应付一条消息,因此每个错误都能写出完美、井井有条的消息!


听起来很棒?但情况并非总是如此。


如果你正在开发一个新的网站、工具或系统,你需要写很多错误消息才行。如果你要添加一条消息,那么同类的消息可能已经有好几条了。


利益相关者也有很多:设计师、开发人员、品牌人员,他们都希望看到精心设计、保持一致的错误处理方法。


用户需要在他们遇到问题时获得错误消息的帮助——所以这些消息最好是有用的。


因此,与其“编写”错误消息,不如考虑“构建”消息。

打下坚实的基础


如果你正在创建一个全新的网站、工具或系统,请召集整个团队,共同列出所有可能出错的事情,例如:


  • 可能提交错误信息的人

  • 将用户引向不存在页面的损坏链接

  • 系统整个崩溃,没有任何解释


然后,开始对它们分组——你的分组方法将取决于你所开发的产品,这里有一些例子:


  • 系统和网络

  • 字段和输入

  • “你不能那样做”


现在将这些事件按照令人困惑(frustrating)、烦人(annoying)到令人生气(infuriating)的级别分类。这一部分引用了 Deliveroo 的内容设计团队的理念,他们也写了一篇关于错误消息的出色文章


在下面这个分类图上,到了某一点后,错误就会阻止用户会话继续进行下去。用户或系统都无法修复它。他们的关键路径被打乱了。



将这些事件分组后,你就更容易设计出一致的模式。按严重程度排名可以帮助你表达正确的语气。

构造错误消息


一旦你构建了一些基础,你就可以给你的错误消息建立一些结构。这样,所有错误消息就都会保持一致,永远都不会过于冗长。

你应该问自己三个关键问题:


  1. 谁触发了错误?

  2. 用户:如果是用户导致了错误,比如输错了电子邮件地址,那就不要道歉。这时候道歉只会花费用户更多的时间和精力来阅读和处理,时间是很宝贵的。

  3. 系统:如果是我们的错,那就说声“对不起”。

  4. 我们知道是什么原因造成的吗?

  5. 是:解释发生了什么,或者为什么有些事情不起作用。

  6. 否:如果我们不知道出了什么问题,请承认并告诉他们。向他们保证我们正在努力修复问题。

  7. 我们可以现在就修复吗?

  8. 是的,我们可以:解决问题,并告诉他们你正在做什么以提供帮助

  9. 是的,用户可以:给他们明确的指示来引导他们解决问题

  10. 否:如果没法继续下去,请提供最佳建议或引导他们后退一步重试。只有在有用的情况下才将人们带到帮助文档或实时/web 对话中。



使用一系列问题和构建块构建你自己的错误消息

让错误消息自行生成


一旦你有了一个定义好的结构,你就有了一个很好的公式-构建块组合来构建用户可能遇到的所有错误消息。


你现在可以按这样的结构来编写错误消息:


[解释] [指导]


[道歉] [解释] [解决]


或者在非常糟糕的情况下:


[道歉] [承认,安抚] [引导他们回来]



在密码框中,用户可能忘记了正确密码。因此你需要创建第二个循环,并提供让用户重回正轨的流程。


这样做可以让句子结构保持简单、清晰和一致,这对大家都有好处。


用户会感到更加熟悉并更快地处理它们。设计师可以正确地预估消息内容的间距和设计模式。开发人员也可以开始构建逻辑和字段验证可能需要的细节级别。

收尾工作


所以,现在你知道了你的错误消息需要满足哪些要求,那么我们的消息具体应该说什么呢?


我们可以在构建块中加入其他一些内容,比如:


  • 错误对用户来说是多么烦人,多么令人头疼

  • 你的品牌声音和基调,可能需要根据品牌调性来调整具体内容

  • 上下文,例如设计和开发需求

选对说法


首先,你的错误信息应该一直都是清晰准确的。它应该听起来很人性化,并且只使用你日常对话中会用到的词汇。



“无法连接”听起来不像“未检测到互联网连接”那么机械,虽然它们说的是同样的事情。


你的产品还应该具有一致的个性或声音。一些品牌(例如私人银行)的声音听起来更正式,因为这种正式感能让用户感到自己的资金更加安全可靠。而其他一些品牌(如时尚、游戏或运动行业)则可能更健谈、不拘礼节,甚至随性。


你的错误消息都应该符合你的品牌声音调性。错误消息应该考虑到受众身份,以及他们为什么、何时使用你的产品。

打出正确的语气


当品牌声音固定下来以后,你的语气需要和不同的错误情况相适应。


如果错误很小,例如用户输入了错误的电子邮件地址,你的语气就可以比较随意,同时让人感到你正在提供帮助。如果你的品牌声音允许的话,你还可以加入一些温暖或幽默的语气。但这些调整不应该让你的信息更难理解。


如果错误真的很糟糕,比如有人被锁定在他们的帐户之外,那么现在你的语气就应该变得更加诚恳、更让人感受到帮助了。


你应该理解用户所处的位置,以及他们为了解决问题需要付出的努力。你的帐户恢复流程可能短暂而甜蜜。但是你的用户还是被锁定在他们的帐户之外了,这终归是给人压力的。



采取更直接的方法:“你需要恢复你的帐户”而不是“哎呀,你被锁定了!”,但告诉用户“我们随时为你提供帮助。”

平衡精度与一致性


在一个简单的表单上(比如用户注册页面),你需要考虑一些最常见的错误。你或许可以为用户提供更具体的指导,例如提醒他们密码始终应该包含数字,或者电子邮件地址始终应该包含“@”。


通过与设计师、开发人员和团队其他成员的紧密合作,你甚至可以提前阻止一些错误的发生!



如果你能提前同团队合作设计验证字段,就可以预防一些错误并改善整体用户体验。


但如果你正在处理一个大型表单,你可能无法涵盖所有​​类型的字段验证,因为这样会很难构建和维护。


如果是这种情况,请系统地应对问题。将字段类型分组,定义最常见的错误,看看是否可以将字段标签插入可重用的响应来生成错误消息。比如说:


  • 输入[字段标签]

  • 选择一个选项



一些更简单、全面的错误消息示例,它们平衡了技术限制和实用性,例如“选择一个选项”和“输入[字段标签]”。

写出好的消息的原则


根据项目的不同,你可能需要调整其中的一些想法。


它们并不是解决问题的一刀切原则。不同的情况需要不同的细节水平。需要根据用户测试和数据的情况来调整细节水平。


但是你可以遵循一些很好的原则,它们可以帮助你写出很出色的错误消息:


  • 使用通俗易懂的语言:写出你会大声念出来的句子和单词

  • 分解长句:两个短而清晰的句子比一个长句好

  • 使用主动语态:应该说“输入你的姓名”,而不是“未输入姓名”

  • 修剪不必要的词:“请”往往是累赘的单字

  • 避免责怪用户:不要说“你没有输入你的电子邮件地址”,而是让他们“输入一个电子邮件地址”

总结


错误消息可能写起来很让人头疼。仅仅几句话就可以决定用户体验的成败。只要能系统地构建错误消息,你就可以让消息内容清晰、富有建设性。这种系统方法可以防止消息内容跑偏或者太过宽泛,也能维持一大堆消息的一致性。


一套合理正确的编写流程有助于实现更简洁的设计、更精简的代码,带来更快乐的用户。所以你的重点不应该放在具体的编写上。首先建立你的基础,定义一个结构,然后再慢慢装点它们吧。


原文链接:


https://www.bbc.co.uk/gel/guidelines/how-to-write-useful-error-messages

2021-07-20 14:001452
用户头像
王强 技术是文明进步的力量

发布了 878 篇内容, 共 500.2 次阅读, 收获喜欢 1784 次。

关注

评论

发布
暂无评论
发现更多内容

Flink Hudi 0.10.0 发布,多项重要更新,稳定性大幅提升

Apache Flink

大数据 flink 编程 数据湖 Hudi

Gitee 如何自动部署 Pages?还是用 GitHub Actions!

冴羽

GitHub 前端 GitHub Pages gitee vuepress

王者荣耀异地多活架构设计

Beyond Ryan

GrowingIO Reactor速成指南

GrowingIO技术专栏

响应式编程 reactor

如何正确的重写hashcode()

李子捌

Java 28天写作 12月日更

架构实战营第 4 期 -- 模块三作业

烈火干柴烛灭田边残月

架构实战营

电竞进入5G时代!腾讯云联合腾讯游戏CROS首秀5G电竞专网

科技热闻

优酷播放黑科技 | 基于WebRTC实现的直播“云多视角“技术解析

阿里巴巴终端技术

WebRTC 移动开发 直播技术 客户端

SIGCOMM 首篇 Multi-path QUIC 论文:阿里自研多路径传输技术XLINK

阿里巴巴终端技术

网络协议 传输协议 移动端 客户端 QUIC

如何推动区块链与物联网深度融合,赋能数字化转型?

CECBC

Python 的切片为什么不会索引越界?

Python猫

Python

从零到一,我也能写小程序

王字 Wannz

小程序 小程序市场 finclip 小程序框架

Flink CDC 系列 - 实时抽取 Oracle 数据,排雷和调优实践

Apache Flink

大数据 flink 编程 实时计算 CDC

如何看待制造企业的数字化转型,有哪些成功案例可以分享?

优秀

低代码 数字化转型 制造业

☕【Java深层系列】「技术盲区」让我们一起完全吃透针对于时间和日期相关的API指南

码界西柚

Java 工具 日期处理 12月日更

十二张图带你了解 Redis 的数据结构和对象系统

程序员历小冰

redis 数据结构 28天写作 12月日更

【MongoDB学习笔记】MongoDB 快速入门

恒生LIGHT云社区

数据库 mongodb

通过元宇宙远程上班有的搞吗?

王字 Wannz

虚拟现实 元宇宙 凡泰极客

基于HTML5/CSS/JS响应式圣诞老人过悬崖小游戏

海拥(haiyong.site)

28天写作 12月日更

EMQ & 轻流:全托管物联网消息服务助力海量设备低代码智联

EMQ映云科技

物联网 mqtt

怎样的活动才算是成功?(20/28)

赵新龙

28天写作

🏆【CI/CD技术专题】「Docker实战系列」(1)本地进行生成镜像以及标签Tag推送到DockerHub

码界西柚

Docker 容器镜像 12月日更 Dockerhub

CSS之变量

Augus

CSS 12月日更

开发者供不应求,传统企业如何拥抱 DevOps ?

飞算JavaAI开发助手

基于区块链的去中心化身份技术有哪些应用前景?

CECBC

NFT改变潮流,也在解放人类创造力的约束

CECBC

如何提高用户留存?

石云升

AARRR 产品思维 28天写作 产品增长 12月日更

浅谈前端角色权限方案

王字 Wannz

前端 权限控制 finclip

架构训练营 week3 作业

红莲疾风

「架构实战营」

在Vue-cli中使用mock.js

CRMEB

不要被数据蒙蔽你的眼睛

Geek_utwige

数据分析 统计学 辛普森悖论

如何编写有用的错误消息?_语言 & 开发_James Cleaver_InfoQ精选文章