Windows 7 中的错误消息

注意

此设计指南是为 Windows 7 创建的，尚未针对较新版本的 Windows 进行更新。 大部分指南原则上仍然适用，但演示和示例并不反映我们 当前的设计指南。

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

典型的模式错误消息。

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

精心编写、有用的错误消息对于高质量的用户体验至关重要。 错误写入的错误消息会导致产品满意度降低，并且是可避免的技术支持成本的主要原因。 不必要的错误消息会中断用户流。

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

这是正确的用户界面吗？

在决定之前，请考虑以下问题：

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

设计概念

错误信息的特征

有许多烦人、无益且编写不当的错误消息，这不足为奇。 而且，由于错误消息通常使用模式对话框显示，因此它们会中断用户的当前活动，并要求在允许用户继续之前得到确认。

问题的一部分是，有很多方法做错了。 请考虑错误消息耻辱大厅中的这些示例：

不必要的错误消息

不正确：

Windows XP 中的此示例可能是有史以来最糟糕的错误消息。 它表示程序无法启动，因为 Windows 本身正在关闭。 用户对此无能为力，甚至不想对此执行任何操作， (用户选择关闭 Windows，毕竟) 。 通过显示此错误消息，Windows 会阻止自身关闭！

问题： 错误消息本身就是问题。 除了消除错误消息之外，用户无需执行任何操作。

主要原因： 报告所有错误案例，而不考虑用户的目标或观点。

建议的替代方法： 不要报告用户不关心的错误。

“成功”错误消息

不正确：

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

问题： 从用户的角度来看，没有错误。 除了消除错误消息之外，用户无需执行任何操作。

主要原因： 从用户的角度来看，任务已成功完成，但从卸载程序的角度来看失败。

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

完全无用的错误消息

不正确：

用户知道有错误，但不知道错误是什么或该怎么做。 不，这不行！

问题： 错误消息未提供特定问题，用户对此无能为力。

主要原因： 最有可能是，该程序的错误处理很差。

建议的替代方法： 在程序中设计良好的错误处理。

难以理解的错误消息

不正确：

在此示例中，问题陈述是明确的，但补充说明完全令人费解。

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

主要原因： 从代码的角度而不是用户的角度解释问题。

建议的替代方法： 编写目标用户可以轻松理解的错误消息文本。 提供用户可以实际执行的解决方案。 设计程序的错误消息体验不需要程序员当场撰写错误消息。

过度通信的错误消息

不正确：

在此示例中，错误消息显然试图解释每个故障排除步骤。

问题： 信息太多。

主要原因： 提供过多的详细信息或尝试在错误消息中解释复杂的故障排除过程。

建议的替代方法： 避免不必要的细节。 此外，请避免使用疑难解答。 如果需要疑难解答，请关注最有可能的解决方案，并通过链接到“帮助”中的相应主题来解释其余部分。

不必要的严厉错误消息

不正确：

程序无法找到物体听起来几乎是灾难性的。 假设这是灾难性的，为什么反应正常？

问题： 节目的语气不必要的苛刻或戏剧性。

主要原因： 此问题是由于从程序的角度来看，该 bug 看起来是灾难性的。

建议的替代方法： 根据用户的观点仔细选择语言。

追溯用户的错误消息

不正确：

为什么让用户觉得自己是罪犯？

问题： 错误消息的表述方式是指责用户出错。

主要原因： 不敏感的措辞，侧重于用户的行为而不是问题。

建议的替代方法： 关注问题，而不是导致问题的用户操作，根据需要使用被动语音。

愚蠢的错误消息

不正确：

在此示例中，问题陈述具有讽刺意想，没有提供任何解决方案。

问题： 愚蠢或非 sequitor 的错误消息语句。

主要原因： 创建错误消息而不注意其上下文。

建议的替代方法： 让编写者制定和查看错误消息。 查看错误时，请考虑上下文和用户心态。

程序员错误消息

不正确：

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

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

主要原因： 程序员使用普通 UI 向自己发送消息。

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

错误信息呈现不力

不正确：

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

问题： 在错误消息演示文稿中错误地获取所有详细信息。

主要原因： 不知道并应用错误消息指南。 不使用编写器和编辑器来创建和查看错误消息。

错误处理的性质使得许多错误都很容易犯。 令人不安的是，大多数错误消息可能是耻辱大厅的提名人。

良好错误消息的特征

与前面的错误示例相比，良好的错误消息包括：

• 问题。 指出发生了问题。
• 原因。 说明问题发生的原因。
• 解决方案。 提供解决方案，以便用户可以解决问题。

此外，良好的错误消息以如下方式显示：

• 相关。 该消息显示用户关注的问题。
• 可行。 用户应执行操作或更改其行为作为消息的结果。
• 以用户为中心。 该消息根据目标用户操作或目标来描述问题，而不是代码对哪些内容不满意。
• 简短。 消息尽可能短，但不短。
• “清除”。 该消息使用普通语言，以便目标用户可以轻松理解问题和解决方案。
• 特定。 该消息使用特定语言描述问题，并提供所涉及的对象的特定名称、位置和值。
• 礼貌。 用户不应受到指责或感到愚蠢。
• 罕见。 不经常显示。 经常显示的错误消息是设计错误的迹象。

通过将错误处理体验设计为具有这些特征，可以将程序的错误消息排除在错误消息耻辱大厅外。

避免不必要的错误消息

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

要避免的最明显的错误消息是那些不可操作的错误消息。 如果用户可能不执行或更改任何操作就关闭消息，请省略错误消息。

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

不正确：

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

对于另一个示例，假设用户显式取消任务。 对于用户的观点，以下条件不是错误。

不正确：

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

有时，可以通过关注用户的目标而不是技术来消除错误消息。 这样做时，请重新考虑错误到底是什么。 问题与用户的目标有关，还是与程序满足目标的能力有关？ 如果用户的操作在现实世界中有意义，那么在软件中也应该有意义。

例如，假设在电子商务程序中，用户尝试使用搜索查找产品，但文本搜索查询没有匹配项，并且所需产品缺货。 从技术上讲，这是一个错误，但程序可能会：

• 继续搜索与查询最匹配的产品。
• 如果搜索有明显的错误，则会自动推荐更正的查询。
• 自动处理常见问题，例如拼写错误、替代拼写以及复数和动词大小写不匹配。
• 指示产品何时将有库存。

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

避免错误消息的另一个好方法是首先防止问题。 可以通过以下方法防止错误：

• 使用受约束的控件。 使用限制为有效值的控件。 列表、滑块、检查框、单选按钮和日期和时间选取器等控件限制为有效值，而文本框通常不是，并且可能需要错误消息。 但是，可以将文本框限制为仅接受某些字符并接受最大数量的字符。
• 使用受约束的交互。 对于拖动操作，允许用户仅拖放到有效目标上。
• 使用禁用的控件和菜单项。 当用户可以轻松推断控件或菜单项被禁用的原因时，禁用控件和菜单项。
• 提供良好的默认值。 如果用户可以接受默认值，则不太可能发生输入错误。 即使用户决定更改该值，默认值也会让用户知道预期的输入格式。
• 使事情只是工作。 如果任务不必要或自动执行，则用户不太可能犯错误。 或者，如果用户犯了小错误，但意图明确，问题会自动修复。 例如，可以自动更正次要格式问题。

提供必要的错误消息

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

一个常见的信念是，错误消息是最差的用户体验，应该不一切代价避免，但更准确地说，用户混淆是最糟糕的体验，应该不一切代价避免。 有时，成本是有用的错误消息。

请考虑禁用的控件。 大多数情况下，禁用控件的原因显而易见，因此禁用控件是避免错误消息的好方法。 但是，如果禁用控件的原因并不明显，该怎么办？ 用户无法继续，并且没有用于确定问题的反馈。 现在，用户停滞不前，必须推断出问题或获得技术支持。 在这种情况下，最好让控件保持启用状态，并改为提供有用的错误消息。

不正确：

为何在此处禁用“下一步”按钮？ 最好通过提供有用的错误消息来启用它并避免用户混淆。

如果不确定是否应提供错误消息，请首先撰写可能提供的错误消息。 如果用户可能执行操作或更改其行为，请提供错误消息。 相比之下，如果用户可能在不执行或更改任何操作的情况下关闭消息，请省略错误消息。

设计良好的错误处理

虽然编写良好的错误消息文本可能具有挑战性，但有时如果没有程序提供良好的错误处理支持，则不可能。 请考虑以下错误消息：

不正确：

有可能，问题确实是未知的，因为程序的错误处理支持是缺乏的。

虽然这可能是一条非常糟糕的错误消息，但它更有可能反映基础代码缺乏良好的错误处理，而没有关于该问题的具体信息。

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

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

良好的错误消息不仅仅是 UI 问题，也是软件设计问题。 良好的错误消息体验不是以后可以忽略的。

排查 (问题以及如何避免)

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

不正确：

正确：

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

在以下示例中，无法移动某个项，因为它已被移动或删除，或者访问被拒绝。 如果程序可以轻松确定原因，为什么要让用户负担来确定具体原因？

不正确：

嗯，这是哪一个？ 现在，用户必须进行故障排除。

程序可以确定访问是否被拒绝，因此应报告此问题并显示特定的错误消息。

正确：

对于特定原因，无需进行故障排除。

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

处理未知错误

在某些情况下，你确实不知道问题、原因或解决方案。 如果抑制错误是不明智的，最好是预先了解缺少信息，而不是提出可能不正确的问题、原因或解决方案。

例如，如果程序有未经处理的异常，则以下错误消息适用：

如果无法抑制未知错误，最好是预先了解缺少信息。

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

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

确定适当的消息类型

某些问题可能显示为错误、警告或信息，具体取决于重点和措辞。 例如，假设网页无法基于当前的 Windows Internet Explorer 配置加载未签名的 ActiveX 控件：

• 错误。 “此页无法加载未签名的 ActiveX 控件。” (短语为现有问题。)
• 警告。 “此页面的行为可能不符合预期，因为 Windows Internet Explorer 未配置为加载未签名的 ActiveX 控件。”或“允许此页面安装未签名的 ActiveX 控件？ 从不受信任的来源执行此操作可能会损害您的计算机。“ (两者都表示为可能导致未来问题的条件。)
• 信息。 “你已将 Windows Internet Explorer 配置为阻止未签名的 ActiveX 控件。” (短语为 fact 的语句。)

若要确定适当的消息类型，请重点关注用户需要知道或采取行动的问题的最重要方面。 通常，如果某个问题阻止用户继续，则应将其显示为错误;如果用户可以继续，则将其显示为警告。 根据该焦点制作main指令或其他相应文本，然后选择与文本匹配 (标准图标或其他) 。 main指令文本和图标应始终匹配。

错误消息演示文稿

Windows 程序中的大多数错误消息都使用模式对话框 (，如本文) 中的大多数示例一样，但还有其他选项：

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

将错误消息置于模式对话框中的好处是要求用户立即关注和确认。 但是，如果没有必要注意，这也是他们的主要缺点。

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

当用户在继续之前必须立即确认问题时，模式对话是一个很好的选择，但通常不是一个糟糕的选择。 通常，应首选使用最轻量级演示文稿，以很好地完成工作。

避免过度通信

通常， 用户不会阅读，他们会扫描。 文本越多，文本越难扫描，用户就越可能不阅读文本。 因此，请务必将文本缩减为基本内容，并在必要时使用渐进式披露和帮助链接来提供其他信息。

有许多极端示例，但让我们看一个更典型的示例。 以下示例具有良好错误消息的大部分属性，但其文本不简洁，需要阅读动机。

不正确：

此示例是一个很好的错误消息，但它过度通信。

所有这些文本到底在说什么？ 如下图所示：

正确：

此错误消息基本上包含相同的信息，但要简洁得多。

通过使用“帮助”提供详细信息，此错误消息具有 倒棱锥样式 的演示文稿。

有关过度通信的更多指南和示例，请参阅 用户界面文本。

如果只执行八项操作

1. 设计用于错误处理的程序。
2. 不要提供不必要的错误消息。
3. 通过提供必要的错误消息来避免用户混淆。
4. 确保错误消息提供了问题、原因和解决方案。
5. 请确保错误消息相关、可操作、简短、清晰、具体、礼貌和罕见。
6. 从用户的角度（而不是程序的观点）设计错误消息。
7. 避免让用户参与故障排除，针对每个可检测的原因使用不同的错误消息。
8. 使用最轻量级表示方法，该方法可很好地完成工作。

使用模式

错误消息有多种使用模式：

Label	值
系统问题 操作系统、硬件设备、网络或程序出现故障或未处于执行任务所需的状态。	用户可解决许多系统问题： 可以通过打开设备、重新连接设备以及插入媒体来解决设备问题。 可以通过检查物理网络连接并运行网络 诊断和修复来解决网络问题。 可以通过更改程序选项或重启程序来解决程序问题。 在此示例中，程序找不到执行用户任务的相机。 在此示例中，需要启用执行任务所需的功能。
文件问题 找不到用户启动的任务所需的文件或文件夹，该文件或文件夹已被使用，或者没有预期的格式。	在此示例中，无法删除文件或文件夹，因为找不到该文件或文件夹。 在此示例中，程序不支持给定的文件格式。
安全问题 用户无权访问资源，也没有足够的权限来执行用户启动的任务。	在此示例中，用户没有访问资源的权限。 在此示例中，用户没有执行任务的权限。
任务问题 执行由用户启动的任务时存在特定问题， (不是系统、找不到文件、文件格式或安全问题) 。	在此示例中，剪贴板数据不能粘贴到画图中。 在此示例中，用户无法安装软件升级。
用户输入问题 用户输入的值不正确或与其他用户输入不一致。	在此示例中，用户输入了不正确的时间值。 在此示例中，用户输入的格式不正确。

准则

呈现

• 在适当的时候使用任务对话框 来实现一致的外观和布局。 任务对话框需要 Windows Vista 或更高版本，因此不适合早期版本的 Windows。 如果必须使用消息框，请使用两个换行符将main指令与补充指令分开。

用户输入错误

• 尽可能防止或减少用户输入错误，方法是：
  • 使用受有效值约束的控件。
  • 单击时禁用控件和菜单项会导致错误，前提是禁用控件或菜单项的原因显而易见。
  • 提供良好的默认值。

不正确：

在此示例中，无约束文本框用于受约束的输入。 请改用滑块。

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

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

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

在此示例中，就地错误用于通过单击提交按钮找到的错误。

• 使用模式错误处理 (任务对话框或消息框) 所有其他问题， 包括涉及多个控件的错误或通过单击提交按钮找到的非上下文或非输入错误。
• 报告用户输入问题时，使用不正确的数据将输入焦点设置为第一个控件。 如有必要，将控件滚动到视图中。 如果控件是一个文本框，请选择整个内容。 错误消息所指的内容应始终是显而易见的。
• 不要清除错误的输入。 相反，请将其保留，以便用户无需从头开始即可查看并更正问题。
  • 例外： 清除不正确的密码和 PIN 文本框，因为用户无法有效地更正掩码输入。

故障排除

• 避免创建故障排除问题。 不要依赖单个错误消息来报告具有多个不同可检测原因的问题。
• 使用不同的错误消息 (通常针对每个可检测原因使用不同的补充说明) 。 例如，如果由于多种原因无法打开文件，请为每个原因提供单独的补充说明。
• 仅当无法确定特定原因时，才使用具有多个原因的消息。 在这种情况下，请按解决问题的可能性顺序提供解决方案。 这样做可帮助用户更高效地解决问题。

图标

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

• 使用错误图标。 异常：

  • 如果错误是使用模式对话框或气球显示的用户输入问题，请不要使用图标。 这样做与 Windows 令人鼓舞的语气相反。 但是，就地错误消息应使用 (16x16 像素) 的小错误图标来将它们明确标识为错误消息。

    

    

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

    

    在此示例中，就地错误消息需要一个小错误图标才能清楚地将其标识为错误消息。

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

  

  在此示例中，功能图标具有错误覆盖，并且该功能是错误的主题。

• 不要对错误使用警告图标。 这样做通常是为了使演示文稿感觉不那么严重。 错误不是警告。

  不正确：

  

  在此示例中，错误地使用了警告图标，使错误感觉不那么严重。

有关更多指南和示例，请参阅 标准图标。

渐进式披露

• 使用“显示/隐藏详细信息渐进式披露”按钮在错误消息中隐藏高级或详细信息。 这样做可简化典型用法的错误消息。 不要隐藏所需的信息，因为用户可能无法找到它。

在此示例中，渐进式披露按钮可帮助用户向下钻取更多详细信息（如果不需要），或者简化 UI。

• 除非确实有更多详细信息，否则不要使用“显示/隐藏详细信息”。 不要只以更详细的格式重述现有信息。
• 请勿使用显示/隐藏详细信息来显示帮助信息。 请改用帮助链接。

有关标记准则，请参阅 渐进式披露控制。

不再显示此消息

• 如果错误消息需要此选项，请重新考虑错误及其频率。 如果它具有 (相关、可操作且不常) 的错误的所有特征，则用户禁止显示它应该没有意义。

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

默认值

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

帮助

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

有关更多指南，请参阅 帮助。

错误代码

• 对于无法使具体和可操作的错误消息，或者它们受益于“帮助”，请考虑同时提供错误代码。 用户通常使用这些错误代码在 Internet 上搜索其他信息。
• 始终提供问题和解决方案的文本说明。 出于此目的，不要只依赖于错误代码。

不正确：

在此示例中，错误代码用作解决方案文本的替代。

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

正确：

1234

0xC0001234

不正确：

-1

-67113524

• 使用“显示/隐藏详细信息”可显示错误代码。 短语作为错误代码： <error code>。

在此示例中，错误代码用于补充可从进一步信息中受益的错误消息。

声音

• 请勿在错误消息中附带声音效果或蜂鸣声。 这样做是令人不和谐和不必要的。
  • 例外： 如果问题对计算机操作至关重要，则播放“严重停止”声音效果，并且用户必须立即采取措施以防止严重后果。

文本

常规

• 删除冗余文本。 在标题、main说明、补充说明、命令链接和提交按钮中查找它。 通常，在说明和交互式控件中保留全文，并从其他位置删除任何冗余。
• 使用以用户为中心的说明。 从用户操作或目标（而不是软件不满意的内容）的角度描述问题。 使用目标用户理解和使用的语言。 避免技术行话。

不正确：

正确：

在这些示例中，正确的版本使用用户的语言，而不正确的版本过于技术化。

• 请勿使用以下字词：
  • 错误、失败 (使用问题改为)
  • 未能 (使用，无法改为)
  • 非法、无效、错误 (改用错误)
  • 中止、终止、终止 (改为使用 stop)
  • 灾难性的致命 (改用严重)

这些条款是不必要的，与 Windows 的鼓励语气背道而驰。 正确使用时，错误图标充分表明存在问题。

不正确：

正确：

在不正确的示例中，术语“灾难性”和“故障”是不必要的。

• 不要使用指责用户或暗示用户错误的措辞。 避免在措辞中使用你和你的。 虽然通常首选主动语音，但当用户是使用者时使用被动语音，如果使用主动语音，可能会感到错误被指责。

不正确：

正确：

错误的示例使用活动语音责怪用户。

• 具体。 避免措辞模糊，例如语法错误和非法操作。 提供所涉及的对象的特定名称、位置和值。

不正确：

找不到文件。

磁盘已满。

值范围外。

字符无效。

设备不可用。

使用特定名称、位置和值解决这些问题要容易得多。

• 不要在尝试具体时给出可能不太可能的问题、原因或解决方案。 除非正确，否则不要提供问题、原因或解决方案。 例如，最好说发生了未知错误，而不是可能不准确的错误。
• 避免使用“请”一词，除非要求用户执行一些不方便的事情 (例如等待) 或软件追溯的情况。

正确：

Windows 将文件复制到计算机时，请稍候。

• 仅在导致用户 (严重问题的错误消息中使用“抱歉”一词 ，例如数据丢失或无法使用计算机) 。 例如，如果用户需要等待) 找到网络连接，则不要道歉，如果在程序正常运行期间 (。

正确：

很抱歉，Fabrikam 备份检测到无法恢复的问题，并且已关闭以保护计算机上的文件。

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

不正确：

正确：

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

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

正确：

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

• 避免使用对象名称开头的句子。 这样做通常很难分析。
• 不要使用感叹号或全大写字母的单词。 感叹号和大写字母让人感觉好像在对用户大喊大叫。

有关更多指南和示例，请参阅 样式和色调。

标题

• 使用标题标识错误源自的命令或功能。 异常：
  • 如果错误由许多不同的命令显示，请考虑改用程序名称。
  • 如果该游戏多余或与main指令混淆，请改用程序名称。
• 请勿使用标题来解释或总结main指令的目的问题。

不正确：

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

• 使用标题样式大写，不结束标点符号。

主要说明

• 使用main指令以清晰明了的特定语言描述问题。
• 简明扼要地使用一个完整句子。 将main指令分析为基本信息。 如果主题是程序或用户，则可以将其保留为隐式主题。 如果可以简洁地执行此操作，请包括问题的原因。 如果必须解释更多内容，请使用补充说明。

不正确：

在此示例中，整个错误消息都放在main指令中，使其难以阅读。

• 如果涉及对象，请具体说明，请提供其名称。
• 避免在main指令中放置完整的文件路径和 URL。 相反，请使用短名称 (（如文件名) ），并将全名 (（如文件路径) ）放在补充指令中。 但是，如果错误消息不需要补充指令，则可以在main指令中放置单个完整文件路径或 URL。

在此示例中，只有文件名位于 main 指令中。 完整路径位于补充说明中。

• 如果从上下文中看得很明显，则根本不提供完整的文件路径和 URL。

在此示例中，用户正在从 Windows 资源管理器重命名文件。 在这种情况下，不需要完整的文件路径，因为从上下文中可以明显看出。

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

主指令模板

虽然没有严格的措辞规则，但请尽可能尝试使用以下main指令模板：

• [可选使用者名称] 无法 [执行操作]
• [可选使用者名称] 无法 [执行操作] ，因为 [reason]
• [可选使用者名称] 无法[执行操作]到“[对象名称]”
• [可选使用者名称] 无法[执行操作]到“[对象名称]”，因为 [reason]
• 没有足够的 [资源] [执行操作]
• [使用者名称] 没有 [目的] 所需的 [对象名称]
• [设备或设置] 已关闭，以便 [不需要的结果]
• [设备或设置] 未 [可用 | 找到 | 打开 | 已启用]
• “[对象名称]”当前不可用
• 用户名或密码不正确
• 你无权访问“[对象名称]”
• 你没有 [执行操作] 的权限
• [程序名称] 遇到严重问题，必须立即关闭

当然，根据需要进行更改，使main指令在语法上正确并符合main指令准则。

补充说明

• 使用补充说明来：
  • 提供有关问题的其他详细信息。
  • 说明问题的原因。
  • 列出用户可以解决此问题的步骤。
  • 提供防止问题再次发生的措施。
• 尽可能提出一个实用且有用的解决方案，以便用户能够解决问题。 但是，请确保建议的解决方案有可能解决问题。 不要通过建议可能但不可能的解决方案来浪费用户的时间。

不正确：

在此示例中，虽然问题及其建议的解决方案是可能的，但不太可能出现。

• 如果问题是用户输入的值不正确，请使用补充说明来解释正确的值。 用户不必从其他源确定此信息。
• 如果问题陈述中可以简单推导，请不要提供解决方案。

在此示例中，无需补充说明;从问题语句中可以简单推导解决方案。

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

正确：

若要重启 Windows，请单击“确定”。

不正确：

单击“确定”重启 Windows。

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

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

不正确：

在此示例中，问题很可能是与用户的网络连接有关，因此不值得联系管理员。

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

不正确：

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

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

提交按钮

• 如果错误消息提供了解决问题的命令按钮或命令链接，请按照 对话框中的相应准则进行操作。
• 如果程序因错误而必须终止，请提供“退出程序”按钮。 为了避免混淆，请勿将 Close 用于此目的。
• 否则，请提供“关闭”按钮。 请勿对错误消息使用“确定”，因为此措辞表示问题正常。
  • 例外： 如果错误报告机制的固定标签 (与 MessageBox API 一样，请使用 OK )

文档

引用错误时：

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

例子： 如果收到 驱动器中没有 CD 光盘 的消息，请在驱动器中插入新的 CD 光盘，然后重试。