出自UXGuide.net

最容易犯的错误

Top Violations

注：2008/11/26 发现此文被微软大幅更新，因此重新收录。

目录 1 窗口 2 布局 3 文本 4 控件 5 键盘 6 鼠标 7 对话框 8 属性表 9 向导 10 向导页 11 错误信息 12 警告信息 13 确认信息 14 图标 15 帮助

本文总结了一些最常见的违反此 UX 规范的情况。你可以以此作为一个核对表，用于确保你程序的用户界面在这些重要方面都是正确的。

窗口

• 支持 800x600 像素的最小 Windows 屏幕分辨率。对于那些必须可以工作在安全模式下或用于 Ultra-mobile PC（UMPC）及 Windows Media Center PC 的关键用户界面，应当支持 640 x 480 像素的屏幕分辨率。
  • 要支持这些环境，即使当前屏幕分辨率低于你程序最小支持的分辨率，也仍然应当显示部分用户界面。该用户界面的功能可能受到限制。
• 为 1024x768 像素的屏幕分辨率优化可调整大小的窗口布局。
• 确保在 96 dpi（800x600）、120 dpi（1024x768）和 144 dpi（1280x1024）模式下测试你的窗口。检查布局问题、控件和窗口裁剪、以及图标和位图拉伸情况。
  • 对于用于移动使用的程序，应为 120 dpi 进行优化。目前 Mobile PC 上普遍采用高 dpi 屏幕。
• 如果窗口是子窗口（owned window），初次显示时应将其“居中”显示在父窗口的上方。不要显示在下方。以后显示的时候，如果更为方便，应考虑将其显示在最后一次出现的位置（相对于父窗口）。
• 如果窗口是上下文相关的，应当总是将其显示在靠近触发它的对象旁边。不过，应当把它放在靠旁边的位置（最好是向右下方一些），以免挡住对象。

布局

• 将窗口中控件和面板的尺寸调整为适合典型内容的大小。避免截断文本使其带有省略号。用户应当不需要任何操作即可查看窗口的典型内容——为通常不会出现的大量内容预留调整大小和滚动功能。特别要检查：
  • 控件尺寸。控件尺寸应当适合于其典型内容，将控件变得更宽、更高、必要时使用多行编辑。调整控件的尺寸，以避免或减少在那些有大量空间的窗口中进行滚动。而且，不应在有大量空间的窗口中存在任何被截断的标签或文本。然而，为了使文本易于阅读，考虑将行宽限制为 65 个字符。
  • 列宽。确保列表视图具有合适的默认、最小及最大列宽。为列表视图使用不会引起文本截断的默认列宽，尤其当列表视图中还有足够空间时。
  • 布局平衡。窗口布局应当让人感到大致平衡。如果觉得布局左侧偏重，应当考虑增加控件的宽度，并将一些控件移到右侧。
  • 布局尺寸调整。当窗口尺寸能够缩放且数据被截断时，确保更大的窗口尺寸能够显示更多数据。当数据被截断时，用户期望通过调整窗口的尺寸来显示更多信息。
• 如果当窗口小于特定尺寸后内容不再可用，则应当设置最小窗口尺寸。对于可缩放控件，应当根据其最小的可用尺寸设计最小可缩放元素尺寸，例如列表视图中的最小可用列宽。

文本

• 尽可能使用普通的、口语化的用语。关注于用户的目标，而非技术。这当你在解释复杂的技术概念或操作时非常有效。假设你就在用户的旁边，向其解释应当如何完成任务。
• 有礼貌、给予支持与鼓励。用户绝不应感到被牵就、被责备或被胁迫。
• 删去重复多余的文字。在窗口标题、主标题说明、补充说明、内容区域、命令链接及提交按钮中寻找重复多余的文字。通常，完全保留说明文本和交互性控件中的文字，删去其他地方的重复内容。
• 为标题使用标题大写风格，并为所有其他 UI 元素使用句子大写风格。这么做更加贴合 Windows Vista® 语气。
  • 例外：对于遗留的应用程序，如果需要，你可以使用标题大写样式来避免混合的大小写样式。
• 对于功能特性和技术名称，应当保留其原有大小写。通常，只有主要组件会大写（使用标题大写风格）。
• 对于功能特性和技术名称，应当统一大小写。如果名称在一个用户界面上出现了多次，应当总是以同样的方式出现。同样，在程序中的所有用户界面中，该名称也应当统一呈现。
• 不要大写普通用户界面元素的名称。如“toolbar（工具栏）”、“menu（菜单）”、“scroll bar（滚动条）”、“button（按钮）”和“icon（图标）”。
  • 例外：Address bar（地址栏）、Links bar（链接栏）。
• 不要为键盘按钮使用全大写字母。而是应当遵循标准键盘上使用的大小写方式，如果键盘上没有标出键名，就小写。（对于中文来说，如果标准键盘上有标注，则严格使用原文，如果键盘上没有标注，则使用其通行的中文名称。——译者注）
• 省略号表示不完整。应当以下列方式在用户界面文本中使用省略号：
  • 命令。表示该命令需要额外的信息。不要凡是显示其他窗口的操作就都加上省略号——应当只是那些需要额外的信息来完成操作的情况。任何暗示着弹出其他窗口的命令按钮都不需要省略号，例如“关于”、“高级”、“帮助”、“选项”、“属性”或“设置”等。
  • 数据。表示文本被截断。
  • 标签。表示任务正在进行中（如“正在搜索...”）。

提示：在那些还有未使用的空间的窗口或页面中出现被截断的文本意味着不好的布局或默认窗口尺寸太小。努力调整布局和默认窗口尺寸，以消除或减少文本截断的数量。更多信息，参见布局。

• 不要为不是链接的文本使用蓝色，因为用户会把它当成链接。在你想使用彩色文本的地方使用粗体或某种灰色。
• 谨慎使用粗体来吸引用户注意那些必须阅读的文本。
• 使用主标题说明来简要地解释一个页面或对话框用来做什么。好的主标题说明传达的是用户的目标，而不只是关注于操作用户界面。
• 以祈使句式的指导或明确的疑问句的形式表述主标题说明。
• 不要在控件标签或主标题说明末尾添加句点。
• 在句子之间使用一个空格。而不是两个。

控件

• 常规
  • 为每个控件或控件组添加标签。例外：
    • 文本框和下拉列表可以通过提示文本（prompt）来标注。
    • 附属控件可以使用它们所附属的控件的标签。微调控件永远都是附属控件。
  • 对于所有控件，应当将最可靠的（避免丢失数据或无法访问系统）、最安全的值作为默认值。如果可靠性与安全性不是需要考虑的因素，那么就选择最有可能的或最方便的值。
  • 最好使用带约束的控件。尽可能使用像列表和滑块这样的带约束的控件来减少文本输入的需要，而不是像文本框这样的无约束控件。
  • 重新考虑禁用控件。禁用的控件可能很难使用，因为用户需要推断其被禁用的原因。当用户觉得该控件适用并能够很容易地推断出控件被禁用的原因时才可禁用控件。当用户无法使其可用或不认为该控件在此处适用的话，应当移除该控件，或者仍让其可用，但在使用不当时提供错误信息。
    • 提示：如果你无法确定是应当禁用控件还是提供错误信息的话，先试着撰写你可能会提供的错误信息。如果该错误信息包含有用的信息，目标用户不太可能快速推断出的话，就保持控件可用并提供该错误信息。否则，即可将其禁用。
• 命令按钮
  • 尽可能使用明确的标签，而非常规标签。理想情况下，用户应当不需要为了理解标签而阅读其他任何内容。用户更愿意阅读命令按钮标签，而不是静态文本。
    • 例外：如果“取消”有歧义的话，不要修改“取消”按钮的名称。用户不应该需要阅读所有按钮来确定到底哪个按钮可以取消该操作。但是，如果不清楚要取消的是哪个操作，例如有多个即将进行操作时，可以重命名“取消”。
  • 当提问时，使用与问题相对应的标签文字。例如，为那些是/否的问题提供“是”和“否”的选择。
  • 不要在不是属性表或控制面板项的对话框中使用“应用”按钮。“应用”按钮表示应用那些还未提交的更改，但保持窗口打开。这么做使用户可以在关闭窗口之前查看更改的效果。但是，只有属性表和控制面板项才需要这么做。
  • 如果取消后退回之前的状态（没有任何副作用），则将按钮命名为“取消”；否则，应当命名为“关闭”（如果操作已经完成）或“停止”（如果操作还在进行中）来表示会完整保留当前更改过的状态。
• 命令链接
  • 应当总是同时呈现两个或更多的命令链接。从逻辑上来说，没必要问只有一种答案的问题。
  • 提供明确的“取消”按钮。不要将命令链接作此用途。很可能用户意识到他并不想进行这项任务。使用命令链接来取消会使用户必须仔细阅读所有的命令链接并确定哪个表示取消。使用明确的“取消”按钮可以让用户非常快速地取消任务。
  • 如果提供明确的“取消”按钮使得只剩下单独的一个命令链接的话，可以同时提供用于取消的命令链接和“取消”按钮。这么做可以明确表达用户可以进行选择。以它与第一个选择有什么不同的角度来描述这个命令链接，而不仅仅是“取消”或类似的变体。
• “不要再显示此 <项>”复选框
  • 考虑使用“不要再显示此 <项>”的选项，以让用户能够禁用一个重复出现的对话框，但仅适用于没有更好的其他途径时。最好是只在用户真正需要它的时候才显示该对话框，或者如果用户不需要的话干脆把它去掉。
  • 将 <项> 替换为特定的名称。例如，“不要再显示此提醒”。当泛指对话框时，应使用“不要再显示此消息。”
  • 明确指出用户输入的内容将在未来用作默认值，在选项下方添加这样一句话：“你的选择会用作未来的默认值。”
  • 不要默认选中该选项。如果该对话框确实只需要显示一次，就直接这么做，不需要询问。不要将此选项用作侵扰用户的借口——确保默认的行为不会侵扰用户。
  • 如果用户选中该项之后又单击“取消”，该选项仍应“生效”。该设置是基元选项（meta-option），不遵循标准的取消行为——没有任何副作用。要知道如果用户不希望再看到该对话框，他们多半也会要取消它。
• 链接
  • 不要为链接分配访问键。链接是通过 Tab 键来访问的。
  • 不要为链接文本添加“单击”或“单击此处”的字样。这是不需要的，因为链接暗示了单击动作。
• 工具提示
  • 应当用工具提示为没有标签的控件提供标签。你无须仅为了一致性的原因去给已有标签的控件添加工具提示。
  • 如果有用的话，工具提示也可以为已有标签的工具栏按钮提供更多的细节。不要只是重复或者换个方式表达已经在标签中说过的内容。
  • 避免遮挡用户可能会去查看或者操作的对象。应当总是把提示放在对象的侧边，即使会造成鼠标指针与提示的分离。这样的分离不存在问题，因为对象和其提示之间的关系仍然非常清晰。
    • 例外：用在列表和树中的完整名称工具提示。
  • 对于一组项目，应当避免遮挡用户可能查看或操作的下一个对象。对于横向排列的项，避免将提示放在右侧；对于纵向排列的项，避免将提示放在下方。
• 渐进展开
  • 将“更多/更少”渐进展开按钮用于隐藏高级的或很少使用的选项、命令及用户通常不需要的细节内容。不要隐藏常用的内容，因为用户可能找不到它们。确保这种隐藏是有价值的。
  • 如果界面上一直显示了一些选项、命令或细节，则使用下列标签组合：
    • 更多/更少选项。用于选项或是选项、命令与细节内容的混合。
    • 更多/更少命令。仅用于命令。
    • 更多/更少细节。仅用于信息。
    • 更多/更少 <对象名称>。用于其他对象类型，如文件夹。
  • 否则：
    • 显示/隐藏选项。用于选项或是选项、命令与细节内容的混合。
    • 显示/隐藏命令。仅用于命令。
    • 显示/隐藏细节。仅用于信息。
    • 显示/隐藏 <对象名称>。用于其他对象类型，如文件夹。
• 进度条
  • 应当将确定模式的进度条用于那些有确定时间界限的操作，即使其中大部分时间都无法进行精确预测时也同样如此。不确定模式的进度条虽然表示正在进行中，但无法提供任何其他信息。不要仅仅因为不够精确，就选用不确定模式的进度条。
  • 如果能够准确计算的话，应当提供估计剩余时间。准确的估计剩余时间是有用的，而那些差得离谱或者剧烈变化的估计值是没用的。你可能需要在给出准确估计值之前先进行一些操作。这样的话，不要在初始阶段显示可能不准确的估计值。
  • 不要重新启动进度。如果它重新启动（可能因为操作中的一个步骤完成），进度条就丧失了它的意义，因为用户无法了解整个操作什么时候会完成。相反，该操作中的各个步骤应当分别只占整个进程的一部分，整个进度条只完成一次。
  • 提供有用的进度细节。仅当用户能够依此做些什么的时候，才有必要提供额外的进度信息。确保文本的显示足够长以使用户能够阅读。
  • 不要同时使用进度条和忙碌鼠标指针。只使用其中一个，不要同时一起使用。
• 提示（prompt）
  • 当屏幕空间紧张，使用标签或说明文字不合适时，可以使用提示文本（prompt）。如在工具栏上。
  • 提示文字主要用于以紧凑的方式标识文本框的目的。它绝不应该是用户在使用文本框时需要看到的关键信息。
  • 提示文本不得与真实文本相混淆。需要做的有：
    • 以灰色斜体方式显示提示文本，而以黑色正体方式显示实际输入的文本。
    • 提示文本应当不可编辑，且当用户单击或跳转到该文本框内时应立即消失。
      • 例外：如果文本框具有默认的输入焦点，则显示提示文本，并当用户开始输入时消失。
  • 不要使用句末标点或省略号。
• 通知
  • 应当将通知用于那些与用户当前活动无关的、无须立即采取行动的、用户可以完全忽略的事件。
  • 不要滥用通知：
    • 仅当需要时才使用通知。当显示通知时，你有可能打断了用户或甚至打扰到他们。确保这种打断是值得的。
    • 为非关键事件或那些不需要用户立即行动的情形使用通知。对于关键事件或那些需要用户立即采取行动的情形，应使用另外的 UI 元素（如模式对话框）。
    • 不要将通知用作功能广告！

键盘

• 将初始输入焦点分配给用户最有可能先进行交互的控件，往往也就是第一个可交互控件。如果第一个交互控件并不合适，考虑更改窗口的布局。
• 为所有交互控件分配 Tab 停靠位，包括只读的编辑框。例外：
  • 一组相关联的、行为与单个控件相同的控件，如选项按钮。这种组合具有单一的 Tab 停靠位。
  • 正确包含分组，以使方向键可以用于在分组内向前向后循环，并保持在该组内。
• Tab 顺序应当以自然流向从左至右，从上至下。通常，Tab 顺序应当遵循阅读顺序。考虑对常用控件例外处理，将其 Tab 顺序排得靠前一些。Tab 应当在所有 Tab 停靠位之间双向循环没有中断。在一具分组内，Tab 顺序应当连续，没有例外。
• 在一个 Tab 停靠位内，方向键顺序应当以自然流向从左至右，从上至下，没有例外。方向键应当在所有项之间双向循环没有中断。
• 应当以下列顺序呈现提交按钮：
  • 确定/[做某事]/是
  • [不做某事]/否
  • 取消
  • 应用（如果有的话）

其中 [做某事] 和 [不做某事] 应当是针对主标题说明的具体回答。

• 不要把访问键与快捷键搞混。虽然访问键和快捷键都是为用户界面提供键盘访问，但他们具有不同的用途和设计规范。
• 尽可能为所有交互控件或其标签分配唯一的访问键。只读文本框也是交互控件（因为用户可以滚动并复制文本），因此它们也需要访问键。不要将访问键分配给：
  • 确定、取消及关闭按钮。Enter 及 Esc 键已经用作它们的访问键。但是，一定要给那些表示确定或取消，但标签文字不同的控件分配访问键。
• 为最常使用的命令分配快捷键。不需要为那些不常用的程序和功能分配快捷键，用户可以使用访问键来代替。
• 不要将快捷键作为执行任务的唯一途径。用户应当也能够使用鼠标或通过 Tab 键、光标键及访问键来执行任务。
• 不要为常用的快捷键分配不同的含义。这些常用快捷键是需要记忆使用的，含义不一致会使用户产生挫败感且易于出错。关于 Windows 程序中使用到的那些常用快捷键，参见 Windows 键盘快捷键。
• 不要试图分配系统级的程序快捷键。你的程序的快捷键仅会当其拥有输入焦点时才会生效。

鼠标

• 切勿非要用户单击之后才能确定对象是否可以被点击。用户必须能够仅通过视觉观察即可确定是否可以被点击。
  • 主要用户界面（如提交按钮）必须具有静态的点击可见性。用户不应需要通过悬停来寻找主用户界面。
  • 次要用户界面（如次要命令或渐进展开控件）可以在悬停时显示其点击功能可见性
  • 文本链接应当静态地暗示链接文本，并在悬停时显示其点击功能可见性（出现下划线或其他外观变化，包括手形鼠标指针）。
  • 图形链接仅在悬停时显示手形鼠标指针。
• 仅为文本或图形链接使用手形（或称“链接选择”）鼠标指针。否则，用户需要通过单击来确定它们是否是链接。

对话框

• 模式对话框需要交互，因此应将它们用于那些用户在继续其操作之前必须响应的事情。确保这种打断是有必要的，如用于关键或不常出现的、一次性的需要完成的任务。否则，考虑无模式方案。
• 无模式对话框无需交互，因此应当在用户需要在对话框与所属窗口之间进行切换时使用。其最适用于频繁出现的、重复性的或持续的任务。不过，功能区（Ribbon）、工具栏和调色板窗口往往是更好的选择。

属性表

• 确保这些属性是必要的。不要只是为了避免进行困难的决断，就在你的属性页中堆满不必要的属性。
• 按照用户的目标来呈现属性，而非技术。只是因为一个属性用于设置特定的技术并不意味着你必须以那种技术的说法来呈现该属性。
  • 如果你必须以技术的说法来呈现设置（也许因为你的用户能够识别技术名称），应当为用户添加一段简短的说明。
• 使用明确的、有意义的选项卡标签。避免可以用于任何选项卡的普通标签，如“常规”、“高级”或“设置”。
• 避免“常规”页。你不需要使用“常规”页，除非：
  • 这些属性适用于多个任务且对于大多数用户来说是有意义的。不要把专门的或高级的属性放在“常规”页上，但你可以通过在“常规”页上放置一个命令按钮来访问它们。
  • 这些属性不适合于更加明确的分类。如果能找到这样的分类，就应当以此做为该页的名称。
• 避免“高级”页。除非：
  • 这些属性适用于不太常见的任务，且主要对于高级用户来说才有意义。
  • 这些属性不适合于更加明确的分类。如果能找到这样的分类，就应当以此做为该页的名称。
• 如果属性窗口只有单独一个选项卡且不可扩展的话，就不要使用选项卡。应当改用带有“确定”、“取消”及可选的“应用”按钮的常规对话框。可扩展属性窗口（可由第三方进行扩展）必须使用选项卡。

向导

• 先考虑轻量级的方案，如对话框、任务面板或单个页面。向导是重量级的用户界面，最适合于多步骤的、不常执行的任务。你不必使用向导——你可以在任何用户界面中提供帮助信息和协助。
• 仅当进到下一页而不作任何提交时才使用“Next（下一步）”。如果进到下一页后，其作用无法通过单击“后退”或“取消”来撤销的话，就视为提交。
• 当用户对任务进行提交时，应当使用针对性地回应主标题说明（如“打印”、“连接”或“开始”）的提交按钮。不要使用一般性的标签来提交任务，如“Next（下一步）”（并不暗示提交）或“Finish（完成）”（没有针对性）。这些提交按钮的标签文本自身应当是有意义的。提交按钮的标签应当始终以动词开头。例外：
  • 当针对性的回答仍然很一般时可以使用“Finish（完成）”，如“Save（保存）”、“Select（选择）”、“Choose（选择）”或“Get（获取）”。
  • 使用“Finish（完成）”来更改特性的一项或一组设置。
• 仅将命令链接用于进行选择，而非提交。在向导中，用特定的提交按钮表示提交远比使用命令链接要来得好。
• 当使用命令链接时，隐藏“下一步”按钮，但保留“取消”按钮。
• 在后续操作及完成页中使用“关闭”按钮。不要使用“取消”，因为关闭该窗口并不会放弃任何已经完成的更改和操作。不要使用“Done（已完成）”，因为它并不是一个祈使动词。
• 不要在向导名称中使用“向导”字样。例如，使用“连接到网络”而非“网络设置向导”。不过，把向导称为向导是可行的。例如：“如果这是你第一次设置网络，你可以通过使用连接到网络向导来获取帮助。”
• 在导航时保留用户的选择。例如，如果用户做了一些更改，单击“后退”，再单击“下一步”，那些更改应当被保留。用户觉得他们不需要重新输入这些更改，除非他们明确地选择清除。

向导页

• 关注于高效决策。减少页面的数量以关注于核心内容。组合相关的页面，将可选页面移出主流程。让用户单击“下一步”来完整过一遍你的向导可能在一开始看起来是好的体验，但如果用户从来不需要更改默认值，这些页面可能就是不需要的。
• 不要使用欢迎页（Welcome page）——尽可能在第一页就提供实际功能。仅在下列情况下才使用可选的起始页（Getting Started page）：
  • 该向导依赖于一些先决条件，必须满足才能成功完成向导。
  • 仅凭第一个选项页，用户可能无法理解该向导的目的，而且没有足够的空间用于进一步的解释。
  • 起始页的主标题说明是“Before you begin:（在开始之前：）”。
• 在要求用户作出选择的页面中，应当为最有可能的情况进行优化。这类页面应当呈现实际的选项，而不只是说明。
  • 如果你不用起始页的话，应当在第一页的顶部解释该向导的目的。
• 使用提交页面（Commit page）以明确用户什么时候将提交任务。通常提交页是最后一个选项页，且“下一步”按钮的标签会被更改以表明任务将被提交。
  • 不要使用仅仅总结用户先前选择的总结页（Summary page），除非该任务存在风险（包括安全性，或者是损失时间或金钱）或对用户可能没有理解其选择且需要检查的时候来说，是一个好机会。
• 不要在向导结束时使用什么也不做的恭喜页（Congratulations page）。如果向导的结果对于用户来说非常清楚，只须在最终提交之后关闭向导即可。
  • 当存在用户后续可能会进行的相关任务时，可以使用后续操作页（Follow-up page）。避免一些常规的后续任务，如“发送电子邮件”。
  • 仅当结果不可见且没有更好的给出任务完成的反馈途径时才可使用完成页（Completion page）。
  • 具有进度页面（Progress page）的向导必须使用完成页或后续操作页，以表明任务已经完成。对于长时间运行的任务，应当在提交页面关闭向导，并用通知来给出反馈。

错误信息

• 如果用户不太会因某错误信息采取行动或改变他们的行为的话，就不要提供该错误信息。如果用户不需要采取行动，或问题并不严重，就不要显示错误信息。
• 尽可能提出解决方案，以使用户能够修复该问题。不过，要确保所建议的解决方案通常能够解决问题。不要用那些可能又不太可信的解决方案来浪费用户的时间。
• 用词明确。避免模糊的用词，例如“语法错误”或是“非法操作”。应当提供明确的名称、位置及所涉及的对象的值等等。
• 不要使用责备用户或暗示用户犯了错误的用语。避免在句子中使用“you（你）”和“your（你的）”。虽然通常来说建议使用主动语态，但如果主动语态有可能会使用户感到被责备的话，可以使用被动语态。
• 不要为错误信息使用“OK（确定）”。用户不会觉得错误是 OK 的。如果错误信息没有明确方向的操作，则改用“关闭”。
• 不要使用下列字词：
  • error（错误）、failure（失败）：用“Problem（问题）”代替
  • failed to（……失败）：用“unable to（无法）”代替
  • illegal（非法）、invalid（无效）、bad（损坏）：用“incorrect（错误）”或“not valid（并非有效）”代替
  • fatal（致命）：用“program termination（程序终止）”代替
  • abort（放弃）、kill（中止）、terminate（终止）：用“stop（结束）”代替
  • catastrophic（灾难性的）：用“serious（严重的）”代替

这些用语是不必要的，而且与 Windows Vista 的鼓励式语气背道而驰。相反，当错误图标使用得当时，足以表达这里出现了问题。

• 不要在呈现错误信息时伴随声音效果。这么做很刺耳，而且没有必要。

警告信息

• 警告信息描述的是可能在未来引发问题的情形。警告不是错误也不是问题，因此不要将常规问题表述为警告。
• 如果用户不太会因某警告信息采取行动或改变他们的行为的话，就不要提供该警告信息。如果用户不需要采取行动，或问题并不严重，就不要显示警告信息。

确认信息

• 不要使用不必要的确认信息。应当仅在下列情况下使用确认信息：
  • 有明确的无法继续的原因或是合理的用户有时不愿继续的情况。
  • 该操作有严重后果或无法轻易撤销。
  • 用户有可能没有意识到该操作的后果。
  • 需要用户进行选择后才可继续操作，而不存在合适的默认值。
  • 鉴于当前上下文的情况下，用户仍然可能会执行错误的操作。
• 将确认信息表述为是与否的问题，并提供是或否的回答。与其他类型的对话框不同，确认信息设计为防止用户过快作出决定。如果用户不思考就进行回答，确认信息将失去意义。

图标

• 所有图标应当符合Aero 风格图标设计规范。应当换掉所有 Windows XP 风格的图标。
• 基于消息类型来选择标准图标，而不是背后的问题的严重程度。
  • 错误：已经发生的错误或问题。
  • 警告：可能在未来引发问题的情形。
  • 信息：有用的信息。

如果一个问题包含了不同的信息类型，则应关注于用户需要处理的最重要的方面。

• 图标必须与主标题说明或其他相关的文字相匹配。
• 非关键的用户输入问题不需要使用错误图标。但是，就地错误信息是需要图标的，否则这种基于上下文的反馈很容易被忽视。
• 不要用警告图标来“弱化”非关键错误。错误不是警告——应当改用错误图标设计规范。
• 对于问题对话框，应当仅为有严重后果的问题使用警告图标。不要为常规问题使用警告图标。

帮助

• 应当链接到具体的、相关的帮助主题。不要链接到帮助首页、目录、搜索结果列表或只是链接到其他页的页面。避免链接到包含一大堆常见问题列表的页面，因为这会强迫用户搜索与其单击的链接相对应的内容。不链接到具体的帮助主题对于手头的任务来说没有帮助。绝不要链接到空白页。
• 不要为了保持统一而在每个窗口或页面上都放置帮助链接。在一处提供帮助链接并不意味着你需要在每处都提供它。
• 尽可能将帮助内容所回答的主要问题用作帮助链接文本。不要使用“Learn more about（了解更多）”或“Get help with this（获取关于此项的帮助）”的措辞。
• 将整个帮助主题设为链接文字，而非只是关键字。
• 使用完整的句子。
• 除了问号以外，不要使用句末标点或省略号。
• 如果帮助内容是在线的，应当在链接文本中表达清楚。这么做使链接的结果能够被预期到。