确认

注意

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

确认是一个模式对话框，询问用户是否要继续执行作。

典型的确认。

确认具有以下基本特征：

• 它们显示为用户启动的作的直接结果。
• 他们验证用户是否要继续执行该作。
• 它们由一个简单的问题和两个或多个回答组成。

当作要求用户做出以后无法做出的相关且不同的选择时，确认最有用。 这种选择通常涉及一些对用户不明显的风险元素，但风险对确认并不重要。 需要这些元素来证明响应模式对话的中断是正当的。

相比之下，警告消息 存在可能导致将来出现问题的条件。 他们的基本特征是，它们涉及风险：

• 它们涉及以下一个或多个潜在损失：
  • 有价值的资产，如数据丢失或财务损失。
  • 系统访问或完整性。
  • 隐私或控制机密信息。
  • 用户的时间（大量，如 30 秒或更多）。
• 他们有意想不到的或意想不到的后果。
• 它们现在需要正确的处理，因为错误不容易修复，甚至可能不可逆。

如果确认涉及风险，也可以将其视为警告。 因此，警告消息准则也适用。

注意： 与 对话框、错误消息、布局以及 警告消息 分别显示在单独的文章中。

这是正确的用户界面吗？

若要决定，请考虑以下问题：

• 用户是否被问及要继续执行有两个或更多响应的作？ 如果没有，则消息不是确认消息。
• UI 是否显示出错或问题？ 如果是，请改用 错误消息。
• 继续执行该作是否要求用户做出没有适当默认值的选择？ 如果是这样，则确认可能合适。
• 是否有替代设计可以消除确认的需要？ 有时需要确认，这表示设计缺陷。 通常有一个更好的设计替代方案，不需要确认。
• 用户是否要执行有风险的作？ 如果是这样，如果作具有重大后果或无法轻易撤消，则确认是适当的。
• 用户是否即将放弃任务？ 如果是这样，请不要确认。 假设用户了解不完成任务的后果。
• 该作是否会产生用户可能不知道的后果？ 如果是这样，则确认可能合适。
• 给定当前上下文，用户是否可能执行错误作？ 如果是这样，则确认可能合适。
• 用户是否经常执行该作？ 如果是这样，请考虑一种替代设计。 频繁的确认令人恼火，几乎没有价值，因为用户无需考虑就学会做出响应。
• 该作是否具有安全影响？ 如果是这样，则即使以前的测试指示其他测试，也可能需要确认。

设计概念

不必要的确认令人恼火

有史以来第一次创建的 Windows 确认无疑如下所示：

的屏幕截图

原始令人恼火的确认。

这是一个非常糟糕的开始。 如果希望用户讨厌你的程序，请在整个过程中洒出这样的确认。 若要了解原因，请考虑用户的观点。 用户只是要求通过确认的定义执行作，因此除非某些内容被意外单击或被意外按下，否则用户当然想要继续作。

不仅不必要的确认令人恼火，而且对保护用户免受错误影响并不有效。 用户快速发现程序何时有不必要的确认，其自然响应是尽快消除它们，通常无需阅读。 因此，此类确认只是为这些任务添加额外的步骤。

不要仅仅因为用户犯了错误而使用确认。 相反，当用于确认具有重大或意外后果的作时，确认效果最有效。 良好的确认从不说明显而易见：他们应该传达用户需要注意的一些不继续的好理由。 并且仅当实际需要某个作时才使用它们，例如，仅当存在值得保存的更改时，才要求用户保存更改。 仅当真正需要时，这样做才需要用户的注意。

对于其他类型的确认，通常有一个比强制用户回答问题更好的设计替代方法。

考虑设计替代项

下面是一些设计替代方法，无需进行例程确认：

• 防止错误。 设计任务，使重大错误难以意外执行。 例如，在物理上将破坏性命令与其他命令分开，并且需要多个作才能完成。
• 提供撤消。 提供还原作的功能。 例如，删除Microsoft Windows 中的文件通常不需要确认，因为可以从回收站恢复已删除的文件。 请注意，如果作很容易执行，只需让用户重新执行该作就足够了。
• 提供反馈。 使不良结果变得明显。 如果用户在犯错误时没有意识到，单独提供撤消是不够的。 例如，直接作（如拖放作）的效果应始终很明显。
• 假设可能的结果，但易于更改。 如果你不确定用户想要什么，但有一个可能、安全和安全的选择，假设该选择，明确发生了什么情况，并使用上下文菜单轻松更改。 例如，Microsoft Word 假定用户希望正确拼写单词。 如果它识别拼写错误的单词并且它知道可能正确的拼写，Word 会自动进行更正，但允许用户还原。
• 完全消除选择。 如果选择不重要，用户只是不会关心。 更好地 简化 程序并消除选择。

进行确认需要思考

若要获得值确认，用户需要了解不继续的原因。 有时，原因显而易见，因为当用户关闭包含尚未保存的更改的文档时：

在此示例中，确认的原因很明显。

在其他情况下，原因可能不太明显。

选择对话框的提交按钮标签时，一般准则 是选择对主指令的特定响应的标签。 这会导致做出有效的决策，因为用户必须读取最少的文本才能继续。 但是，对于确认，这种效率目标可能会适得其反。 请考虑以下示例：

不正确：

使用卸载按钮屏幕截图

在此示例中，正确的响应需要思考。

如果在用户提供 Uninstall 命令后立即显示此确认，则用户的响应可能是“当然我想卸载！”用户将单击“卸载”而不给出第二个想法。

对于确认，我们不希望用户做出匆匆、情绪化的决策。 为了鼓励用户思考他们的反应，我们需要提供一个小的决策速度颠簸。 如果可行，通常最好通过仔细措辞提交按钮来执行此作。 例如，我们可以使用其他语言来指示有理由不继续。

更好：

“卸载”按钮的屏幕截图

在此示例中，“无论如何”将添加到提交按钮标签，以指示确认提供了不继续的理由。

如果这种方法不实用，则可以使用“是/否”提交按钮。

也更好：

使用“是/否”按钮

在此示例中，使用“是/否”提交按钮强制用户至少阅读主指令。

提供所有信息

如果要提出问题，则必须为用户提供足够的信息，以便用户以智能地回答该问题。 请考虑 Windows XP 中的“确认文件替换”对话框：

屏幕截图

Windows XP 确认文件替换对话框。

此确认是否提供用户可能需要回答问题的所有信息？ 在回答之前，请考虑最常见的用户方案：

• 复制（或移动）另一个文件，替换现有文件。
• 保留现有文件，而不复制或移动另一个文件。
• 保留或复制较新的文件（顶部方案）。
• 保留现有文件或复制另一个文件，具体取决于文件内容和大小等条件。
• 保留现有文件，并使用其他名称复制其他文件。
• 如果出现错误或意外情况，请取消该作。

用户可以通过单击“是”和“方案 2”来达到方案 1，方法是单击“否”。 他们可以通过比较文件日期并单击相应的按钮来实现方案 3，但请注意确定较新的文件需要多少时间，然后确定适当的按钮，尤其是最常见方案。

方案 4、5 和 6 也出人意料地困难。 文件大小被舍入，因此，例如，无法确定这些文件的大小是否相同，或者即使这些文件是相同的文件。 图标适用于用于打开文件的应用程序，因此用户必须打开文件才能检查和比较其内容。 拥有文件内容的缩略图在回答问题时会更加有用。

Windows Vista 中的“复制文件”确认通过提供更多信息并添加用于保留这两个文件的选项来更好地处理这些方案：

屏幕截图

Windows Vista 复制文件确认。

提供特定、有用的信息

如果要提出问题，请确保用户了解问题以及替代响应的含义。 请考虑以下 Windows Internet Explorer 安全确认：

模糊的安全确认。

此确认询问了用户无法智能回答的问题。 用户已请求 Windows Internet Explorer 显示页面，并且此消息通过文本的措辞隐式建议，并通过突出显示“否”作为默认选择来隐式反对它。

页面构成的特定安全问题尚未充分解释，因此继续的风险尚不清楚。 确认中哪些信息会导致用户单击“否”？ 由于消息的模糊性，确认不太可能阻止用户继续，但会让他们对这样做感到不好。

要使此确认有用，它必须提供更多信息特定的信息，可能导致用户决定不继续。 通常，对于确认中的每个响应，请考虑需要它的方案，并确保为用户提供足够的信息来选择要选择它。 提供选择，而不是困境。

如何确定是否需要确认

思考方案以及选择每个响应的可能性表明有系统的方式来确定是否需要确认。 如果用户可能选择所有响应，则确认是必需的且有用。 但是，如果只有一个响应可能（例如 98% 的时间），则确认显然是不必要的，应该删除。 请注意，与安全、法律和安全问题相关的确认可能是例外情况。

此确认是否是必需的？ 用户是否会选择“否”？ 这是可能的， 但非常不可能。 应删除此确认。

如果你只做三件事...

1. 确保确认确实是必需的。 应该有合法和明确的理由不继续，有时用户不会这样做。

2. 如果确认原因并不明显，请选择鼓励用户考虑其响应的提交按钮。 通常，这是通过措辞确认为是或否，并提供完全自我解释或是/否答案来完成。

3. 考虑所有方案，并提供智能回答问题所需的信息。

使用模式

确认有多个使用模式：

用法	例
例程确认 确认用户想要继续执行常规的低风险作。	这些确认通常短语为“你确定...？”，并且通常没有再次显示此消息的复选框，以尽量减少他们的烦恼。 屏幕截图 例程确认示例。 注意： 此模式通常是不必要的，应避免。
风险作确认 确认用户想要继续执行有一定风险且无法轻松撤消的作。	由于它们有风险，因此这些确认通常具有警告图标。 风险作确认的示例。
意外的后果确认 确认用户想要继续执行具有意外或意外后果的作。	除了提出问题外，这些确认还指出了意外的后果。 由于它们会产生意外的后果，因此这些确认通常具有警告图标。 “关闭所有选项卡？”确认 “取消安装？”确认 意外结果确认的示例。 但是，此模式要求后果确实是意外的。 不正确： 屏幕截图 后果在此处进行，因此这是例行确认。
澄清 阐明用户希望如何继续执行具有潜在模糊或意外后果的作。	拖放作可能会导致说明作的效果是否可能被误解。 屏幕截图 说明示例。 注意：应避免 此模式，因为最好设计作而不产生模棱两可的后果，并假定最可能的结果。
安全确认 确认用户希望继续执行具有安全后果的作。	屏幕截图 安全确认的示例。
Ulterior 动机确认 提供有关作的信息，但将其显示为确认。	虽然这些对话框显示为确认，但他们的真正目标是用户教育或功能广告。 ulterior 动机确认的示例。 注意： 不建议使用此模式，因为通常有更好的、更直接的替代方法。 例如，动画 是显示原因和效果之间的关系的更好方法。

指引

常规

• 仅当发生重大更改时，才使用“保存更改”确认。 请勿确认用户未直接进行的更改，例如自动文档重新格式化。

不正确：

对于用户未更改的空电子邮件或文档，此示例不正确。

图标

• 确认不使用标题栏图标。

• 确认的内容区域图标基于其设计模式：

  模式	图标
  例程确认	无图标。
  风险作确认	警告图标。
  意外的后果确认	如果存在风险，请使用警告图标;如果可用，则使用功能图标;否则，无图标。
  澄清	如果确认涉及文档，请使用文档的缩略图;否则，请使用功能图标（如果可用）或无图标。
  安全确认	警告图标。
  Ulterior 动机确认	无图标。

• 不要对常规问题使用警告图标。 这样做与 Windows 令人鼓舞的 语气相反，并使你的程序感觉就像是一种危险的活动。 假设用户了解在任务完成之前取消任务的后果。

不正确：

在此示例中，警告图标用于提出例行问题。

提交按钮

• 如果确认原因明显或可以作出自我解释，请使用对主要指令的特定响应。

在此示例中，确认的原因很明显，因此“保存”和“不保存”效果良好。

• 否则，请使用“是”和“否”按钮进行确认响应。 这样做会使用户在响应之前给出一些想法。 切勿使用“确定”和“取消”进行确认。

正确：

屏幕截图

在此示例中，使用“是/否”提交按钮强制用户至少阅读主指令。

不正确：

屏幕截图

在此示例中，使用 OK/Cancel 令人困惑。

• 若要关闭程序或重启 Windows，请使用主要指令的特定响应。 若要防止任何误解，请不要出于此目的使用 Close 或 Yes/No。

正确：

不正确：

“是”按钮的

在不正确的示例中，是用于重启 Windows。

命令链接

• 有关澄清模式，请考虑使用命令链接来明确替代方法。

可接受：

更好：

使用命令链接相同问题的屏幕截图

在更好的示例中，命令链接使替代项更加清晰。

• 首先提供最常用的命令链接。 生成的顺序应大致遵循使用的可能性，但也具有逻辑流。
• 如果命令链接需要进一步说明，提供补充说明。 补充说明说明用户为何可能想要选择该选项，或者选择该选项时会发生什么情况。

有关更多指南和示例，请参阅 命令链接。

默认值

• 确认的默认响应基于其设计模式：

  模式	默认响应
  例程确认	进行。
  风险作确认	不要继续（或安全选择）。
  意外的后果确认	如果后果很大，请不要继续;否则，请继续。
  澄清	最有可能的响应。
  安全确认	不要继续。
  Ulterior 动机确认	进行。

不要再次显示此消息

• 仅对例程和 ulterior 动机确认模式使用此选项。 对于其他模式，如有必要，应始终显示信息。
• 不要提供此选项来证明显示不必要的确认是正当的。 只是摆脱确认。

不正确：

仍然不正确：

屏幕截图

在这些示例中，添加“不要再次显示此消息”选项不会修复不必要的确认。

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

批量作

• 对于适用于批量作的确认，请提供将确认应用于整个作的选项。

屏幕截图

此示例提供批量作选项。

• 在批量作中消除或推迟确认。

不正确：

在此示例中，Windows XP 中的 Windows 资源管理器在批量文件移动过程中确认每个只读文件。 最好复制只读文件而不询问，或推迟处理这些文件，并在任务结束时显示确认。

渐进式披露

• 如果必须在确认消息中包含高级信息，请使用渐进式披露按钮（例如，“显示详细信息”）来显示它。 这样做简化了典型用法的确认。 不要隐藏所需的信息，因为用户可能无法找到它。
• 请勿使用“显示详细信息”，除非确实存在更多详细信息。 不要只以不同的格式重述现有信息。

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

用户帐户控制

• 请勿将用户帐户控制（UAC）提升 UI 用作确认的替代项。 如果作需要确认，请使用单独的对话框。 在 提升 UI期间，用户需要专注于他们是否启动任务以及程序是否可信。
• 在提升 UI 之前显示确认。 这样做可以消除不必要的提升。

发短信

常规

• 删除冗余文本。 在标题、主要说明、补充说明、内容区域、命令链接和提交按钮中查找冗余文本。 通常，在说明和交互式控件中保留全文，并从其他地方删除任何冗余。
• 不要在文本中使用“警告”或“警告”。 如果用户需要谨慎行事，请改用警告图标指示这一点。

不正确：

批量格式确认屏幕截图

在此示例中，不需要术语“warning”。

标题

• 使用游戏标识确认来自的命令或功能。 异常：
  • 如果确认由许多不同的命令显示，请考虑改用程序名称。
  • 如果该游戏会冗余或与主指令混淆，请改用程序名称。

但是，如果确认来自长时间运行的任务，并且可能在任务启动后显示良好，请始终使用命令或功能来清楚地识别上下文。

• 不要使用标题来解释对话中要执行的作 这是主要说明的目的。
• 如果增加了清晰度，请使用“确认”一词启动标题。
• 对于有风险的作确认，可以添加涉及额外强调的对象的名称。

屏幕截图

在此示例中，要格式化的驱动器包含在标题中。

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

主要说明

• 确认的主要说明基于其设计模式：

  模式	主要说明
  意外的后果确认	说明意外的后果。 异常： 如果询问用户是否希望继续的问题明确暗示意外后果，请改为提问。 “关闭所有选项卡？”确认 在此示例中，要求用户继续充分传达作的后果。
  所有其他内容	提出一个问题以确定用户是否要继续。

• 请简洁地只使用单个完整句子。 将主要指令条带到基本信息。 如果必须解释更多内容，请使用补充说明。

• 如果涉及对象，请指定其全名。

• 使用正短语。 用户更容易理解积极措辞。

正确：

是否要启用文件和打印机共享？

不正确：

是否要禁用文件和打印机共享？

但是，短语必须与关联的命令匹配，即使命令是负短语：因此，例如，使用 disable 确认 Disable 命令。

• 虽然没有严格的措辞规则，但 这些常见的确认短语具有指示的内涵：

  短语	内涵
  是否确实要[执行作]？	确认用户请求的直接结果。
  是否要[执行作]？	确认用户请求的副作用。
  是否要 [选择结果]？	需要澄清。
  [执行作]？	无内涵。

• 对于有风险的作确认，请使用术语永久指示无法撤消作。

永久删除确认屏幕截图

在此示例中，“永久”表示无法撤消作。

• 使用 句子样式大写。

补充说明

• 确认的补充说明基于其设计模式：

标签	价值
模式	补充说明
意外的后果确认	提出一个问题以确定用户是否要继续。
所有其他内容	解释用户可能不想继续的任何非明显原因。 此类原因包括： 以下一个或多个潜在损失： 有价值的资产，如数据丢失或财务损失。 系统访问或完整性。 隐私或控制机密信息。 不可逆的作。

• 不要用略有不同的措辞重复主指令。 相反，如果不添加更多内容，请省略补充说明。
• 对于意外的后果确认，请考虑使用术语来简明地指示在用户忽略主指令的情况下，没有理由继续。 有关详细信息，请参阅设计概念。
• 使用完整的句子、句子样式大写和结束标点符号。

文档

引用确认时：

• 如果游戏特定于确认（即，而不是程序名称），请参阅其标题的确认;否则，请通过主要指令引用它。
• 如有必要，可以引用确认对话框作为消息。
• 使用确切的文本，包括其大写。
• 如果可能，请使用加粗格式设置文本的格式。 否则，仅当需要防止混淆时，才将文本置于引号中。

示例：在 复制文件 消息中，单击较新的文件。