注释
此设计指南是为 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 控件。（短语为事实陈述。
若要确定适当的消息类型，请重点关注用户需要知道或采取行动的问题最重要的方面。 通常，如果问题阻止用户继续，则应将其显示为错误;如果用户可以继续，请将其显示为警告。 根据该焦点 或其他相应文本制作 主指令，然后选择与文本匹配的图标（标准 或其他）。 主指令文本和图标应始终匹配。
错误消息演示
Windows 程序中的大多数错误消息都使用模式对话框（如本文中的大多数示例所示），但还有其他选项：
- 就地
- 气球
- 通知
- 通知区域图标
- 状态栏
- 日志文件（针对面向 IT 专业人员的错误）
将错误消息放在模式对话框中的好处是要求用户立即注意和确认。 但是，如果不需要注意，这也是他们的主要缺点。
是否确实需要中断用户，以便他们可以单击“关闭”按钮？ 如果没有，请考虑使用模式对话框的替代方法。
当用户在继续之前必须立即确认问题时，模式对话是一个很好的选择，但通常选择不佳。 通常，应倾向于使用最轻量级演示文稿来做好这项工作。
避免过度通信
通常， 用户不会读取，他们扫描。 文本越多，文本就越难扫描，用户可能根本不会阅读文本。 因此，请务必将文本减少到其基本信息，并在必要时使用渐进式披露和帮助链接来提供其他信息。
有许多极端示例，但让我们看看一个更典型的示例。 以下示例包含良好错误消息的大部分属性，但其文本并不简洁，需要阅读动机。
不正确：
此示例是一条很好的错误消息，但它过度通信。
所有这些文本都真正说什么？ 如下所示：
正确：
此错误消息基本上具有相同的信息，但更简洁。
通过使用“帮助”提供详细信息，此错误消息具有 反转的棱锥形表示形式 。
有关过度通信的更多指南和示例，请参阅 用户界面文本。
如果你只做八件事
- 为错误处理设计程序。
- 不要提供不必要的错误消息。
- 通过提供必要的错误消息来避免用户混淆。
- 确保错误消息提供了问题、原因和解决方案。
- 确保错误消息相关、可作、简短、明确、具体、礼貌和罕见。
- 从用户的角度来看，而不是从程序的角度设计错误消息。
- 避免在故障排除中涉及用户，为每个可检测原因使用不同的错误消息。
- 使用最轻量级演示方法，以便很好地完成工作。
使用模式
错误消息有多个使用模式：
| 标签 | 价值 |
|---|---|
|
系统问题 作系统、硬件设备、网络或程序已失败或未处于执行任务所需的状态。 |
用户可以解决许多系统问题：
在此示例中，程序找不到执行用户任务的相机。 
在此示例中，需要启用执行任务所需的功能。 |
|
文件问题 找不到用户启动的任务所需的文件或文件夹、已在使用中，或者没有预期的格式。 |
在此示例中，无法删除文件或文件夹，因为它未找到。 
在此示例中，程序不支持给定的文件格式。 |
|
安全问题 用户无权访问资源，或者没有足够的权限来执行用户启动的任务。 |
在此示例中，用户无权访问资源。 
在此示例中，用户没有执行任务的权限。 |
|
任务问题 执行由用户启动的任务存在特定问题（不是系统、找不到文件、文件格式或安全问题）。 |
在此示例中，剪贴板数据无法粘贴到 Paint 中。 
在此示例中，用户无法安装软件升级。 |
|
用户输入问题 用户输入的值不正确或与其他用户输入不一致。 |
在此示例中，用户输入了不正确的时间值。 
在此示例中，用户输入的格式不正确。 |
准则
演示
- 在适当的时候使用任务对话框 来实现一致的外观和布局。 任务对话框需要 Windows Vista 或更高版本，因此它们不适合早期版本的 Windows。 如果必须使用消息框，请用两个换行符将主指令与补充指令分开。
用户输入错误
-
尽可能防止或减少用户输入错误，方法是：
- 使用约束为有效值的控件。
- 单击时禁用控件和菜单项会导致错误，只要控件或菜单项被禁用的原因很明显。
- 提供良好的默认值。
不正确：
在此示例中，未约束的文本框用于约束输入。 请改用滑块。
- 将无模式错误处理（就地错误或气球）用于上下文用户输入问题。
- 将气球用于在文本框中检测到的非关键单点用户输入问题或在文本框失去焦点后立即检测到的问题。气球 不需要可用的屏幕空间或显示就地消息所需的动态布局。 一次仅显示一个气球。 由于问题并不重要，因此不需要错误图标。 单击、解决问题时或超时后，气球将消失。
在此示例中，气球指示控件中仍存在输入问题。
- 使用就地错误进行延迟错误检测， 通常是通过单击提交按钮找到的错误。 （不要对立即提交的设置使用 就地错误 。一次可能存在多个就地错误。 使用普通文本和 16x16 像素错误图标，尽可能将它们直接放在问题旁边。 除非用户提交并且未找到其他错误，否则就地错误不会消失。
在此示例中，就地错误用于通过单击提交按钮找到的错误。
- 将模式错误处理（任务对话框或消息框）用于所有其他问题， 包括涉及多个控件的错误，或者通过单击提交按钮找到的非上下文或非输入错误。
- 报告用户输入问题时，使用不正确的数据将输入焦点设置为第一个控件。 如有必要，将控件滚动到视图中。 如果控件是文本框，请选择整个内容。 应始终清楚错误消息所指的内容。
- 不要清除不正确的输入。 请保留它，以便用户无需开始即可查看并更正问题。
- 例外： 清除不正确的密码和 PIN 文本框，因为用户无法有效地更正屏蔽的输入。
故障排除
- 避免创建故障排除问题。 不要依赖单个错误消息来报告多个不同可检测原因的问题。
- 对每个可检测的原因使用不同的错误消息（通常是不同的补充说明）。 例如，如果由于多种原因无法打开文件，请为每个原因提供单独的补充说明。
- 仅当无法确定特定原因时，才使用具有多个原因的消息。 在这种情况下，请提供解决方案，以便解决问题的可能性。 这样做有助于用户更有效地解决问题。
图标
模式错误消息对话框没有标题栏图标。 标题栏图标用作主窗口和辅助窗口之间的可视区别。
使用错误图标。 异常：
如果错误是使用模式对话框或气球显示的用户输入问题，请不要使用图标。 这样做与 Windows 令人鼓舞的语气相反。 但是，就地错误消息应使用小错误图标（16x16 像素）来明确标识它们作为错误消息。
在这些示例中，用户输入问题不需要错误图标。
在此示例中，就地错误消息需要一个小错误图标才能清楚地将其标识为错误消息。
如果问题适用于具有图标（而不是用户输入问题）的功能，则可以将功能图标与错误覆盖一起使用。 如果执行此作，请使用功能名称作为错误的主题。
在此示例中，功能图标具有错误覆盖，并且该功能是错误的主题。
不要对错误使用警告图标。 这通常是为了使演示文稿感觉不那么严重。 错误不是警告。
不正确：
在此示例中，错误地使用了警告图标来使错误感觉不太严重。
有关更多指南和示例，请参阅 标准图标。
渐进式披露
- 使用“显示/隐藏详细信息渐进式披露”按钮隐藏错误消息中的高级或详细信息。 这样做简化了典型用法的错误消息。 不要隐藏所需的信息，因为用户可能找不到它。
在此示例中，渐进式披露按钮可帮助用户向下钻取详细信息（如果需要）或简化 UI（如果没有）。
- 请勿使用显示/隐藏详细信息，除非确实存在更多详细信息。 不要只以更详细的格式重述现有信息。
- 请勿使用“显示/隐藏详细信息”来显示帮助信息。 请改用帮助链接。
有关标记准则，请参阅 渐进式披露控制。
不要再次显示此消息
- 如果错误消息需要此选项，请重新考虑错误及其频率。 如果它具有良好错误的所有特征（相关、可作且不频繁），则用户不应禁止显示错误。
有关更多指南，请参阅 对话框。
默认值
- 选择最安全、最不破坏性或最安全的响应作为默认值。 如果安全性不是一个因素，请选择最有可能或最方便的命令。
帮助
- 设计错误消息以避免需要帮助。 通常，用户不必阅读外部文本才能理解和解决问题，除非解决方案需要几个步骤。
- 确保帮助内容相关且有用。 它不应是错误消息的详细重述，而是应包含超出错误消息范围的有用信息，例如避免将来出现问题的方法。 不要只是因为你可以提供帮助链接。
- 使用特定、简洁、相关的帮助链接访问帮助内容。 请勿出于此目的使用命令按钮或渐进式披露。
- 对于无法使特定和可作的错误消息，请考虑提供指向联机帮助内容的链接。 通过执行此作，你可以向用户提供可在程序发布后更新的其他信息。
有关更多指南，请参阅 “帮助”。
错误代码
- 对于无法使特定和可作的错误消息，或者它们受益于“帮助”，请考虑同时提供错误代码。 用户通常使用这些错误代码在 Internet 上搜索其他信息。
- 始终提供问题和解决方案的文本说明。 不要只依赖于错误代码实现此目的。
不正确：
在此示例中，错误代码用作解决方案文本的替代方法。
- 为每个不同原因分配唯一错误代码。 这样做可以避免进行故障排除。
- 选择易于在 Internet 上搜索的错误代码。 如果使用 32 位代码，请使用带前导“0x”和大写字符的十六进制表示形式。
正确：
1234
0xC0001234
不正确：
-1
-67113524
- 使用“显示/隐藏详细信息”显示错误代码。 短语为错误代码：
<error code>.
在此示例中，错误代码用于补充可从进一步信息中获益的错误消息。
声音
- 不要附带带有声音效果或蜂鸣声的错误消息。 这样做是令人不和谐和不必要的。
- 例外： 如果问题对计算机作至关重要，则播放“严重停止”声音效果，用户必须立即采取措施，防止严重后果。
Text
常规
- 删除冗余文本。 在标题、主要说明、补充说明、命令链接和提交按钮中查找它。 通常，在说明和交互式控件中保留全文，并从其他地方删除任何冗余。
- 使用用户为中心的说明。 在用户作或目标方面描述问题，而不是在软件不满意方面。 使用目标用户理解和使用的语言。 避免使用技术术语。
不正确：
正确：
在这些示例中，正确的版本讲出用户的语言，而不正确的版本过于技术化。
-
不要使用以下单词：
- 错误，失败（改用问题）
- 未能（无法使用）
- 非法、无效、错误（改用不正确）
- 中止、终止、终止（改用停止）
- 灾难性的致命（改用严重）
这些术语是不必要的，与 Windows 令人鼓舞的语气相反。 正确使用时，错误图标足以传达存在问题。
不正确：
正确：
在不正确的示例中，不需要术语“灾难性”和“失败”。
- 不要使用归咎于用户或暗示用户错误的措辞。 避免在措辞中使用你和你的措辞。 虽然主动语音通常是首选语音，但当用户是主题时使用被动语音，如果在使用活动语音时可能会感到被指责为错误。
不正确：
正确：
不正确的示例通过使用活动语音来指责用户。
- 具体说明。 避免模糊措辞，例如语法错误和非法作。 提供涉及的对象的特定名称、位置和值。
不正确：
找不到文件。
磁盘已满。
值范围不足。
字符无效。
设备不可用。
使用特定名称、位置和值可以更轻松地解决这些问题。
- 不要在尝试特定时提供可能不太可能的问题、原因或解决方案。 除非问题、原因或解决方案可能是正确的，否则请不要提供问题、原因或解决方案。 例如，最好说发生未知错误比可能不准确的内容。
- 避免“请”一词， 除非要求用户执行不方便（如等待）或软件负责的情况。
正确：
请等待 Windows 将文件复制到计算机。
- 仅在导致用户严重问题的错误消息中使用“抱歉”一词 （例如数据丢失或无法使用计算机）。 如果在程序正常运行期间出现问题（例如，如果用户需要等待找到网络连接），请不要道歉。
正确：
很抱歉，Fabrikam 备份检测到无法恢复的问题，并已关闭以保护计算机上的文件。
- 使用其短名称引用产品。 请勿使用完整的产品名称或商标符号。 除非用户将公司名称与产品关联，否则不要包含公司名称。 不包括程序版本号。
不正确：
正确：
在不正确的示例中，使用完整的产品名称和商标符号。
- 对对象名称使用双引号。 这样做会使文本更易于分析和避免可能令人尴尬的语句。
- 例外： 完全限定的文件路径、URL 和域名无需双引号。
正确：
在此示例中，如果对象名称没有引号，则错误消息将令人困惑。
- 避免使用对象名称启动句子。 这样做通常很难分析。
- 不要对所有大写字母使用感叹号或单词。 感叹号和大写字母让你感觉你对用户大喊大叫。
有关更多指南和示例，请参阅 Style 和 Tone。
标题
- 使用游戏标识错误源自的命令或功能。 异常：
- 如果许多不同的命令显示错误，请考虑改用程序名称。
- 如果该游戏会冗余或与主指令混淆，请改用程序名称。
- 不要使用标题来解释或汇总 主要指令的目的问题。
不正确：
在此示例中，游戏错误地用于解释问题。
- 使用标题样式大写，无需结束标点符号。
主要说明
- 使用主要说明以明文、明文、特定语言描述问题。
- 请简洁地只使用单个完整句子。 将主要指令分析为基本信息。 如果主题是程序或用户，则可以隐式保留主题。 如果可以简洁地执行此作，请包括问题的原因。 如果必须解释更多内容，请使用补充说明。
不正确：
在此示例中，整个错误消息都放在主指令中，使其难以阅读。
- 如果涉及对象，请指定其名称。
- 避免在主指令中放置完整的文件路径和 URL。 相反，请使用短名称（如文件名），并将全名（如文件路径）放在补充说明中。 但是，如果错误消息不需要补充说明，则可以在主指令中放置单个完整文件路径或 URL。
在此示例中，只有文件名位于主指令中。 完整路径位于补充说明中。
- 如果上下文中很明显，请不要提供完整的文件路径和 URL。
在此示例中，用户正在从 Windows 资源管理器重命名文件。 在这种情况下，不需要完整的文件路径，因为上下文中很明显。
- 尽可能使用当前时态。
- 使用句子样式大写。
- 如果指令是语句，请不要包含最后句点。 如果指令是问题，请包含最终问号。
主要指令模板
虽然没有严格的措辞规则，但尽可能尝试使用以下主要指令模板：
- [可选使用者名称] 无法 [执行作]
- [可选使用者名称] 无法 [执行作] 因为 [原因]
- [可选使用者名称] 无法 [执行作] 到 “[对象名称]”
- [可选使用者名称] 无法 [执行作] “[对象名称]”，因为 [reason]
- 没有足够的 [资源] [执行作]
- [使用者名称] 没有 [目的] 所需的 [对象名称]
- [设备或设置] 已关闭，以便 [不需要的结果]
- [设备或设置] 未 [可用 | 找到 | 已启用 | 已启用]
- “[对象名称]”当前不可用
- 用户名或密码不正确
- 您无权访问“[对象名称]”
- 您无权 [执行作]
- [程序名称] 已遇到严重问题，必须立即关闭
当然，根据需要进行更改，使主指令在语法上正确无误，并遵守主要指令准则。
补充说明
- 使用补充说明可以：
- 提供有关问题的其他详细信息。
- 解释问题的原因。
- 列出用户可以执行哪些步骤来解决问题。
- 提供防止问题重新出现的措施。
- 尽可能提出一个实用且有用的解决方案，以便用户能够解决问题。 但是，请确保建议的解决方案可能会解决问题。 不要通过建议可能但不可能的解决方案浪费用户的时间。
不正确：
在此示例中，虽然问题及其建议的解决方案是可能的，但它们不太可能。
- 如果问题是用户输入的错误值，请使用补充说明解释正确的值。 用户不必从另一个源确定此信息。
- 如果无法从问题陈述中推断出解决方案，请不要提供解决方案。
在此示例中，不需要补充说明;解决方案可以从问题语句中简单推断出来。
- 如果解决方案具有多个步骤，请按照完成步骤的顺序演示这些步骤。 但是，请避免使用多步骤解决方案，因为用户难以记住两三个以上的简单步骤。 如果需要更多步骤，请参阅相应的帮助主题。
- 保持补充说明简洁。 仅提供用户需要知道的内容。 省略不必要的详细信息。 目标为最多三个中等长度的句子。
- 若要避免用户在执行指令时出错，请将结果放在作之前。
正确：
若要重启 Windows，请单击“确定”。
不正确：
单击“确定”重启 Windows。
在不正确的示例中，用户更有可能意外单击“确定”。
- 建议不要联系管理员，除非这样做是解决问题的最可能的解决方案之一。 为管理员只能解决的问题保留此类解决方案。
不正确：
在此示例中，很可能问题与用户的网络连接有关，因此不值得联系管理员。
- 不建议联系技术支持。 联系技术支持解决问题的选项始终可用，无需通过错误消息进行升级。 而是专注于编写有用的错误消息，以便用户无需联系技术支持即可解决问题。
不正确：
在此示例中，错误消息错误地建议联系技术支持。
- 使用完整的句子、句子样式大写和结束标点符号。
提交按钮
- 如果错误消息提供解决该问题的命令按钮或命令链接，请按照 对话框中的相应准则进行作。
- 如果程序必须因错误而终止，请提供退出程序按钮。 为了避免混淆，请勿将 Close 用于此目的。
- 否则，请提供“关闭”按钮。 不要对错误消息使用 OK，因为此措辞意味着问题正常。
- 例外： 如果错误报告机制具有固定标签（与 MessageBox API 一样），请使用 OK。
文档
引用错误时：
- 按主要说明引用错误。 如果主要指令较长或详细，请对其进行汇总。
- 如有必要，可以引用错误消息对话框作为消息。 仅在编程和其他技术文档中引用错误消息。
- 如果可能，请使用加粗格式设置文本的格式。 否则，仅当需要防止混淆时，才将文本置于引号中。
例： 如果 驱动器消息中没有 CD 光盘 ，请在驱动器中插入新的 CD 光盘，然后重试。