错误消息设计 - 用户可理解的字数与表达方式
错误消息是用户遇到问题时系统显示的文本。这一瞬间的沟通如果恰当，用户就能解决问题并继续操作；如果不当，则会引发困惑和不满，导致用户流失。Nielsen Norman Group 的研究表明，用户平均只花 1.5 秒阅读错误消息，几乎所有的传达力都集中在前 5~7 个词上。本文将结合认知心理学和可用性研究的成果，系统讲解如何设计用户能理解的错误消息字数与表达方式。想系统学习错误消息设计基础的读者，了解细高跟鞋 (Amazon)也可作为参考。
错误消息的字数参考标准
错误消息太短则信息不足，太长则无人阅读。根据错误类型设定合适的字数至关重要。以下推荐字数综合考虑了显示场景 (内联、Toast、全屏) 和用户心理状态 (焦虑、困惑、不安) 两方面因素。
| 错误类型 | 推荐字数 | 示例 |
|---|---|---|
| 输入验证 | 15~40 字符 | 密码至少需要 8 个字符 |
| 操作错误 | 30~60 字符 | 文件上传失败，请选择 5MB 以下的文件 |
| 系统错误 | 40~80 字符 | 无法连接服务器，请稍后重试 |
| 404 页面 | 60~120 字符 | 未找到您要访问的页面，请检查 URL 或从首页重新查找 |
| 权限错误 | 30~60 字符 | 您没有执行此操作的权限，请联系管理员 |
| API 错误响应 | 30~120 字符 | 机器可读的错误代码 + 面向用户的消息组合 |
错误消息的基本结构是"发生了什么 + 该怎么做"两个要素。只告知原因而不提供解决方案的消息，会让用户不知所措。认知心理学研究表明，人在压力状态下能处理的信息量约降至正常水平的 60%。错误发生时的用户正处于这种状态，因此消息需要比普通文本更短，结构更清晰。
优秀错误消息的三大原则
能让用户理解的错误消息具有三个共同原则。这些原则直接对应尼尔森十大可用性启发式中的"帮助用户识别、诊断和恢复错误" (Help users recognize, diagnose, and recover from errors)。
- 用通俗语言说明发生了什么：避免技术术语，用用户能理解的语言传达情况。不要写"500 Internal Server Error"，而要写"服务器出现了问题"。从认知负荷理论的角度看，专业术语会增加外在认知负荷 (extraneous cognitive load)，占用本可用于解决问题的认知资源
- 简要说明原因：尽可能告知原因。例如"您输入的邮箱地址格式不正确"。提示原因有助于修正用户的心智模型 (对系统运作方式的内在理解)，防止同类错误再次发生
- 具体指引下一步操作：明确提供解决方案或下一步行动。例如"请输入包含 @ 的邮箱地址"。可用性研究表明，包含解决方案的错误消息可将任务完成率提升最高 50%
将这三个要素融入一条消息中，通常需要 40~80 个字符。不必将所有内容塞进一句话，分成 2~3 句以提高可读性也是有效的做法。
主要服务的错误消息设计模式
Google、Apple、Microsoft 三家公司分别采用不同的方法设计错误消息。分析各家的模式，可以为自身服务找到合适的设计方向。
| 服务 | 设计方针 | 特点 |
|---|---|---|
| 具体、行动导向 | 如"密码至少 8 个字符，需包含字母和数字"，具体列出要求，用户一目了然 | |
| Apple | 简洁、关注情感 | 如"无法连接"般简短，彻底避免责怪用户的表达。详细信息通过"了解更多"链接逐步展示 |
| Microsoft | 渐进式披露 | Windows 11 起在蓝屏上显示 QR 码，引导用户获取详细信息。兼顾技术人员和普通用户的双层结构 |
三者的共同点是都坚持"不责怪用户"和"提示下一步操作"。虽然表达风格各异，但将错误恢复性 (error recovery) 放在首位的态度是一致的。
错误消息的语气与风格
错误消息的语气应与服务整体的品牌形象保持一致。但无论采用何种语气，以下几点都应共同遵守。
- 不责怪用户：不要写"您的输入有误"，而要写"请确认输入内容"。根据心理学的归因理论，人们倾向于将失败原因归咎于外部。责怪用户的表达会引发防御反应，妨碍其专注于解决问题
- 不使用专业术语：不要写"认证令牌无效"，而要写"登录已过期，请重新登录"
- 避免模糊表达：仅显示"发生了错误"，用户无法知道该怎么做。直接显示 HTTP 状态码同样不妥
- 谨慎使用幽默：404 页面可以接受，但支付错误中则不合适。应根据错误的严重程度调整语气
错误消息的字数可以用字符计数器来确认，在保持简洁的同时确保必要信息不遗漏。
HTTP 状态码对应的错误消息设计
Web 应用中，需要根据 HTTP 状态码优化错误消息的内容和长度。状态码本质上是面向开发者的信息，面向用户时应传达情况和解决方案，而非代码本身。
| 状态码 | 面向用户的表达 | 推荐字数 | 设计要点 |
|---|---|---|---|
| 400 Bad Request | 输入内容有误 | 30~50 字符 | 具体指出哪项输入有问题 |
| 401 Unauthorized | 需要登录 | 20~40 字符 | 提供登录页面的直接链接 |
| 403 Forbidden | 没有访问权限 | 30~50 字符 | 指引获取权限的方法 |
| 404 Not Found | 页面未找到 | 60~120 字符 | 提供搜索功能或首页导航 |
| 408 Request Timeout | 连接超时 | 30~60 字符 | 提示检查网络并重试 |
| 429 Too Many Requests | 请求过于频繁 | 30~50 字符 | 提示预计等待时间 |
| 500 Internal Server Error | 服务器出现问题 | 40~80 字符 | 告知恢复预期和替代方案 |
| 503 Service Unavailable | 正在维护中 | 40~80 字符 | 尽可能明确恢复时间 |
需要注意安全方面的考量。如果向用户明确区分 401 和 403，攻击者可能借此判断已认证用户或资源是否存在。在登录页面应使用"邮箱地址或密码不正确"这样无法确定具体哪项有误的表达。
表单验证的最佳实践
表单输入的验证消息是用户最常看到的错误消息类型。采用实时验证 (输入过程中即时反馈) 可以大幅提升用户体验。
验证消息应控制在 15~40 个字符以内。由于显示在表单字段附近，过长的消息会破坏布局。应使用"必填项""请输入 8 个字符以上""请输入有效的邮箱地址"等具体而简洁的表达。
验证的显示时机也需要注意。如果在字段获得焦点的瞬间就显示错误，用户还没开始输入就会感觉被批评了。推荐在字段失去焦点时 (blur 事件) 执行验证。不过，对于密码强度等实时反馈有益的场景，输入过程中显示也是有效的。
成功状态的反馈也不要忘记设计。输入正确时显示对勾或绿色边框，用户就能安心地进入下一个字段。不要仅依赖颜色，应同时使用图标或文字，确保色觉多样性的用户也能获取信息。
Toast 通知与内联显示的使用场景
错误消息的显示方式需要根据错误的性质来区分。以下整理了主要的显示模式及其适用场景。
| 显示方式 | 适用场景 | 注意事项 |
|---|---|---|
| 内联显示 | 表单验证、与输入字段关联的错误 | 显示在出错字段的正下方。需要滚动时应自动滚动到相应位置 |
| Toast / Snackbar | 临时通知 (保存成功、连接断开)、不希望中断用户操作的场景 | 3~5 秒后自动消失，因此应控制在 40~80 字符以内。不要用于重要错误 |
| 模态对话框 | 数据丢失警告、不可逆操作的确认 | 会完全阻断用户操作，应仅限于真正重要的场景 |
| 横幅 / 警告栏 | 影响整个系统的故障、维护通知 | 固定显示在页面顶部，并提供关闭按钮 |
屏幕阅读器的适配也很重要。动态显示的错误消息应设置 role="alert" 或 aria-live="assertive"，确保不依赖视觉的用户也能立即感知错误的发生。Toast 通知等自动消失的消息可能在屏幕阅读器朗读之前就消失了，因此重要错误应优先使用内联显示。
系统错误与 404 页面的设计
系统错误和 404 页面是用户最感到不安的场景。这些场景下的消息设计是防止用户流失的最后防线。
404 页面除了 60~120 字符的消息外，还应提供首页链接、搜索功能和热门页面链接。务必为用户准备到达目标信息的替代途径。优秀的 404 页面不是"死胡同"，而是"分岔路口"。
系统错误 (500 系列) 中，传达恢复预期和替代方案至关重要。像"系统正在维护中，请 30 分钟后重试"这样给出具体时间，可以减轻用户的不安。根据心理学的不确定性规避原则，"请 30 分钟后重试"比"请稍后再试"能大幅降低用户的压力。
移动端由于屏幕尺寸限制，错误消息设计需要额外考量。在 320px 宽的智能手机上，内联验证消息如果折行超过 2 行，会破坏整个表单的布局。移动端应以 15~25 个字符为目标，详细信息通过"了解更多"链接渐进式展示。
关于错误消息的冷知识
Windows 的"蓝屏" (BSOD) 被认为是世界上最多人见过的错误消息。Microsoft 从 Windows 8 开始，将技术性错误代码替换为悲伤表情的表情符号 ":("。Windows 11 更进一步，添加了 QR 码引导用户前往支持页面。这标志着错误消息设计从"用技术术语说明"到"用情感共鸣引导下一步操作"的转折点。
GitHub 的 404 页面"This is not the web page you are looking for" (星球大战的戏仿) 是在错误页面中融入幽默的经典成功案例。而 Amazon 的 404 页面则显示狗的照片，营造品牌的亲和力。不过，幽默仅适用于 404 页面等"非致命性错误"，在支付错误或数据丢失的错误中则不合适。
关于 HTTP 404 状态码的由来众说纷纭。最著名的说法是 CERN 的 404 号办公室里放着第一台 Web 服务器，但实际上 HTTP 状态码是在 1992 年系统性定义的，400 系列被设计为表示客户端错误的类别。
为什么不同错误类型的字数不同
错误消息的最佳长度由三个因素决定：用户的情绪状态、问题的复杂程度和显示区域。
输入验证 (15~40 字符) 之所以短，是因为它显示在表单字段下方，过长的消息会破坏布局。而且用户在填写表单时处于"心流状态"，长消息会打断这种专注。另一方面，404 页面 (60~120 字符) 之所以较长，是因为有整个页面的空间来展示替代方案 (首页链接、搜索功能)。
系统错误 (40~80 字符) 需要包含"发生了什么""何时恢复""有无替代方案"三个要素，容纳这些信息至少需要 40 个字符。超过 80 个字符，处于恐慌状态的用户就难以读完，因此也设定了上限。参照认知心理学的神奇数字 7±2 法则，一条错误消息中包含的信息块以 3~4 个为极限。
多语言错误消息的设计
全球化服务中，错误消息的多语言适配不可避免。然而，简单的翻译往往无法保证质量。多语言适配的设计模式，搜索吊袜带 (Amazon)中有系统性的介绍。
- 字数膨胀：英文错误消息翻译成中文时，字数通常缩减约 40~50%。反之，中文翻译成德语或法语时会膨胀 30~40%。UI 布局需要按最长语言来设计
- 文化差异：中文中"非常抱歉"这样的礼貌前缀很自然，但在英文中会显得冗余。应根据各语言的文化期望调整语气
- 模板化的陷阱："{field} 为必填项"这样的模板在中文中很自然，但在某些语言中由于语序或格变化的问题会产生不自然的句子。设计模板时需要考虑目标语言的语法结构
- 从右到左 (RTL) 语言：阿拉伯语和希伯来语的文本方向相反。错误图标的位置和文本对齐方向也需要相应翻转
安全性与错误消息
错误消息可能成为攻击者的宝贵信息来源。从安全角度出发，需要注意以下几点。
- 防止信息泄露：不要在错误消息中包含堆栈跟踪、数据库表名、内部 API 端点、服务器版本信息等。在生产环境中，详细的错误信息应仅记录在服务器端日志中，向用户返回通用消息
- 防止用户枚举攻击：如果在登录表单中显示"该邮箱地址未注册"，攻击者就能确定哪些邮箱已注册。应使用"邮箱地址或密码不正确"这样无法确定具体哪项有误的表达
- 速率限制的消息：显示"还剩 3 次尝试机会后账户将被锁定"这样的具体次数，等于告诉攻击者暴力破解的剩余尝试次数。使用"请稍后重试"这样模糊的表达更安全
常见的失败模式
- 只显示错误代码："Error 0x80070005"这样的技术性错误代码对非开发者毫无意义。如果要显示错误代码，务必附上通俗的说明文字
- 使用责怪用户的表达："您的输入有误""非法操作"这样的表达会让用户产生负罪感。应替换为"请确认输入内容""此操作当前不可用"等中性表达
- 只说原因不给解决方案：仅显示"发生了网络错误"，用户不知道该怎么办。应写成"请检查网络连接后重试"，务必提示下一步操作
- 错误消息的复用：对所有错误都显示"出现了问题，请重试"是对用户最不友好的模式。应为每种错误类型准备专属消息
- 清空输入值：错误发生时清空表单的输入值，用户就不得不从头输入。正确做法是高亮出错位置，同时保留已输入的值
API 错误响应的设计
API 的错误响应需要同时向前端开发者和最终用户传递信息。推荐采用机器可读的错误代码与面向人类的消息相结合的结构。
通用的错误响应结构由三层组成：错误代码 (机器可读的唯一标识符)、消息 (人类可读的说明)、详细信息 (验证错误时各字段的错误)。错误代码应独立于 HTTP 状态码，设计应用专属的代码体系，这样前端的条件分支会更容易。
API 错误消息的国际化中，以错误代码为键管理各语言消息的方式最为高效。服务器端返回英文消息，前端根据用户的区域设置显示对应翻译，这种设计在可维护性和可扩展性方面都很优秀。
专业人士实践的错误消息设计技巧
- 创建错误消息的"语气矩阵"：以错误严重程度 (低/中/高) 和用户情绪状态 (焦虑/困惑/愤怒) 为两轴创建矩阵，为每个单元格定义合适的语气。轻微的验证错误可以随意些，支付错误则需要礼貌且具体
- 预防错误优先于消息设计：最好的错误消息是"不需要显示的错误消息"。实时显示输入限制 (如字符计数器的剩余字数显示)、将无效选项灰显、通过自动补全防止输入错误等，应优先设计不会产生错误的 UI。尼尔森启发式中的"错误预防" (Error prevention) 正是这一理念的体系化
- 分离错误日志和用户消息：面向开发者的详细错误信息 (堆栈跟踪、请求 ID) 记录在日志中，向用户只显示通俗消息。不过，联系客服时需要的"错误 ID"可以在用户界面上小字显示
- 错误消息的模板化：大型应用中，应将错误消息作为模板统一管理。准备"{action} 失败。{reason}。{solution}"这样的结构化模板，为每个错误填入参数，便于维持一致性和管理翻译
- 通过 A/B 测试优化消息：错误消息和营销文案一样可以进行 A/B 测试。比较不同文案的任务完成率和表单放弃率，基于数据改进消息。微小的文案变更有时会对转化率产生重大影响
- 年度错误消息盘点：每年至少盘点一次产品中的所有错误消息。可以发现对已废弃功能的引用、格式不一致、过时的联系方式等容易被忽视的问题
总结
错误消息是影响用户体验的重要 UI 元素。正如认知心理学的研究所示，处于压力状态下的用户能处理的信息量是有限的。以"发生了什么 + 该怎么做"两个要素为基础，根据错误类型设定合适的字数来设计。验证消息 15~40 字符、操作错误 30~60 字符、系统错误 40~80 字符为参考标准，使用字符计数器确认字数，创建贴近用户的消息。同时不要忘记安全方面的信息泄露防范、多语言适配时的字数膨胀、无障碍访问等考量，在整个产品中构建一致的错误消息体验。