第 7 个Windows错误消息

备注

本设计指南针对 Windows 7 创建,尚未针对较新版本的 Windows。 大部分指南仍原则适用,但演示和示例并不反映 我们当前的设计指南

7 个Windows 7 个警告用户已发生的问题的错误消息。 相反,警告消息会提醒用户将来可能会导致问题的条件。 可以使用模式对话框、就地消息、通知或气球显示错误消息。

错误消息的屏幕截图:无法重命名

典型的模式错误消息。

有效的错误消息会通知用户问题已发生,解释问题发生的原因,并提供解决方案,以便用户可以解决此问题。 用户应执行一项操作,或因错误消息而更改其行为。

编写良好、有用的错误消息对于高质量的用户体验至关重要。 错误写入的错误消息会导致产品满意度降低,是避免技术支持成本的一个根本原因。 不必要的错误消息会中断用户的流。

注意: 与对话框 、警告消息确认、标准图标、通知和布局相关的 指南在单独的文章中提供。

这是正确的用户界面吗?

在决定之前,请考虑以下问题:

  • 用户界面是否 (UI) 出现了已经发生的问题? 如果不是,则消息不是错误。 如果用户收到将来可能导致问题的条件的警报,请使用警告消息。
  • 能否在不造成混淆的情况下防止此问题? 如果是这样,请改为防止此问题。 例如,使用受限于有效值的控件,而不是使用可能需要错误消息的不受约束的控件。 此外,单击 时禁用控件会导致错误,只要控件被禁用的原因很明显。
  • 问题是否可自动更正? 如果是这样,请处理问题并禁止显示错误消息。
  • 用户是否可能会执行操作或更改其行为作为消息的结果? 如果不是,则条件不能证明中断用户是合理,因此最好禁止显示错误。
  • 当用户主动使用其他程序时,问题是否相关? 如果是,请考虑使用通知区域图标 显示问题
  • 问题是否与当前用户活动不相关,是否需要立即执行用户操作,并且用户可以随意忽略它? 如果是这样,请改为 使用操作失败 通知。
  • 问题是否与主窗口中后台任务的状态相关? 如果是这样,请考虑使用状态栏 显示问题
  • 主要目标用户是 IT 专业人员吗? 如果是这样,请考虑使用备用反馈机制,例如 日志文件条目或 电子邮件警报。 IT 专业人员强烈建议使用日志文件获取非关键信息。

设计概念

不良错误消息的特征

有许多令人麻烦、没有帮助且写入不佳的错误消息,这一点应该并不意外。 而且,由于错误消息通常是使用模式对话呈现的,因此会中断用户的当前活动,并要求在允许用户继续操作之前进行确认。

问题的一部分是,有太多方法可以出错。 请考虑以下来自 Error Message Hall of 则来自以下示例:

不必要的错误消息

不正确:

错误消息的屏幕截图:应用程序失败

来自 Windows XP 的此示例可能是最差的错误消息。 它指示程序无法启动,因为Windows本身正在关闭。 用户无法对此执行任何操作,甚至不希望在用户选择关闭 (关闭后Windows关闭) 。 通过显示此错误消息,Windows阻止自己关闭!

问题: 错误消息本身是问题所在。 除了消除错误消息外,用户没有任何操作可做。

前导原因: 报告所有错误案例,而不考虑用户的目标或观点。

建议的替代项: 不要报告用户不关心的错误。

"成功"错误消息

不正确:

错误消息的屏幕截图:删除失败

此错误消息是由于用户选择在程序删除后立即Windows重启。 从用户的角度来看,程序删除成功。

问题: 从用户的角度来看,没有错误。 除了消除错误消息外,用户没有任何操作可做。

前导原因: 从用户的角度来看,任务已成功完成,但从卸载程序的角度来看失败。

建议的替代项: 不要报告用户认为可接受的条件的错误。

完全无用错误消息

不正确:

错误消息的屏幕截图:未知错误

用户了解到发生了错误,但不知道错误是什么或该怎么办。 否,这不一样!

问题: 错误消息未提供特定问题,用户无法执行任何操作。

前导原因: 最有可能的是,程序的错误处理不佳。

建议的替代项: 在程序中设计良好的错误处理。

无法理解的错误消息

不正确:

错误消息的屏幕截图:备份无法完成

本示例中,问题陈述清晰明了,但补充说明完全不解。

问题: 问题陈述或解决方案不可理解。

前导原因: 从代码的角度(而不是用户的角度)解释问题。

建议的替代项: 编写目标用户可以轻松理解的错误消息文本。 提供用户可以实际执行的解决方案。 设计程序的错误消息体验时,程序员不会就地撰写错误消息。

过度通信的错误消息

不正确:

极详细消息的屏幕截图

此示例中,错误消息似乎尝试解释每个故障排除步骤。

问题: 信息太多。

前导原因: 提供过多的详细信息,或尝试解释错误消息中的复杂故障排除过程。

建议的替代项: 避免不必要的详细信息。 此外,请避免使用疑难解答。 如果需要疑难解答,请专注于最可能的解决方案,并链接到"帮助"中的相应主题,解释其余部分。

不必要地处理错误消息

不正确:

消息的屏幕截图:找不到对象

程序无法找到对象,这很难说是灾难性操作。 假设它是灾难性事件,为什么响应正常?

问题: 节目的语调不必要地令人生色或巨大。

前导原因: 此问题是由于一个从程序的角度来看似乎具有灾难性后果的 bug。

建议的替代项: 根据用户的观点仔细选择语言。

对用户进行警告的错误消息

不正确:

消息的屏幕截图:非法字符

为什么让用户感觉自己是犯罪?

问题: 错误消息的短语方式使用户无法出错。

前导原因: 不敏感短语,侧重于用户的行为而不是问题。

建议的替代项: 请专注于问题,而不是导致问题的用户操作,并在必要时使用被动语音。

错误错误消息

不正确:

消息的屏幕截图:错误报告中的错误

此示例中,问题陈述非常具有反性,并且未提供解决方案。

问题: 错误消息语句是错误或非 sequitor。

前导原因: 在不注意其上下文的情况下创建错误消息。

建议的替代项: 由编写器创建并查看错误消息。 查看错误时,请考虑上下文和用户的状态。

程序员错误消息

不正确:

消息的屏幕截图:访问冲突地址

此示例中的错误消息指示程序中存在 bug。 此错误消息仅对程序员有意义。

问题: 旨在帮助程序开发人员查找 bug 的消息将留在程序的发布版本中。 这些错误消息对于用户没有任何意义或值。

前导原因: 程序员使用普通 UI 向自己发送消息。

建议的替代项: 开发人员必须有条件地编译所有此类消息,以便自动从产品的发布版本中删除这些消息。 不要浪费时间尝试使用户理解这种错误,因为他们的唯一受众是程序员。

显示不佳的错误消息

不正确:

消息的屏幕截图:意外失败

此示例有许多常见的演示错误。

问题: 在错误消息演示中错误获取所有详细信息。

前导原因: 不知道并应用错误消息准则。 不使用编写器和编辑来创建和查看错误消息。

错误处理的性质使得其中许多错误很容易发生。 令人担忧的是,大多数错误消息可能是"The Hall of Hall"的错误消息。

良好错误消息的特征

与前面的错误示例相比,良好的错误消息具有:

  • 问题。 指出出现了问题。
  • 原因。 解释问题发生的原因。
  • 解决方案。 提供一个解决方案,以便用户可以解决此问题。

此外,良好的错误消息呈现方式如下:

  • 相关。 该消息显示用户关心的问题。
  • 可行。 用户应执行一项操作,或更改其行为作为消息的结果。
  • 以用户为中心。 该消息以目标用户操作或目标描述问题,而不是根据代码的不规范内容描述问题。
  • 简短。 消息尽可能短,但不短。
  • 清楚。 该消息使用纯语言,以便目标用户可以轻松理解问题与解决方案。
  • 特定。 该消息使用特定语言描述问题,并给出所涉及的对象的特定名称、位置和值。
  • 礼貌。 不应对用户进行指错,也不应让用户感到不自在。
  • 罕见。 不常显示。 经常显示的错误消息是设计错误的标志。

通过设计具有这些特征的错误处理体验,可以将程序的错误消息排除在"Error Message Hall of Handling"外。

避免不必要的错误消息

通常,最佳错误消息不是错误消息。 可以通过更好的设计避免许多错误,并且错误消息通常有更好的替代方法。 防止错误通常比报告错误更好。

要避免的最明显错误消息是不可操作的消息。 如果用户可能在不执行或更改任何操作的情况下关闭消息,请省略错误消息。

可以消除某些错误消息,因为它们不是用户认为的问题。 例如,假设用户尝试删除已在删除过程中的文件。 虽然从代码的角度来看,这可能是意外情况,但用户不会认为这是一个错误,因为他们所需的结果已实现。

不正确:

消息的屏幕截图:无法删除文件

应消除此错误消息,因为从用户的角度来看操作已成功。

另举一例,假设用户显式取消任务。 从用户的角度来看,以下条件不是错误。

不正确:

消息的屏幕截图:无法完成备份

还应消除此错误消息,因为从用户的角度来看操作已成功。

有时,可以通过专注于用户的目标而不是技术来消除错误消息。 这样做时,请重新思考错误是什么。 问题出在用户的目标上,还是与程序满足目标的能力有关? 如果用户的操作在现实世界中有意义,则它在软件中也应有意义。

例如,假设在电子商务程序中,用户尝试使用搜索查找产品,但文本搜索查询没有匹配项,并且所需的产品没有库存。 从技术上说,这是一个错误,但程序可以:

  • 继续搜索与查询最匹配的产品。
  • 如果搜索有明显的错误,则自动建议更正查询。
  • 自动处理拼写错误、替代拼写以及复数形式和谓词不匹配等常见问题。
  • 指示产品何时有库存。

只要用户的请求合理,设计良好的电子商务程序应返回合理的结果,而不是错误。

避免错误消息的另一种好办法是首先防止出现问题。 可以通过:

  • 使用受约束的控件。 使用受限于有效值的控件。 列表、滑块、复选框、单选按钮和日期和时间选取器等控件被约束为有效值,而文本框通常不是,并且可能需要错误消息。 但是,可以将文本框约束为仅接受特定字符并接受最大字符数。
  • 使用受约束的交互。 对于拖动操作,允许用户仅删除有效目标。
  • 使用禁用的控件和菜单项。 当用户可以轻松推断控件或菜单项被禁用的原因时,禁用控件和菜单项。
  • 提供良好的默认值。 如果用户可以接受默认值,则他们不太可能出现输入错误。 即使用户决定更改值,默认值也让用户知道预期的输入格式。
  • 使一切正常工作。 如果用户不需要或自动执行这些任务,则用户不太可能出错。 或者,如果用户错误较小,但意图清晰,则会自动修复此问题。 例如,可以自动更正次要格式设置问题。

提供必要的错误消息

有时确实需要提供错误消息。 用户出错、网络和设备停止工作、找不到或修改对象、无法完成任务以及程序存在 bug。 理想情况下,这些问题很少发生,例如,我们可以设计软件来防止多种类型的用户错误,但防止所有这些问题并不现实。 当其中一个问题发生时,有用的错误消息会让用户快速恢复运行。

一个常见的误解是,错误消息是最差的用户体验,应避免产生任何费用,但更准确的说,用户混淆是最差的体验,应全部避免。 有时,该成本是一条有用的错误消息。

请考虑禁用的控件。 大多数情况下,禁用控件的原因很明显,因此禁用控件是避免错误消息的一种好方法。 但是,如果禁用控件的原因并不明显,该做什么? 用户无法继续操作,并且没有反馈来确定问题。 现在,用户停滞,必须推断出问题或获取技术支持。 在这种情况下,最好让控件保持启用状态,并改为提供有用的错误消息。

不正确:

消息的屏幕截图:将备份保存到何处?

为什么此处禁用了"下一步"按钮? 最好通过提供有用的错误消息来启用它并避免用户混淆。

如果不确定是否应该提供错误消息,请首先编写可能给出的错误消息。 如果用户可能会执行操作或更改其行为作为结果,请提供错误消息。 相反,如果用户可能在不执行或更改任何操作的情况下关闭消息,请省略错误消息。

设计良好的错误处理

虽然制作好的错误消息文本可能很有挑战性,但有时如果没有来自程序的良好错误处理支持,则不可能。 请考虑以下错误消息:

不正确:

消息的屏幕截图:未知错误

问题可能确实未知,因为缺少程序的错误处理支持。

尽管这很可能是一条写入效果不佳的错误消息,但更可能反映基础代码缺乏良好的错误处理,没有关于该问题的特定信息。

为了创建特定、可操作、以用户为中心的错误消息,程序的错误处理代码必须提供特定的高级错误信息:

  • 每个问题都应分配有唯一的错误代码。
  • 如果问题具有多种原因,则程序应尽可能确定特定原因。
  • 如果问题具有参数,则必须维护这些参数。
  • 必须在足够高级别处理低级别问题,以便从用户的角度显示错误消息。

好的错误消息不仅仅是 UI 问题,也是软件设计问题。 良好的错误消息体验并不是以后可以攻击的。

故障排除 (以及如何避免)

当报告具有多个不同原因的问题并出现单个错误消息时,对结果进行故障排除。

不正确:

说明三个原因的一条消息的示意图

正确:

说明每个原因的三条消息的示意图

当报告多个问题并出现单个错误消息时,对结果进行故障排除。

在下面的示例中,无法移动某个项,因为该项已被移动或删除,或者访问被拒绝。 如果程序可以轻松确定原因,为什么将负担放在用户上以确定特定原因?

不正确:

说明两个原因的消息的屏幕截图

那么,它是什么? 现在,用户必须进行故障排除。

程序可以确定访问是否被拒绝,因此应该使用特定的错误消息报告此问题。

正确:

说明一个原因的消息的屏幕截图

由于特定原因,无需进行故障排除。

仅在无法确定特定原因时,才使用具有多个原因的消息。 此示例中,程序很难确定该项是移动还是已删除,因此可能在此处使用具有多个原因的单个错误消息。 但是,用户不太可能会关心,例如,他们无法移动已删除的文件。 对于这些原因,甚至不需要错误消息。

处理未知错误

在某些情况下,你确实不知道问题、原因或解决方案。 如果取消显示错误是不明智的,最好对缺少信息进行了解,而不是提供可能错误的问题、原因或解决方案。

例如,如果程序有未经处理异常,则适合以下错误消息:

消息的屏幕截图:出现未知错误

如果无法禁止显示未知错误,最好了解缺少信息。

另一方面,如果大多数情况下可能会有所帮助,请提供具体的可操作信息。

显示"服务器Office Communicator"消息的屏幕截图。

如果网络连接通常是问题所在,则此错误消息适用于未知错误。

确定适当的消息类型

某些问题可能呈现为错误、警告或信息,具体取决于重点和短语。 例如,假设网页无法根据当前 ActiveX 配置加载无符号Windows Internet Explorer控件:

  • 错误。 "此页无法加载无符号ActiveX控件。" (短语为现有问题。)
  • 警告。 "此页的行为可能未按预期方式进行,Windows Internet Explorer未配置为加载未签名ActiveX控件。" 或"允许此页安装未签名ActiveX控件?" 从不受信任的源执行此操作可能会损害计算机。" (都短语为可能导致将来出现问题的条件。)
  • 信息。 "你已配置Windows Internet Explorer以阻止未签名ActiveX控件。" (短语作为 fact.)

若要确定适当的消息类型,请专注于用户需要知道或处理的问题最重要的方面。 通常,如果问题阻止用户继续,则应该以错误表示;如果用户可以继续,则以警告显示。 基于 该焦点创建 主指令或其他相应的文本,然后选择一个 ( 与文本) 的其他图标。 主指令文本和图标应始终匹配。

错误消息演示

使用模式对话框Windows程序中的大多数错误消息 (如本文中的大多数) 所示,但还有其他选项:

  • 就地
  • 气球
  • 通知
  • 通知区域图标
  • 状态栏
  • 日志文件 (针对 IT 专业人员错误)

将错误消息置于模式对话框中的好处是要求用户立即关注和确认。 但是,如果不需要这种关注,这也是它们的主要缺点。

消息的屏幕截图:停止你正在执行的工作

是否确实需要中断用户,以便他们可以单击"关闭"按钮? 如果没有,请考虑使用模式对话框的替代方法。

模式对话是一个很好的选择,因为用户必须在继续之前立即确认问题,但通常不是一个差的选择。 通常,您应该更喜欢使用最小的权重表示法来完成工作。

避免 overcommunicating

通常, 用户不会阅读,他们会进行扫描。 文本越多,文本扫描难度就越多,用户也不会读取文本。 因此,将文本减少到其基础知识很重要,并在必要时使用渐进式披露和帮助链接提供附加信息。

有很多极端示例,但让我们看看一个更典型的示例。 下面的示例具有良好的错误消息的大多数属性,但其文本并不简洁,需要继续进行读取。

不正确:

详细消息的屏幕截图

此示例是一个很好的错误消息,但 overcommunicates。

这一切文本确实是什么意思? 如下图所示:

正确:

消息屏幕截图:未检测到 cd 刻录机

此错误消息实质上是相同的信息,但要简洁得多。

此错误消息通过使用 "帮助" 来提供详细信息。

有关 overcommunicating 的更多指导和示例,请参阅 用户界面文本

如果只执行八项操作

  1. 设计用于错误处理的程序。
  2. 不要发出不必要的错误消息。
  3. 通过提供必要的错误消息避免用户混淆。
  4. 请确保错误消息提供了问题、原因和解决方法。
  5. 请确保错误消息是相关的、可操作、简短、清晰、特定、短暂地和罕见的。
  6. 从用户的观点设计错误消息,而不是从程序的角度设计。
  7. 避免在故障排除中涉及用户对每个检测到的原因使用不同的错误消息。
  8. 使用最小权重表示方法来完成作业。

使用模式

错误消息具有几个使用模式:

Label
系统问题
操作系统、硬件设备、网络或程序已失败,或者未处于执行任务所需的状态。
用户可解决许多系统问题:
  • 可以通过打开设备、重新连接设备和插入媒体来解决设备问题。
  • 可以通过检查物理网络连接和运行 网络诊断和修复来解决网络问题。
  • 可以通过更改程序选项或重新启动程序来解决程序问题。
Screen shot of message: Can't find a camera
在此示例中,程序找不到用于执行用户任务的相机。
Screen shot of message Network discovery off
在此示例中,需要打开执行任务所需的功能。
文件问题
找不到由用户启动的任务所需的文件或文件夹,该文件或文件夹已在使用中,或其格式不正确。
Screen shot of message: Can't delete file
在此示例中,无法删除文件或文件夹,因为找不到该文件或文件夹。
Screen shot of message: Can't play this file
在此示例中,程序不支持给定的文件格式。
安全问题
用户无权访问资源,或具有足够的权限来执行用户启动的任务。
Screen shot of message: You don't have permission
在此示例中,用户没有访问资源的权限。
Screen shot of message: You don't have privilege
在此示例中,用户没有执行任务的权限。
任务问题
执行由用户启动的任务 (不是系统、找不到文件、文件格式或安全问题) 出现特定问题。
Screen shot of message: Data can't be pasted
在此示例中,剪贴板数据无法粘贴到画图中。
Screen shot of message: Upgrade can't be installed
在此示例中,用户无法安装软件升级。
用户输入问题
用户输入的值与其他用户输入不正确或不一致。
Screen shot of message: Incorrect time value
在此示例中,用户输入了不正确的时间值。
Screen shot of message: Incorrect input format
在此示例中,用户输入的格式不正确。

指南

呈现

  • 尽可能使用任务对话框 来实现一致的外观和布局。 任务对话框需要 Windows Vista 或更高版本,因此不适合 Windows 早期版本。 如果必须使用消息框,请使用两个换行符分隔补充指令中的主指令。

用户输入错误

  • 尽可能通过以下方法阻止或减少用户输入错误:
    • 使用限制为有效值的控件。
    • 当单击时禁用控件和菜单项会导致错误,前提是控件或菜单项被禁用的原因很明显。
    • 提供合理的默认值。

不正确:

带有扬声器音量标签的文本框的屏幕截图

在此示例中,不受约束的文本框用于受约束的输入。 改为使用滑块。

  • 使用无模式错误处理 (就地错误或气球) ,以应对上下文用户输入问题。
  • 将球标用于在文本框中或在文本框失去焦点之后检测到的非关键单点用户输入问题。气球 不需要可用的屏幕空间或显示就地消息所需的动态布局。 一次只显示一个气球。 由于此问题并不重要,因此无需错误图标。 单击时,气球消失,问题解决后或超时后出现。

消息屏幕截图:字符不正确

在此示例中,气球指示仍在控件中的一个输入问题。

  • 对延迟的错误检测使用就地错误, 这通常是通过单击 "提交" 按钮找到的错误。 (请勿对立即提交的设置使用 就地错误 。 ) 一次可以有多个就地错误。 使用普通文本和16x16 像素错误图标,并在可能的情况下将它们直接放置在问题旁。 除非用户提交且未找到其他错误,否则就地错误不会消失。

消息屏幕截图:错误的电子邮件地址

在此示例中,通过单击 "提交" 按钮发现错误的就地错误。

  • 将模式错误处理 (任务对话框或消息框中) ,以解决所有其他问题, 包括涉及多个控件或通过单击 "提交" 按钮发现非上下文或非输入错误的错误。
  • 当报告用户输入问题时,请将输入焦点设置为具有错误数据的第一个控件。 必要时将控件滚动到视图中。 如果控件是文本框,请选择整个内容。 应始终清楚错误消息所引用的内容。
  • 不要清除输入错误。 相反,请将其保留,使用户可以在不重新启动的情况下查看和更正问题。
    • 异常: 清除 "密码不正确" 和 "固定" 文本框,因为用户不能有效地更正屏蔽输入。

疑难解答

  • 避免产生疑难解答问题。 不要依赖单个错误消息来报告几个不同的可检测原因的问题。
  • 对于每个检测到的原因,请使用不同的错误消息 (通常是不同的补充指令) 。 例如,如果某个文件由于某些原因而无法打开,则为每个原因提供单独的补充说明。
  • 仅当无法确定特定原因时,才使用具有多个原因的消息。 在这种情况下,请按照解决问题的可能的顺序来显示解决方案。 这样做可帮助用户更有效地解决问题。

图标

  • 模式错误消息对话框没有标题栏图标。 标题栏图标用作主窗口和辅助窗口之间的视觉差别。

  • 使用错误图标。 异常:

    • 如果错误是使用模式对话框或气球显示的用户输入问题,请不要使用图标。 这样做是 Windows 的鼓励音。 但是,就地错误消息应使用 (16x16 像素的小错误图标) 清楚地将它们标识为错误消息。

      消息的屏幕截图格式不正确

      消息计算机名称的屏幕截图太长

      在这些示例中,用户输入问题不需要错误图标。

      消息电话号码格式错误的屏幕截图

      在此示例中,就地错误消息需要一个小错误图标,以明确地将其标识为错误消息。

  • 如果此问题适用于带有图标 (而不是用户输入问题) 的功能,则可以使用具有错误覆盖的功能图标。 如果执行此操作,还应使用功能名称作为错误的主题。

    屏幕截图消息 media player 无法播放文件

    在此示例中,功能图标有一个错误覆盖,该功能是错误的主题。

  • 不要使用警告图标来查找错误。 这通常是为了使演示感到不太严重。 错误不是警告。

    不正确:

    未启用消息快速切换的屏幕截图

    在此示例中,不正确地使用警告图标来使错误感觉不太严重。

有关更多指导和示例,请参阅 标准图标

渐进式披露

  • 使用 "显示/隐藏详细信息泄漏" 按钮,可以在错误消息中隐藏高级或详细信息。 这样做可以简化错误消息的典型用法。 不要隐藏所需的信息,因为用户可能找不到它。

消息屏幕截图: activesync 无法登录

在此示例中,"渐进式披露" 按钮有助于用户在需要时向下钻取更多详细信息,如果不需要,还可以简化 UI。

  • 不要使用显示/隐藏详细信息,除非确实有更详细的信息。 不要只是以更详细的格式重述现有信息。
  • 不要使用 "显示/隐藏详细信息" 来显示帮助信息。 请改用帮助链接。

有关标签准则,请参阅 渐进式披露控件

不再显示此消息

  • 如果错误消息需要此选项,请重新考虑错误及其频率。 如果它具有良好错误的所有特征 (相关、可操作且不常发生的) ,则用户不能将其取消。

有关更多指南,请参阅 对话框

默认值

  • 选择最安全、最小的破坏性或最安全的响应作为默认值。 如果安全不是一个因素,请选择最可能的或便捷的命令。

帮助

  • 设计错误消息,以避免需要帮助。 通常,用户不必阅读外部文本来理解和解决问题,除非解决方案需要多个步骤。
  • 请确保帮助内容相关且有用。 它不应是错误消息的详细重述,而应包含错误消息范围之外的有用信息,例如,用于避免将来出现此问题的方法。 不要提供 "帮助" 链接,只是因为你可以。
  • 使用特定的、简洁的相关帮助链接来访问帮助内容。 请勿使用命令按钮或渐进式披露来实现此目的。
  • 对于无法进行特定操作并可操作的错误消息,请考虑提供联机帮助内容的链接。 这样,你就可以向用户提供其他信息,你可以在该程序发布后更新该信息。

有关更多指导,请参阅 " 帮助"。

错误代码

  • 对于无法进行具体的操作的错误消息或从 "帮助" 中获益的错误消息,还应考虑提供错误代码。 用户通常使用这些错误代码在 Internet 上搜索其他信息。
  • 始终提供问题和解决方案的文本说明。 请勿仅依赖于错误代码来实现此目的。

不正确:

消息屏幕截图:无法打开文件

在此示例中,错误代码用于替代解决方案文本。

  • 为每个不同的原因分配一个唯一的错误代码。 这样做可以避免故障排除。
  • 选择可在 Internet 上轻松搜索的错误代码。 如果使用32位代码,请使用带有前导 "0x" 和大写字符的十六进制表示形式。

正确:

1234

0xC0001234

不正确:

-1

-67113524

  • 使用 "显示/隐藏详细信息" 显示错误代码。 短语作为错误代码: 。

消息屏幕截图:程序未初始化

在此示例中,将使用错误代码来补充可从其他信息中受益的错误消息。

声音

  • 不要附带带有声音效果或嘟嘟声的错误消息。 这样做的 jarring 和不必要。
    • 异常: 如果问题对于计算机的操作至关重要,则播放关键停止声音效果,用户必须立即采取措施来防止严重后果。

文本

常规

  • 删除冗余文本。 在标题、主要说明、补充说明、命令链接和提交按钮中查找它。 通常,请在说明和交互式控件中保留完整文本,并删除其他位置的任何冗余。
  • 使用以用户为中心的说明。 描述用户操作或目标方面的问题,而不是对软件不满意的内容。 使用目标用户理解并使用的语言。 避免技术术语。

不正确:

消息屏幕截图:输入-同步调用

正确:

消息屏幕截图:正在接收呼叫

在这些示例中,正确的版本会说出用户的语言,而错误的版本却太技术性了。

  • 不要使用以下词语:
    • 错误,失败 (改用问题)
    • 无法 (使用无法改为)
    • 非法、无效、错误 (改用不正确的)
    • 中止、终止、终止 (改用 stop)
    • 灾难性的严重 (改用严重)

不需要这些术语,这与 Windows 的鼓励音相反。 当 正确使用时,"错误" 图标会完全传达问题。

不正确:

消息屏幕截图:灾难性故障!

正确:

消息的屏幕截图:备份必须一次关闭

在不正确的示例中,不需要使用术语"灾难性"和"失败"。

  • 请勿使用对用户负责或暗示用户错误的短语。 避免在短语中使用 你和 。 虽然主动语音通常是首选的,但当用户是使用者时,请使用被动语音,如果使用主动语音,则可能会因为错误而感到错误。

不正确:

输入错误登录的消息的屏幕截图

正确:

消息的屏幕截图:密码不正确

不正确的示例使用活动语音来指错用户。

  • 具体说来。 避免使用模糊的词句,例如语法错误和非法操作。 提供涉及的对象的特定名称、位置和值。

不正确:

找不到文件。

磁盘已满。

值范围外。

字符无效。

设备不可用。

使用特定名称、位置和值可以更轻松地解决这些问题。

  • 请勿在尝试进行特定操作时提供可能不太可能的问题、原因或解决方案。 除非可能正确,否则请勿提供问题、原因或解决方案。 例如,最好说发生了未知错误,而不是可能不准确的错误。
  • 请避免使用"请 "一词,除非要求用户执行一些不方便 (例如等待) 或软件对这种情况负责。

正确:

请等待Windows文件复制到计算机。

  • 仅在错误消息中 使用"抱歉"一词,导致用户 (,例如数据丢失或无法使用计算机) 。 如果问题发生在程序正常运行期间, (,例如,如果用户需要等待网络连接) 。

正确:

抱歉,Fabrikam Backup 检测到无法恢复的问题,并已关闭以保护你的计算机上的文件。

  • 请参阅使用短名称的产品。 请勿使用完整的产品名称或商标符号。 除非用户将公司名称与产品关联,否则不要包含公司名称。 请勿包含程序版本号。

不正确:

显示"无法Microsoft Office Outlook项"消息的屏幕截图。

正确:

消息的屏幕截图:无法打开此项

在不正确的示例中,使用了完整的产品名称和商标符号。

  • 在对象名称周围使用双引号。 这样做可使文本更易于分析,并避免可能易行的语句。
    • 例外: 完全限定的文件路径、URL 和域名不需要使用双引号。

正确:

消息的屏幕截图:"my house"不可用

此示例中,如果对象名称不在引号中,则错误消息会令人困惑。

  • 避免使用对象名称启动句子。 这样做通常很难分析。
  • 不要将感叹号或单词用于所有大写字母。 感叹号和大写字母让你感觉自己正在向用户看。

有关更多指南和示例,请参阅 样式和音调

标题

  • 使用 标题标识错误源自的命令或功能。 异常:
    • 如果许多不同的命令显示错误,请考虑改为使用程序名称。
    • 如果该标题是冗余的,或者与主指令混淆,请改为使用程序名称。
  • 请勿使用标题来解释或汇总 作为主要指令用途的问题。

不正确:

显示"无法重命名新文件夹"消息的屏幕截图。

此示例中,标题被错误地用于解释问题。

  • 使用标题样式大写,而不结束标点。

主要说明

  • 使用主要说明以清晰、纯文本、特定语言描述问题。
  • 简洁,只需使用一个完整的句子。 将主指令向下拉至基本信息。 如果是程序或用户,可以将主题保留为隐式。 如果可以简洁地这样做,请包括问题的原因。 如果必须说明其他内容,请使用补充说明。

不正确:

消息的屏幕截图:无法安装升级

本示例将整个错误消息放在主指令中,使其难以阅读。

  • 如果涉及对象,请指定其名称,具体说来。
  • 避免在主指令中放置完整的文件路径和 URL。 相反,请使用短名称 (如文件名) ,并输入完整名称 (如补充指令) 文件路径)。 但是,如果错误消息不需要补充指令,可以将单个完整文件路径或 URL 放在主指令中。

消息的屏幕截图:无法删除 fabrikam 文件

此示例中,只有文件名位于主指令中。 完整路径位于补充指令中。

  • 如果从上下文中明显可见,则完全不要提供完整的文件路径和 URL。

消息的屏幕截图:无法重命名新文件夹

此示例中,用户正在从资源管理器Windows文件。 在这种情况下,不需要完整的文件路径,因为从上下文中看,它很明显。

  • 尽可能使用当前时态。
  • 使用句式大写。
  • 如果指令是语句,则不要包含最终句点。 如果指令是问题,请包含最终问号。

主要指令模板

虽然没有严格的短语规则,但尽可能尝试使用以下主要指令模板:

  • [可选主题名称] 无法 [执行操作]
  • [可选主题名称] 无法 [执行操作] ,因为 [原因]
  • [可选主题名称] 无法 [执行操作] 到"[对象名称]"
  • [可选主题名称] 无法 [执行操作] 到"[对象名称]",因为 [reason]
  • 没有足够的 [资源] [执行操作]
  • [主题名称] 没有 [用途] 所需的 [对象名称]
  • [设备或设置] 已关闭,以便 [不预期的结果]
  • [设备或设置] 未 [可用 | 发现 | 已启用 | ]
  • "[对象名称]"当前不可用
  • 用户名或密码不正确
  • 你无权访问"[对象名称]"
  • 你没有 [执行操作] 的权限
  • [程序名称] 遇到了严重问题,必须立即关闭

当然,请根据需要进行更改,使主要指令在语法上正确且符合主要指导准则。

补充说明

  • 使用补充说明可以:
    • 提供有关此问题的其他详细信息。
    • 解释问题的原因。
    • 列出用户可以采取哪些步骤来解决问题。
    • 提供防止问题再次出现的度量值。
  • 尽可能提出实用、有用的解决方案,以便用户可以解决此问题。 但是,请确保建议的解决方案可能解决此问题。 不要通过建议可能但不可能的解决方案来浪费用户的时间。

不正确:

消息的屏幕截图:内存不足

本示例中,尽管问题及其建议的解决方案可行,但不太可能出现。

  • 如果问题是用户输入的不正确值,请使用补充说明解释正确的值。 用户不需要从另一个源确定此信息。
  • 如果可以从问题陈述中简单推断出解决方案,请不要提供该解决方案。

消息的屏幕截图:时间值不正确

本示例不需要补充指令;可以从问题陈述中简单推断出解决方案。

  • 如果解决方案包含多个步骤,请按完成步骤的顺序提供这些步骤。 但是,请避免多步骤解决方案,因为用户难以记住两个或三个简单的步骤。 如果需要执行更多步骤,请参阅相应的帮助主题。
  • 保持补充说明简洁。 仅提供用户需要知道的。 省略不必要的详细信息。 目标为最多三个中等长度的句子。
  • 为了避免用户执行指令时出错,将结果放在操作之前。

正确:

若要重启Windows,请单击"确定"。

不正确:

单击"确定"重启Windows。

在不正确的示例中,用户更有可能意外单击"确定"。

  • 不建议联系管理员,除非这样做是问题最可能的解决方案之一。 为真正只能由管理员解决的问题保留此类解决方案。

不正确:

消息的屏幕截图:服务器不可用

此示例中,问题很可能出在用户的网络连接上,因此不需要联系管理员。

  • 不建议联系技术支持人员。 与技术支持联系以解决问题的选项始终可用,无需通过错误消息进行提升。 相反,请专注于编写有用的错误消息,以便用户无需联系技术支持即可解决问题。

不正确:

显示"无法打开此项"消息的屏幕截图。

此示例中,错误消息错误地建议联系技术支持人员。

  • 使用完整的句子、句子样式大写和结束标点。

提交按钮

  • 如果错误消息提供命令按钮或命令链接来解决问题,请遵循对话框 中的 相应准则
  • 如果程序必须因错误而终止,请提供"退出程序"按钮。 为避免混淆,请勿将 Close 用于此目的。
  • 否则,请提供"关闭"按钮。 请勿对错误消息使用"确定",因为此用词意味着问题正常。
    • 例外: 如果错误报告机制具有固定标签, (与 MessageBox API.)

文档

引用错误时:

  • 按主要说明引用错误。 如果主指令很长或详细,请进行汇总。
  • 如有必要,你可以将错误消息对话框引用为消息。 仅在编程和其他技术文档中将 作为错误消息引用。
  • 如果可能,使用粗体设置文本格式。 否则,仅在需要时将文本置于引号中以防止混淆。

例子: 如果收到驱动器 消息"没有 CD 磁盘",请在驱动器中插入新的 CD 磁盘,然后重试。