确认
注意
此设计指南是为 Windows 7 创建的，尚未针对较新版本的 Windows 进行更新。 大部分指南原则上仍然适用，但演示和示例并不反映我们 当前的设计指南。
确认是一个模式对话框，询问用户是否要继续执行操作。
典型的确认。
确认具有以下基本特征：
- 它们显示为用户启动的操作的直接结果。
- 验证用户是否要继续执行操作。
- 它们包括一个简单的问题和两个或更多个响应。
当操作要求用户做出稍后无法做出的相关且不同的选择时，确认最有用。 该选择通常涉及一些对用户来说并不明显的风险元素，但风险对确认并不重要。 为了证明响应模式对话的中断，这些元素是必需的。
相比之下， 警告消息 会呈现可能导致将来出现问题的条件。 它们的基本特征是它们涉及风险：
- 它们涉及以下一项或多项的潜在损失：
- 有价值的资产，例如数据丢失或财务损失。
- 系统访问或完整性。
- 隐私或对机密信息的控制。
- 用户的时间 (相当长的时间，例如 30 秒或更多) 。
- 它们会产生意外或意外的后果。
- 它们现在需要正确处理，因为错误不容易修复，甚至可能是不可逆的。
如果确认涉及风险，也可以将其视为警告。 因此，警告消息指南也适用。
注意： 单独的文章中提供了与 对话框、 错误消息、 布局和 警告消息 相关的指南。
这是正确的用户界面吗？
在决定之前，请考虑以下问题：
- 是否询问用户继续执行具有两个或更多响应的操作的问题？ 如果不是，则消息不是确认。
- UI 是否显示已发生的错误或问题？ 如果是，请改用 错误消息 。
- 继续操作是否需要用户做出没有合适的默认值的选择？ 如果是这样，则确认可能合适。
- 是否有替代设计可以消除确认需求？ 确认的需要有时表示存在设计缺陷。 通常有一个更好的设计替代方案，不需要确认。
- 用户是否要执行有风险的操作？ 如果是这样，如果操作具有重大后果或无法轻易撤消，则进行确认是合适的。
- 用户是否要放弃任务？ 如果是，请不要确认。 假设用户了解未完成任务的后果。
- 操作是否会产生用户可能不知道的后果？ 如果是这样，则确认可能合适。
- 鉴于当前上下文，用户是否可能错误地执行操作？ 如果是这样，则确认可能合适。
- 用户是否经常执行操作？ 如果是，请考虑替代设计。 频繁的确认很烦人，而且没有什么价值，因为用户学会了不考虑就做出响应。
- 该操作是否具有安全隐患？ 如果是这样，则可能需要确认，即使前面的测试指示了其他情况。
设计概念
不必要的确认很烦人
创建的第一个 Windows 确认无疑如下所示：
原始烦人的确认。
这是一个非常糟糕的开始。 如果希望用户讨厌你的程序，只需在整个过程中撒上这样的确认。 若要了解原因，请考虑用户的观点。 用户刚刚要求根据确认的定义执行操作，因此除非以某种方式意外单击或按下某些内容，否则用户当然要继续。
不必要的确认不仅令人讨厌，而且在保护用户免受错误方面并不有效。 用户可快速发现程序何时有不必要的确认，其自然响应是尽快消除它们，通常无需阅读。 因此，此类确认只能为这些任务添加额外的步骤。
不要仅仅因为用户可能犯错而使用确认。 相反，当用于确认具有重大或意外后果的操作时，确认最有效。 好的确认永远不会说明显而易见的：他们应该传达一些用户需要知道不继续的充分理由。 并且它们仅在操作真正需要时才使用，例如，仅当存在值得保存的更改时，才要求用户保存更改。 只有在真正有保障的情况下，这样做才需要用户的注意。
对于其他类型的确认，通常有一种比强制用户回答问题更好的设计方法。
考虑设计替代方案
下面是一些设计替代方案，无需进行例行确认：
- 防止错误。 设计任务，使重大错误难以意外执行。 例如，在物理上将破坏性命令与其他命令分开，并且需要执行多个操作才能完成。
- 提供撤消。 提供还原操作的功能。 例如，在 Microsoft Windows 中删除文件通常不需要确认，因为已删除的文件可以从回收站中恢复。 请注意，如果操作很容易执行，只需让用户重做该操作就足够了。
- 提供反馈。 使不良结果变得明显。 如果用户在犯错误时没有意识到，仅提供撤消是不够的。 例如，直接操作 (（例如拖放操作) ）的效果应始终明显。
- 假设可能的结果，但要使其易于更改。 如果你不确定用户想要什么，但有一个可能、安全和安全的选择，假设该选择，请明确所发生的情况，并使用上下文菜单轻松进行更改。 例如，Microsoft Word假定用户希望正确拼写单词。 如果识别拼写错误的单词并且知道拼写可能正确，Word会自动进行更正，但允许用户还原。
- 完全消除选择。 如果选择不重要，用户就不会在乎。 更好的是 简化 程序并消除选择。
需要深思的确认
若要使确认具有值，用户需要了解不继续操作的原因。 有时原因显而易见，就像用户关闭文档时未保存的更改一样：
在此示例中，确认的原因显而易见。
在其他情况下，原因可能不那么明显。
为对话框选择提交按钮标签时，一般准则是选择对main指令的特定响应的标签。 这会导致有效的决策制定，因为用户必须阅读最少的文本才能继续。 但是，对于确认，此效率目标可能会适得其反。 请看以下示例：
不正确：
在此示例中，需要思考正确的响应。
如果在用户发出 Uninstall 命令后立即显示此确认，则用户的响应可能是“当然我想卸载！”用户将单击“卸载”，无需再考虑一下。
对于确认，我们不希望用户做出仓促、情绪激动的决定。 为了鼓励用户考虑他们的响应，我们需要提供一个小小的决策速度颠簸。 如果可行，通常最好通过仔细措辞提交按钮来执行此操作。 例如，我们可以使用其他语言来指示有理由不继续。
良好：
在此示例中，“无论如何”将添加到提交按钮标签，以指示确认提供了不继续的理由。
如果此方法不实用，可以使用“是/否”提交按钮。
也更好：
在此示例中，使用“是/否”提交按钮强制用户至少阅读main指令。
提供所有信息
如果要提出问题，则必须为用户提供足够的信息，以便智能地回答该问题。 请考虑 Windows XP 中的“确认文件替换”对话框：
“Windows XP 确认文件替换”对话框。
此确认是否提供了用户回答问题所需的所有信息？ 在回答之前，请考虑最常见的用户方案：
- 复制 (或移动) 另一个文件，替换现有的文件。
- 保留现有文件，不复制或移动其他文件。
- 保留或复制较新的文件 (首要方案) 。
- 保留现有文件或复制其他文件，具体取决于文件内容和大小等条件。
- 保留现有文件，并使用其他名称复制另一个文件。
- 如果出现错误或意外情况，请取消操作。
用户可以通过单击“是”和“方案 2”否“来实现方案 1。 他们可以通过比较文件日期并单击相应的按钮来实现方案 3，但请注意确定较新的文件需要花费多少时间，然后确定适合的按钮，特别是对于可能最常见的方案。
方案 4、5 和 6 也非常困难。 文件大小是舍入的，因此，例如，无法确定这些文件的大小是否相同，甚至它们是否是同一个文件。 图标适用于用于打开文件的应用程序，因此用户必须打开文件才能检查和比较其内容。 拥有文件内容的缩略图在回答问题时会更有用。
Windows Vista 中的“复制文件”确认通过提供更多信息并添加用于保留这两个文件的选项，在处理这些方案方面做得更好：
Windows Vista 复制文件确认。
提供具体有用的信息
如果要提出问题，请确保用户了解问题以及替代响应的影响。 请考虑以下 Windows Internet Explorer 安全确认：
模糊的安全确认。
此确认会询问用户无法智能回答的问题。 用户已请求 Windows Internet Explorer 显示一个页面，并且此消息通过文本的措辞和突出显示“否”作为默认选项来隐式建议不要显示该页面。
页面造成的特定安全问题没有充分解释，因此无法明确继续存在的风险。 确认中的哪些信息会导致用户单击“否”？ 由于消息的模糊性，确认不会阻止用户继续操作，但会让他们感到不舒服。
若要使此确认有用，它必须提供可能导致用户决定不继续的详细信息特定信息。 通常，对于确认中的每个响应，请考虑需要它的方案，并确保有足够的信息供用户选择它。 提供选择，而不是两难境地。
如何确定确认是否必要
通过考虑方案和选择每个响应的可能性，可以系统地确定是否需要确认。 如果用户可能选择所有响应，则确认是必要且有用的。 但是，如果只有一个响应可能 (98% 的时间) ，则确认显然是不必要的，应该删除。 请注意，与安全性、法律和安全问题相关的确认可能是例外情况。
是否需要进行此确认？ 用户是否会选择“否”？ 这是可能的，但非常不可能。 应删除此确认。
如果你只做三件事...
确保确实有必要进行确认。 应该有合法且明确的理由不继续，有时用户不会这样做。
如果确认的原因并不明显，请选择鼓励用户考虑其响应的提交按钮。 通常，这是通过将确认措辞为“是”或“否”，并提供完全一目了然或“是/否”的答案来完成。
考虑所有方案，并提供智能回答问题所需的信息。
使用模式
确认有多种使用模式：
| 使用情况 | 示例 |
|---|---|
| 例程确认 确认用户想要继续执行常规的低风险操作。 |
这些确认通常短语为“你确定...？”，并且通常有一个不再显示此消息检查框，以尽量减少他们的烦恼。   例程确认的示例。 注意： 此模式通常是不必要的，应避免。 |
| 风险操作确认 确认用户想要继续执行具有一定风险且无法轻易撤消的操作。 |
由于它们有风险，因此这些确认通常具有警告图标。   风险操作确认的示例。 |
| 意外后果确认 确认用户想要继续执行具有意外或意外后果的操作。 |
除了提出问题外，这些确认还指出了意外的后果。 因为它们具有意外的后果，因此这些确认通常具有警告图标。   意外后果确认的示例。 但是，此模式要求后果确实是意外的。 错误：  后果是此处的，因此这是例行确认。 |
| 说明 阐明用户希望如何继续执行具有潜在不明确或意外后果的操作。 |
如果操作的效果可能被错误解释，拖放操作可能会导致澄清。   说明示例。 注意： 应避免此模式，因为最好在不产生模棱两可的后果的情况下设计操作，并假定最可能的结果。 |
| 安全确认 确认用户想要继续执行具有安全后果的操作。 |
  安全确认的示例。 |
| 别有用动机确认 提供有关操作的信息，但将其呈现为确认。 |
虽然这些对话框显示为确认，但其实际目标是用户教育或功能广告。  别有用动机确认的示例。 注意： 不建议使用此模式，因为通常有更好、更直接的替代方法。 例如， 动画 是显示因果关系更好的方法。 |
准则
常规
- 仅当存在重大更改时，才使用“保存更改”确认。 不要确认用户未直接进行的更改，例如自动文档重新格式化。
不正确：
对于用户未更改的空电子邮件或文档，此示例不正确。
图标
确认不使用标题栏图标。
确认的内容区域图标基于其设计模式：
模式 图标 例程确认 无图标。 风险操作确认 警告图标。 意外后果确认 如果有风险，请使用警告图标;如果可用，请使用功能图标;否则，无图标。 说明 如果确认涉及文档，请使用文档的缩略图;否则，请使用功能图标（如果可用）或无图标。 安全确认 警告图标。 别有用动机确认 无图标。 不要对例行问题使用警告图标。 这样做与 Windows 令人鼓舞的语气相反， 并使使用程序感觉就像一项危险活动。 假设用户了解任务完成前取消任务的后果。
不正确：
在此示例中，警告图标用于提出例行问题。
提交按钮
- 如果确认的原因显而易见，或者可以自行解释，请使用对main指令的特定响应。
在此示例中，确认的原因显而易见，因此保存和不保存工作正常。
- 否则，请使用“是”和“否”按钮进行确认响应。 这样做会使用户在响应之前先对确认进行一些思考。 永远不要使用“确定”和“取消”进行确认。
正确：
在此示例中，使用“是/否”提交按钮强制用户至少阅读main指令。
不正确：
在此示例中，使用 OK/Cancel 会让人感到困惑。
- 若要关闭程序或重启 Windows，请使用对main指令的特定响应。 为防止任何误解，请勿出于此目的使用 Close 或 Yes/No。
正确：
不正确：
在不正确的示例中，“是”用于重启 Windows。
命令链接
- 对于说明模式，请考虑使用命令链接来明确替代方法。
可以接受：
良好：
在更好的示例中，命令链接使替代项变得清晰。
- 首先显示最常用的命令链接。 生成的顺序应大致遵循使用的可能性，但也具有逻辑流。
- 如果命令链接需要进一步说明， 请提供补充说明。 补充说明描述了用户可能想要选择选项的原因，或者选择该选项时会发生什么情况。
有关更多指南和示例，请参阅 命令链接。
默认值
确认的默认响应基于其设计模式：
模式 默认响应 例程确认 进行。 风险操作确认 不要继续 (或安全选择) 。 意外后果确认 如果后果重大，请不要继续：否则，请继续。 说明 最有可能的响应。 安全确认 不要继续。 别有用动机确认 进行。
不再显示此消息
- 仅对例程和别有用动机确认模式使用此选项。 对于其他模式，如果需要信息，应始终显示该信息。
- 不要提供此选项来证明显示不必要的确认。 只需删除确认即可。
不正确：
仍然不正确：
在这些示例中，添加“不再显示此消息”选项不会修复不必要的确认。
有关更多指南，请参阅 对话框。
批量操作
- 对于适用于批量操作的确认，请提供将确认应用于整个操作的选项。
此示例具有用于批量操作的选项。
- 消除或推迟批量操作中的确认。
不正确：
在此示例中，Windows XP 中的 Windows 资源管理器在批量文件移动期间确认每个只读文件。 最好是复制只读文件而不询问，或者推迟处理这些文件并在任务结束时提供确认。
渐进式披露
- 如果必须在确认消息中包含高级信息，请使用渐进式披露按钮 (显示信息，例如“显示详细信息”) 。 这样做可以简化典型用法的确认。 不要隐藏所需的信息，因为用户可能找不到它。
- 除非确实有更多详细信息，否则不要使用“显示详细信息”。 不要只以不同的格式重述现有信息。
有关标记准则，请参阅 渐进式披露。
用户帐户控制
- 请勿使用用户帐户控制 (UAC) 提升 UI 作为确认的替代项。 如果操作需要确认，请使用单独的对话框。 在 提升 UI 期间，用户需要专注于他们是否启动了任务以及程序是否可信。
- 在提升 UI 之前显示确认。 这样做可以消除不必要的提升。
文本
常规
- 删除冗余文本。 在标题、main说明、补充说明、内容区域、命令链接和提交按钮中查找冗余文本。 通常，在说明和交互式控件中保留全文，并删除其他位置的任何冗余。
- 不要在文本中使用“警告”或“警告”。 如果用户需要谨慎继续操作，请改用警告图标来指示这一点。
不正确：
在此示例中，不需要术语“warning”。
标题
- 使用标题标识确认来自的命令或功能。 异常：
- 如果确认由许多不同的命令显示，请考虑改用程序名称。
- 如果该游戏多余或与main指令混淆，请改用程序名称。
但是，如果确认来自长时间运行的任务，并且可能在任务启动后显示良好，请始终使用 命令或功能来清楚地标识上下文。
- 请勿使用标题来解释main指令的对话框中要执行的操作。
- 如果更清晰，请以“确认”一词开头标题。
- 对于有风险的操作确认，可以添加涉及的对象的名称，以便进行额外的强调。
在此示例中，要格式化的驱动器包含在标题中。
- 使用 标题样式大写，不结束标点符号。
主要说明
确认main指令基于其设计模式：
模式 主指令 意外后果确认 说明意外后果。
异常： 如果询问用户是否要继续的问题明确暗示了意外的后果，请改为提出问题。
在此示例中，要求用户继续操作可以充分传达操作的后果。所有其他 提出一个问题以确定用户是否要继续。 简明扼要地使用一个完整句子。 将main指令剥离为基本信息。 如果必须解释更多内容，请使用补充说明。
如果涉及对象，请具体说明，请提供其全名。
使用积极措辞。 积极的措辞更易于用户理解。
正确：
是否启用文件和打印机共享？
不正确：
是否要禁用文件和打印机共享？
但是，措辞必须与关联的命令匹配，即使命令是负短语;例如，使用 disable 确认 Disable 命令。
虽然没有严格的措辞规则， 但这些常见的确认短语具有指示的内涵：
短语 内涵 是否确实要 [执行操作]？ 确认用户请求的直接结果。 是否要 [执行操作]？ 确认用户请求的副作用。 是否要 [选择结果]？ 需要澄清。 [执行操作]？ 无内涵。 对于有风险的操作确认，请永久使用 术语来指示操作无法撤消。
在此示例中，“永久”表示操作无法撤消。
- 使用 句子样式大写。
补充说明
- 确认的补充说明基于其设计模式：
| Label | 值 |
|---|---|
| 模式 |
补充说明 |
| 意外后果确认 |
提出一个问题以确定用户是否要继续。 |
| 所有其他 |
解释用户可能不想继续的任何非明显原因。 此类原因包括：
|
- 不要用略有不同的措辞重复main指令。 相反，如果没有更多要添加的说明，请省略补充说明。
- 对于意外的后果确认，请考虑无论如何使用 术语来简洁地指示，如果用户忽略了main指令，有理由不继续。 有关详细信息，请参阅设计概念。
- 使用完整句子、句子样式大写和结束标点。
文档
引用确认时：
- 如果游戏特定于确认 (，而不是程序名称) ，则引用其标题的确认;否则，请通过其main指令引用它。
- 如有必要，可以将确认对话框引用为消息。
- 使用确切的文本，包括其大写。
- 如果可能，请使用粗体设置文本格式。 否则，仅在需要时才将文本置于引号中以防止混淆。
示例：在 “复制文件” 消息中，单击较新的文件。
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈