确认

备注

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

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

屏幕截图显示了记事本"是否要保存更改?"的屏幕截图。 对话框中指定选项。

典型的确认。

确认具有以下基本特征:

  • 它们显示为用户启动的操作的直接结果。
  • 验证用户是否想要继续操作。
  • 它们由一个简单的问题以及两个或多个响应组成。

当操作要求用户做出相关且不同的选择时,确认最有用,因为以后无法做出这种选择。 这种选择通常涉及一些用户并不明显的风险元素,但风险对于确认并不是必需的。 这些元素是证明响应模式对话中断的合理性所必需的。

相比之下, 警告消息 显示的条件可能会导致将来出现问题。 它们的基本特征是它们涉及风险:

  • 它们涉及以下一个或多个可能丢失:
    • 有价值的资产,例如数据丢失或财务损失。
    • 系统访问或完整性。
    • 隐私或控制机密信息。
    • 用户的时间 (,例如 30 秒或 30 秒) 。
  • 它们会产生意外或意外后果。
  • 它们现在需要正确的处理,因为错误无法轻松修复,甚至可能是不可逆的。

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

注意: 与对话框 、错误消息布局警告消息相关的准则在单独的文章中提供。

这是正确的用户界面吗?

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

  • 用户是否收到问题以继续执行具有两个或多个响应的操作? 如果不是,则消息不是确认消息。
  • UI 是否显示错误或已发生的问题? 如果是这样,请 改为使用错误消息
  • 继续操作是否要求用户做出没有适当默认值的选择? 如果是这样,可能适合进行确认。
  • 是否有替代设计可消除确认需求? 需要确认有时表示存在设计缺陷。 通常,有一种更好的设计替代方法,不需要确认。
  • 用户是否即将执行有风险的操作? 如果是这样,如果操作具有重大后果或无法轻松撤消,则确认是合适的。
  • 用户是否即将放弃任务? 如果是,请不要确认。 假设用户了解不完成任务的后果。
  • 操作是否会产生用户可能不知道的后果? 如果是这样,可能适合进行确认。
  • 鉴于当前上下文,用户是否可能正在出错地执行操作? 如果是这样,可能适合进行确认。
  • 用户是否经常执行此操作? 如果是,请考虑采用替代设计。 频繁的确认很令人麻烦,并且没有价值,因为用户会无心地做出响应。
  • 操作是否具有安全隐患? 如果是这样,可能需要确认,即使前面的测试指示了其他操作。

设计概念

不必要的确认令人麻烦

创建Windows第一个确认如下所示:

"确定?"的屏幕截图 确认

原始令人反感的确认。

这是一个很好的开始。 如果希望用户不喜欢你的程序,只需在整个过程中都显示如下所示的确认。 若要了解原因,请考虑用户的观点。 用户只是要求根据确认的定义执行某个操作,因此,除非意外单击或按下了某些内容,当然,用户想要继续操作。

不仅不必要的确认令人麻烦,而且无法有效地保护用户免受错误影响。 用户可以快速发现程序何时出现不必要的确认,其自然响应是尽快消除这些确认,通常无需阅读。 因此,此类确认只向这些任务添加额外的步骤。

不要仅仅因为用户可能出错而使用确认。 相反,确认在用于确认具有重大或意外后果的操作时最有效。 良好的确认永远不会说明明显;他们应传达用户需要知道不继续的充分理由。 并且它们仅在操作真正需要时使用,例如,要求用户仅在有需要保存的更改时保存更改。 只有在真正有保证时,才需要用户关注。

对于其他类型的确认,通常有一种更好的设计替代方法,而不是强制用户回答问题。

考虑设计备选项

下面是一些无需进行日常确认的设计替代方法:

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

进行确认需要思考

若要确认是否具有值,用户需要了解不继续的原因。 有时原因很明显,因为当用户关闭包含尚未保存的更改的文档时:

显示"是否画图"的屏幕截图。 消息作为响应。

此示例中,确认原因很明显。

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

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

不正确:

通过 "卸载" 按钮确认的屏幕截图

在此示例中,正确的响应需要考虑。

如果用户提供了 Uninstall 命令后立即发出此确认,则用户的响应可能是 "我想要卸载!" 用户将单击 "卸载",而不是第二次考虑。

对于确认,我们不希望用户做出 hasty 的决策。 为了鼓励用户对其响应做出看法,我们需要提供小规模的决策速度凹凸。 在可行的情况下,最好是通过仔细地表述提交按钮来实现此目的。 例如,我们可以使用其他语言来指示有理由不要继续。

良好:

"仍卸载" 按钮的屏幕截图

在此示例中,"无论如何" 将添加到 "提交" 按钮标签,以指示该确认不能继续。

如果这种方法不可行,可以使用 "是/否提交" 按钮。

还有更好的:

带有 "是/否" 按钮的确认屏幕截图

在此示例中,使用 "是/否提交" 按钮将强制用户至少读取主指令。

提供所有信息

如果要提出问题,您必须提供足够的信息供用户智能地回答该问题。 请考虑 Windows XP 中的 "确认文件替换" 对话框:

"确认文件替换" 对话框的屏幕截图

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

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

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

用户可以通过单击 "是" 和方案2来实现方案1,方法是单击 "否"。 他们可以通过比较文件日期并单击相应的按钮来实现方案3,但请注意确定较新文件所需的时间,然后确定适合最常见方案的适当按钮。

方案4、5和6也是非常困难的。 文件大小被舍入,因此,例如,无法确定这些文件的大小是否相同,甚至是否是相同的文件。 图标适用于用于打开文件的应用程序,因此,用户必须打开文件来检查和比较其内容。 在回答问题时,具有文件内容缩略图会更有用。

Windows Vista 中的复制文件确认通过提供详细信息并添加保留两个文件的选项,来更好地处理这些方案:

"复制文件" 对话框的屏幕截图

Windows Vista 副本文件确认。

提供特定的有用信息

如果要提出问题,请确保用户了解其他响应的问题和影响。 请考虑以下 Windows Internet Explorer 安全确认:

带有不明确问题的确认屏幕截图

不明确的安全确认。

此确认会询问用户无法智能地回答的问题。 用户已请求 Windows Internet Explorer 显示页面,此消息会通过文本的措辞隐式建议并突出显示 "否" 作为默认选项。

页面所面临的特定安全问题并未充分说明,因此继续操作的风险并不明显。 确认中的哪些信息将导致用户不单击 "否"? 由于消息的 vagueness,确认不会阻止用户继续,但会使用户感觉不到这样的问题。

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

如何确定是否需要确认

考虑方案和选择每个响应的可能性,建议确定是否需要确认的系统化方法。 如果用户可能选择所有响应,则确认是必需的,并且很有用。 但是,如果只有一个响应可能 (说98% 的时间) ,则表明确认是不必要的,应该将其删除。 请注意,与安全性、法律和安全问题相关的确认是可能的例外情况。

"是否要更改设置?" 的屏幕截图

是否需要此确认? 用户是否会选择 "否?" 这是可能的,但却非常本来就。 应删除此确认。

如果只执行三项操作 .。。

  1. 请确保您的确认确实是必需的。 应该有一个合理且清楚的原因不能继续,有时用户可能不会这样做。

  2. 如果确认原因不会立即出现,请选择 "提交" 按钮,以鼓励用户考虑其响应。 通常,这是通过将确认短语解释为 "是" 或 "否" 问题,并提供完全一目了然或是/否答案来完成的。

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

使用模式

确认具有几个使用模式:

使用情况 示例
例程确认
确认用户想要继续处理常规的、低风险的操作。
这些确认通常是 "是否确实 ..." 的组句方式 并且通常会出现 "不再显示此消息" 复选框,以最大程度地降低其干扰。
"将文件夹移动到回收站吗?" 屏幕截图
"不再显示消息" 屏幕截图
例程确认示例。
注意: 此模式通常是不必要的,应避免这样做。
风险操作确认
确认用户是否想要继续操作,该操作会有风险并且无法轻松撤消。
由于这些确认有风险,因此这些确认通常会出现警告图标。
显示卷格式确认示例的屏幕截图。
显示永久删除确认示例的屏幕截图。
风险操作确认的示例。
意外的结果确认
确认用户想要继续执行具有意外结果或意外结果的操作。
除了提出问题之外,这些确认指出了意外的后果。 由于这些确认会产生意外结果,因此这些确认通常会出现警告图标。
"全部关闭" 选项卡的屏幕截图 证实
"取消安装?" 的屏幕截图 证实
意外结果确认的示例。
但是,这种模式要求结果确实不是必需的。
不正确
"关闭密钥记录器?" 的屏幕截图 证实
这里有一些后果,因此这是一条例行确认。
说明
澄清用户要如何使用可能导致不明确或意外结果的操作。
如果操作的效果可能被误解,拖放操作可能会导致进行说明。
"仅更改此事件的屏幕截图"
"始终在退出时保存?" 屏幕截图 证实
说明的示例。
注意: 应避免此模式,因为这样可以更好地设计无歧义后果的操作,并假设最有可能的结果。
安全确认
确认用户想要继续执行安全后果的操作。
"是否要运行此软件?" 的屏幕截图
"记住密码" 的屏幕截图 确认
安全确认的示例。
不可告人动机确认
提供有关操作的信息,但将其显示为确认。
尽管这些对话框显示为确认,但其实际目标是用户教育或功能公告。
希望此工具栏在任务栏上的屏幕截图吗?
不可告人动机确认的示例。
注意: 不建议使用此模式,因为通常有更好的直接替代方法。 例如, 动画 是一种更好的方法来显示原因与效果之间的关系。

指南

常规

  • 仅当有重大更改时才使用 "保存更改" 确认。 请勿确认不是由用户直接进行的更改,如自动文档重新格式化。

不正确:

显示 Microsoft Office Outlook "是否要保存更改?" 的屏幕截图 对话框中指定选项。

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

图标

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

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

    模式 图标
    例程确认
    无图标。
    风险操作确认
    警告图标。
    意外的结果确认
    如果有风险,则使用警告图标; 如果有,则使用功能图标;否则,不会有图标。
    说明
    如果确认涉及到文档,请使用文档的缩略图;否则,请使用功能图标(如果可用),或者不显示图标。
    安全确认
    警告图标。
    不可告人动机确认
    无图标。
  • 不要将警告图标用于日常问题。 这样做会带来Windows的鼓励性,并使使用您的程序看起来像是危险活动。 假定用户了解在任务完成前取消该任务的后果。

不正确:

"是否结束本教程?" 的屏幕截图

在此示例中,使用了一个警告图标来提出问题。

提交按钮

  • 如果确认原因很明显或可以进行自我解释,则使用对主指令的特定响应。

"是否要保存更改?" 的屏幕截图

在此示例中,确认的原因很明显,因此请保存并不节省工作。

  • 否则,请使用 "是" 和 "否" 按钮来获得确认响应。 这样做会使用户在做出响应之前,先给确认。 请勿使用 "确定" 和 "取消" 进行确认。

正确:

"想要卸载支持文件?" 的屏幕截图

在此示例中,使用 "是/否提交" 按钮将强制用户至少读取主指令。

不正确:

"取消你的预订?" 的屏幕截图

在此示例中,使用 "确定"/"取消" 会造成混淆。

  • 若要关闭程序或重新启动 Windows,请使用特定于主指令的响应。 若要防止任何误解,请不要出于此目的使用 "关闭" 或 "是/否"。

正确:

"立即重启 windows" 按钮的屏幕截图

不正确:

"是" 按钮的屏幕截图

在不正确的示例中,使用 "是" 重新启动 Windows。

  • 对于 "说明" 模式,请考虑使用命令链接使替代项更清晰。

可以接受:

"更改一项或所有项" 的屏幕截图

良好:

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

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

  • 首先列出最常用的命令链接。 最终的顺序应该大致遵循使用的可能性,同时还会有一个逻辑流。
  • 如果命令链接需要进一步说明,请 提供补充说明。 补充说明介绍了在选择选项时,用户可能需要选择选项或执行的操作。

有关更多指导和示例,请参阅 命令链接

默认值

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

    模式 默认响应
    例程确认
    阅读.
    风险操作确认
    请勿继续 (或安全选择) 。
    意外的结果确认
    如果后果重大,请不要继续;否则,请继续。
    说明
    最可能的响应。
    安全确认
    请勿继续。
    Ulterior 动机确认
    进行。

不要再次显示此消息

  • 仅对例程和 ulterior 动机确认模式使用此选项。 对于其他模式,如果需要信息,应始终显示此信息。
  • 不要提供此选项来说明显示不必要的确认的理由。 只需删除确认。

不正确:

"消除这些提醒?"的屏幕截图

仍不正确:

"不再次显示消息"的屏幕截图

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

有关更多准则,请参阅 对话框

批量操作

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

"针对所有项目执行此操作?"的屏幕截图 复选框

此示例具有用于批量操作的选项。

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

不正确:

"确认文件删除"对话框的屏幕截图

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

<a name="progressive-disclosure">渐进式披露

  • 如果必须在确认消息中包括高级信息,则使用渐进式披露按钮 (例如"显示详细信息") 。 这样做可简化典型用法的确认。 不要隐藏所需信息,因为用户可能找不到这些信息。
  • 除非确实有更多详细信息,否则请勿使用"显示详细信息"。 不要只是以其他格式重述现有信息。

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

用户帐户控制

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

文本

常规

  • 删除冗余文本。 在标题、主要说明、补充说明、内容区域、命令链接和提交按钮中查找冗余文本。 通常,在说明和交互式控件中保留全文,并删除其他位置的任何冗余。
  • 请勿在文本中使用"警告"或"警告"。 如果用户需要谨慎继续,请改为使用警告图标来指示这一点。

不正确:

卷格式设置确认的屏幕截图

此示例中不需要术语"warning"。

标题

  • 使用标题标识确认来自的命令或功能。异常:
    • 如果确认由许多不同的命令显示,请考虑改为使用程序名称。
    • 如果该标题是冗余的,或者与主指令混淆,请改为使用程序名称。

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

  • 请勿使用标题来说明 在对话中要执行哪些操作,这是主要指令的用途。
  • 如果增加了清晰度,请以"确认"一词开始标题。
  • 对于风险操作确认,可以添加涉及的对象的名称,以进一步强调。

"格式化 f 驱动器"对话框标题的屏幕截图

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

主要说明

  • 确认的主要指令基于其设计模式:

    模式 主指令
    意外后果确认
    说明意外后果。
    异常: 如果询问用户是否想要继续的问题明确暗示了意外后果,请改为提问。
    "关闭所有选项卡?"的屏幕截图 确认
    本示例要求用户继续,充分传达操作的结果。
    所有其他
    提出一个问题来确定用户是否想要继续。
  • 简洁,只需使用一个完整的句子。 将主指令向下去除为基本信息。 如果必须说明其他内容,请使用补充说明。

  • 如果存在涉及的对象,请指定其全名。

  • 使用正短语。 正短语更易于用户理解。

正确:

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

不正确:

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

但是,即使命令是负面短语,短语也必须与关联的命令匹配;例如,使用 disable 确认 Disable 命令。

  • 虽然没有严格的短语规则,但这些常见的确认短语 具有指示的词句:

    短语 内涵
    是否确实要 [ 执行的操作 ] ?
    确认用户请求的直接结果。
    是否要执行 [ 操作 ] ?
    确认用户请求的副作用。
    是否选择 [ 结果 ] ?
    需要说明。
    [执行操作 ] ?
    无暗示。
  • 对于风险操作确认,请使用术语"永久"来指示无法撤消操作。

永久删除确认的屏幕截图

此示例中,"永久"指示无法撤消该操作。

补充说明

  • 确认的补充说明基于其设计模式:
Label
模式
补充说明
意外的结果确认
询问一个问题,确定用户是否想要继续。
所有其他
解释用户可能不希望继续进行的任何不明显的原因。 此类原因包括:
  • 可能丢失以下一项或多项:
    • 宝贵的资产,如数据丢失或财务损失。
    • 系统访问或完整性。
    • 隐私或控制机密信息。
  • 不可逆的操作。
  • 不要以略有不同的措辞重复本说明。 如果没有更多要添加的,请改为省略补充说明。
  • 对于意外的结果确认,请考虑使用这一术语,而不是 在用户忽略主指令时不继续。 有关详细信息,请参阅设计概念。
  • 使用完整的句子、句子样式大写和结束标点。

文档

引用确认时:

  • 如果标题特定于确认 (而不是程序名称) ,请参阅其标题的确认;否则,请参阅其主要说明。
  • 如有必要,您可以将确认对话框作为消息来引用。
  • 使用准确的文本,包括其大小写。
  • 如果可能,请使用粗体设置文本格式。 否则,请仅在需要时将文本放入引号中,以避免混淆。

示例:在 " 复制文件 " 消息中,单击新的文件。