002-Windows桌面应用程序设计指南（设计基础篇-桌面应用

2019-07-01 本文已影响0人烈焰虾米

下面是一些用户体验指南中的重要准则集合。您可以将此作为自查表，以确保程序用户界面在相关要点上设计无误。

窗口

支持最小Windows有效分辨率800x600像素。 对于必须在安全模式下工作的关键用户界面(ui) ，支持640x480像素的有效分辨率。对于有任务栏的窗口，确保在此分辨率中留出48个垂直相对像素供其占位显示。
在有效分辨率为1024x768像素的基础上，优化可调整大小的窗口布局。在更低的屏幕分辨率下，自动调整优化不同大小窗口的效果。
确保在每英寸96dpi(800x600像素)、120dpi (1024x768像素)和144dpi (1200x900像素)模式下测试窗口。 检查布局问题，例如控件、文本和窗口是否有超出，以及图标和位图是否有拉伸变形。
对于触屏和有移动应用场景的程序，在120dpi下进行优化。 高分辨率屏幕目前在触摸屏和移动电脑上非常流行。
如果一个窗口是一个从属窗口，初次出现应该"居中"于其主窗口上层。 永远不要在下层弹出。对于后续的弹出显示，如果更方便的话，可以考虑将其显示在上一次操作时相对于所有者窗口的位置。
如果一个窗口和上下文相关，那么总是在启动它的对象元素附近显示它。然而，让它展现在稍稍不同的位置(最好是向下偏移和向右偏移) ，这样启动对象就不会被窗口覆盖。

布局

在窗口中设计用以调整主要内容显示的控件和操作面板。避免出现内容删节及其相关信息省略的情况。用户永远不应该通过与整个窗口交互来查看其主要内容ー为异常大的内容保留大小调整控件和滚动条。具体检查以下项目:

控制大小的控件。 大小控件的典型内容，在需要的情况下，可以将控件设计得更宽、更高，或多行展示。有了控制内容展示大小的控件，就可以减少或杜绝在窗口仍有多余展示空间的情况下，仍需要滚动条控制才能阅读更多内容的情况。此外，在有大量可用空间的窗口中，不应该出现被截断的标签或被截断的文本。但是，为了使文本更易于阅读，可以考虑将行宽限制在65个字符内。
栏目宽度。 确保列表栏视图的默认大小、最小和最大尺寸合适。特别在列表视图中还有可用的空间时，设计不会导致文本被截断的列表视图默认列宽。
布局平衡。 窗口的布局应该给人感觉大致平衡。如果感觉布局左边重，可以考虑将控件加宽，并将一些控件向右移动。
布局大小调整。当窗口可调整大小并且数据被截断时，请确保较大的窗口能展示更多的数据。当数据被截断时，用户希望通过调整窗口大小来获取更多信息。

如果在一定尺寸下内容将无法有效展示，记得设置最小窗口尺寸。 对于可调整大小的控件，将最小尺寸设置为其最小正常运作的尺寸，例如列表视图中的最小列宽度。

文本

尽可能使用日常、通用的术语。 关注点应在于用户目标，而不是技术。如果你正在解释一个复杂的技术概念或行动，这尤其有效。想象一下你就站在用户面前，向他解释如何完成这个任务。
传达礼貌、支持和鼓励的态度。 用户永远不应该感到屈尊俯就、被责备或者担惊受怕。
删除冗余文本。 在窗口标题、主要指令、补充指令、内容区、命令链接和提交按钮中查找冗余文本。通常，在主要说明和交互式控件中保留全文，其他地方的冗余都需要删除。
对标题使用标题样式的大写规则，所有其他 UI 元素上的文本则使用句子的大写规则。 这样做更贴合 Windows 的风格。
例外情况: 对于传统应用程序，如果需要，可以对命令按钮、菜单和列标题使用标题样式的大小写，以避免混合大小写样式。
对于功能和技术名称，在大写规则上要保守。 通常，只有主要组件应该大写(使用标题样式大写规则)。
对于功能和技术名称，大写规则要保持一致。 如果名称在同一界面中出现多次，则应保持显示一致。同样，在同一程序中的所有界面中，名称应该始终一致。
不要将通用用户界面元素(如工具栏、菜单、滚动条、按钮和图标)的名称大写。
例外情况: 地址栏，链接栏，功能区。
键盘按键不要全部使用大写字母。 遵循标准键盘使用的大写字母规则，或者如果键盘上没有标记，则按小写字母。
省略号意味着信息不完整。 使用省略号UI文本中有以下情况:
1.命令。省略号表明执行命令需要额外的信息。某个操作会弹出新窗口时，UI文本不一定要使用省略号ー只有在需要展示额外信息时才使用。当一个命令隐含有打开新窗口的动作倾向时，UI文本不应加省略号，如"高级"、"帮助"、"选项"、"属性"或"设置"。
2.数据。暗示文本被截断，显示不完整。
3.标签。暗示任务正在进行(例如,"搜索中...")。
提示: 如果窗口中仍有未使用的空间，而页面中却有被截断的文本，说明布局设计得不合理或默认窗口尺寸过小。尽量设计合适的布局和默认窗口大小，以消除或减少截断文本的情况。有关更多信息，请参见布局相关章节说明。
如果不是链接，不要设置蓝色文本，以免用户产生误解。 使用字体加粗或灰度字体来代替彩色文字。
节制地对用户必读内容使用加粗文字以吸引注意力。
使用主指令简明地向用户解释清楚，在给定窗口或页面中应该做什么。 好的主说明能够与用户沟通以完成用户的目的，而不仅仅是指导用户操作界面。
以祈使句或特定问句的形式表达主要指令。
不要在控制标签或主说明的末尾放置句号。
在句子之间空一格。

控件

通用

为每个控件或控件组设置文本标签。以下情况例外:
1.文本框和下拉列表可以使用prompt进行说明。
2.下级控件使用其主控件的标签。可旋转控件都是从属控件。
对于所有控件，选择最安全的(以防止数据丢失或系统访问) ，最保险的默认值。 如果安全性和保险性不是因素，就设置最可能或最方便的值。
尽量选择操作有限的控件。 尽可能这种约束性的控件，如列表和滑块，而不是无约束的控件，如文本框，以减少内容的输入。
慎用禁用控件。 禁用控件可能很难使用，因为用户得明白禁用的原因。当用户认为某个控件可点击、并且如果该控件不能使用时他们可以很容易地明白发生了什么，这种情况下可以使用禁用控件。当用户不可能启用、或他们不想让控件可用、或他们用不到该控件，这时应该直接删掉这个控件，或者在其没有被正确使用的时候显示错误信息提示。

（提示: 如果您不确定是该禁用控件还是应该显示错误提示，那么可以从列出可能提供的错误信息内容开始。如果错误消息包含有用信息，而这些信息目标用户不太可能仅凭自己的理解迅速得出，那么请保持控件处于启用状态并提供错误提示。否则，禁用该控件。）

命令按钮

直接使用具体标签文字，不要使用附属文本进行说明。 理想情况下，用户不必通过阅读其他内容来理解标签。用户更愿意直接阅读命令按钮标签而不是静态文本。（特例: 如果某操作的取消含义明确，那就直接叫"取消"按钮。用户不必阅读所有的按钮来思考哪个按钮能取消操作。但是，如果不清楚正在取消哪些操作，比如有几个挂起的操作时，则为“取消”按钮重新命名。）
问问题时，使用与问题相匹配的标签文字。 例如，对一个是或否的问题提供是或否的选择按钮。
不要在非属性列表或控制面板项的对话框中使用"应用"按钮。 "应用"按钮意味着应用挂起中的更改内容，但保持窗口打开状态。这样做允许用户在关闭窗口之前评估更改。但是，只有属性表和控制面板项具有此需要。
如果要取消使环境操作，以恢复到以前的状态(不产生任何其他影响) ，则标签名称为"取消"; 当操纵已完成时，标记按钮为"关闭"；如果操作正在进行中，使用"停止"以表明它保持当前更改的状态不变。

命令链接

一个典型的命令链接

一组命令链接中一定有两个或者更多命令链接。 从逻辑上讲，没有理由问一个只有唯一答案的问题。
设计一个明确的取消按钮。不要为“取消“设计命令链接。很多时候，用户会意识到他们不想把任务执行下去。若使用命令链接完成取消操作，需要用户仔细阅读所有命令链接，以确定取消是哪一个。有一个明确的取消按钮允许用户高效地取消任务。
如果除了提供一个Cancel按钮以外，只留下了一个命令链接，那就同时提供一个要取消的命令链接和一个Cancel按钮。 这样能清楚地表明，用户有得选择。在表述上，该命令链接必须得重新组织，要和单纯的“取消”含义有所不同，而不仅仅是"取消"或其他变体。

“不再显示”选择框

在没有更好的方案时，考虑设置"不要再显示此内容"选项，以允许用户禁用重复出现的对话框。 如果用户真的需要，最好总是显示对话框，如果不需要，就简单地删除它。
用特定语言表述此类选项。 例如“不再显示该提醒” 。在一般情况下引用对话框时，使用"不再显示此消息"。
清楚地告知用户输入值将用作未来的默认值。使用这样的语句告知: 您的选择将在未来默认使用。
不要默认勾选“不再显示”选项。 如果对话框确实应该只显示一次，请不要询问用户（给用户“不再选择”的选项），就直接只显示一次。 “不再显示”选项的存在是为了方便用户而不是为用户造成困扰ーー确保默认行为不会惹恼用户。
如果用户勾选了该选项又单击了对话框的"取消"，选项将仍会生效。这个设置是一个元选项，所以它不会遵循标准的取消行为（标准的取消行为会让对话框中的所有指令无效）。这样设计的内在逻辑是，如果用户将来不想再看到这个对话框，他们很可能也会点去击取消按钮。

链接

不要为链接分配存取键。使用 Tab 键访问链接。
不要在链接文字中加入「点一下」或「点这里」。这没必要，因为链接就意味着需要点击。

工具提示

工具提示是为未标记的控件提供标签文字说明。 你不必仅仅为了一致性而给本身有标签的控件设置工具提示。
在必要情况下，工具提示可以为带标签的工具栏按钮提供更多细节说明。但不要只是重复或者冗长地重复标签上已经写好的内容。
要避免工具提示遮挡用户将要查看或交互的对象。 始终将提示放在对象的另一侧，即使这会使提示和鼠标指针不同侧显示。只要物体和它的提示之间的关系是清楚的，一些距离上的分割也没关系。（特例: 列表和树中使用的全名提示。）
对于多个项的集合，避免遮盖用户可能查看或与之交互的下一个对象。 对于水平排列的对象，避免将提示放在右边; 对于垂直排列的物品，避免将提示放在下方。

渐进展示

使用“展开/收起”渐进按钮组，来隐藏高级或用户很少使用的选项、命令和细节。 不要隐藏常用的项目，防止用户可能找不到它们。但也得确保隐藏起来的选项是有必要存在的。
如果界面需要显示一些选项、命令或细节，请使用以下标签文字对:
（1）更多 / 收起选项。用于选项或选项、命令和详细信息的混合。
（2）更多 / 收起命令。仅用于命令。
（3）更多 / 收起细节。仅用于信息展示。
（4）更多 / 收起。用于其他对象类型，如文件夹。
或者是:
（1）显示 / 隐藏选项。用于选项或选项、命令和详细信息的混合。
（2）显示 / 隐藏命令。仅用于命令。
（3）显示 / 隐藏细节。仅用于信息展示。
（4）显示 / 隐藏。用于其他对象类型，如文件夹。

进度条

对于需要有限时间的操作，使用确定的进度条，即使该时间量无法准确预测。不确定的进度条显示正在取得进展，但不提供其他信息。不要仅仅因为可能缺乏准确性而选择不确定的进度条。
如果可以做到准确的话，提供一个时间剩余的估计。 精确的剩余时间估计很好，但是不准确估计或者有明显时间反弹的估计毫无作用。您可能需要执行一些程序处理，然后才能给出准确的估计。如果是这样的话，不要在一开始就匆忙显示可能不准确的估计。
不要重启进程。 如果进度条重新启动(可能是因为操作中的一个步骤已经完成) ，它将失去其价值，因为用户无法知道操作何时将完成。相反，让操作中的所有步骤共享一部分进度，并让进度条报告一次部分完成状态。
提供有用的进度细节。 提供额外的进度信息，但前提这些信息对用户有用。确保文本显示的时间足够长，以便用户能够读完。
**不要将进度条和忙指针（转圈圈指针）组合使用。 ** 可以使用前者或者后者，但不要同时使用两个。

提示

当屏幕空间非常宝贵，使用标签文字或使用说明都不合适的时候，使用提示符。比如在工具栏上。
提示主要用于以紧凑的方式说明文本框或组合框的用途。它不该是用户在使用控件时需要查看的关键信息。
提示文本不能与实际文本混淆。要做到这一点:
（1）提示文本使用灰色斜体，实际输入文本使用黑色罗马体。
（2）提示文本不可编辑，一旦用户点击或开始在文本框内输入，提示文本应该消失。
（特例: 如果文本框具有默认输入焦点，则会默认显示提示，一旦用户开始输入，提示就会消失。）
不要在结尾使用标点符号或省略号。

通知

对与当前用户活动无关、不需要用户立即操作且用户可以自忽略的事件使用通知。
不要滥用通知:
（1）只在有必要的时候使用通知。当您显示一个通知时，您可能会打断用户，甚至会惹恼他们。要确保这种中断是合理的。
（2）对不需要用户立即操作的非关键事件或情况，使用通知。对于需要立即执行用户操作的关键事件或情况，请使用其他的UI元素(例如模态对话框)。
（3）不要使用通知作为功能广告！

键盘

将初始输入焦点分配给用户最可能首先与之交互的控件，这通常是第一个交互控件。如果第一个交互式控件并不是这种情况，考虑更改窗口的布局设计。
为所有交互控件分配焦点切换，包括只读编辑框。特例:
（1）组成单个控件(如多选按钮)的相关控件集。这样的组只有一个焦点切换。
（2）正确地设置组，以便箭头键在组中向前和向后循环，并保持在组中。
制表顺序应该从左到右，从上到下。 一般来说，制表顺序应该遵循阅读顺序。对于常用的控件，可以考虑特别将它们放在前面的tab键制表顺序中。焦点切换应不停循环，在两个方向上通过所有制表位。在一个组中，制表符应该是按顺序的，没有例外。
在制表位内，箭头键顺序应该从左到右，从上到下，没有例外。 箭头键应该在两个方向上循环遍历所有项目，不要停止。
按以下顺序显示提交按钮:
（1）好的 / [做] / 是的
（2）[不要做] / 不
（3）取消
（4）应用(如有)
其中[做]（1）和[不要做]（2）是对主要指示任务的具体回应。
不要混淆存取键和快捷键。 虽然存取键和快捷键都提供对 UI 的键盘访问，但它们有不同的用途和指导原则。
只要有可能，为所有交互控件或其标签分配唯一存取键。 只读文本框是交互式控件(因为用户可以滚动它们并复制文本) ，所以它们也可以使用存取键。不要将存取键分配给:
（1）确定，取消，和关闭按钮。 Enter键和 Esc键专用于它们的存取访问。但是，始终为表示"确定"或"取消"但具有不同标签文字的控件分配存取键。
为最常用的命令分配快捷键。 不经常使用的程序和功能不需要快捷键，因为用户可以使用存取键。
不要使用快捷键作为执行任务的唯一方式。 用户还应该能够使用鼠标或带有 Tab、箭头和存取键的键盘。
不要为众所周知的快捷键赋予不同的含义。 因为它们已经为人熟知，如果突然有了不同的含义，容易让用户受挫、产生误操作。
不要尝试分配系统层面的程序快捷键。 只有当程序具有输入焦点时，程序的快捷键才会生效。

鼠标指针

别让用户用鼠标去点击测试对象是否可点击。 必须保证用户通过视觉观察就能明确对象的可点击性。
1.主UI控件 (如提交按钮)必须具有静态的可点击示能。用户不需要通过鼠标悬停来探索这一点。
2.辅助UI控件(如辅助命令或渐进公开控件)可以在鼠标悬停时显示点击示能。
3.文本链接应该静态地展示链接文本内容，然后在鼠标悬停时显示它们的点击示(手型指针附带下划线或其他表现形式的变化)。
4.图形链接只在鼠标悬停时显示手型指针。
只对带有链接的文本和图形使用手型指针(或"链接选择")。 否则，用户将不得不点击对象来确定它们是否是链接。

对话框

模态对话框需要交互动作，所以在继续执行任务之前，用它们展示用户必须响应的事情。 确保中断是合理的，例如对于重要的或不经常的、需要完成的一次性任务。否则，考虑非模态的其他展示形式。
非模态对话框不需要交互，因此当用户需要在对话框和其主窗口之间切换时使用它们。 它们最适用于频繁、重复或正在进行的任务。但是，彩条、工具栏和调色板窗口通常是更好的选择。

属性表单

确保这些属性有设置的必要。 不要为了避免设计取舍而在属性页面中放置不必要的属性。
根据用户目标而不是技术水平来呈现属性。 一个属性可以配置一个特定的技术，并不意味着您必须通过该技术来展示该属性。

-如果您必须根据技术(可能是因为您的用户认识该技术的名称)显示设置，请包含用户受益的简要描述。

3.使用特定的，有意义的标签。避免可以应用于任何选项卡(如常规、高级或设置)的通用选项卡标签。

4.避免通用页面。通用页面并不是必备的。只有在下列情况下才使用通用页面:
（1）这些属性适用于多个任务，对大多数用户都有意义。不要在通用页面上放置专用或高级属性，但可以通过通用页面上的命令按钮来访问它们。
（2）这些属性不适合更具体的类别。如果有更具体的类别，使用那个类别来命名页面。

5.避免高级页面。只有在以下情况下才使用高级页面:
（1）这些属性适用于不常见的任务，主要对高级用户有意义。
（2）这些属性不适合更具体的类别。如果有更具体的类别，使用那个类别来命名页面。

如果属性窗口只有一个选项卡且不可扩展，则不要使用选项卡。 使用一个常规的对话框，包括“确定”、“取消”和一个可选的“应用”按钮。但可扩展的属性窗口(可由第三方扩展)必须使用选项卡。

向导程序

首先考虑轻量级替代方案，如对话框、任务窗格或单页等。 向导是一套很重的用户界面，最好用于多步骤、不经常执行的任务。可以用其他UI控件提供有用的信息和帮助，不是一定要使用向导。
只有在没有任何信息变动提交的情况下进入下一页时才使用“下一步”。如果无法通过单击"上一步"或"取消"来撤销效果，则进入下一页将被视为确定的承诺。
只在更正错误时使用“上一步”。 除了纠正错误之外，用户不应该必须单击 “上一步”才能将任务进行下去-。
当用户提交任务时，使用一个提交按钮作为对主指令的特定响应(例如，“打印”、 “连接” 或 “开始”)。 不要使用类似“下一步”(这并不意味着承诺能保存改动和信息)或“完成”(这并不具体)这样的通用标签来提交任务。这些提交按钮上的标签本身就应该有意义。提交按钮标签要用动词描述。特例:
（1）当响应仍然是通用动作的时候使用“完成”，例如 Save、 Select、 Choose 或 Get。
（2）使用"完成"来更改特定设置或设置集合。
使用命令链接只是为了选择，而不是承诺。 特定的提交按钮能比向导中的命令链接更好地表示承诺。
使用命令链接时，去掉"下一步"按钮，但保留"取消"按钮。
操作完成或者要进行后续操作时，使用“关闭”按钮。 不要使用"取消"，因为关闭窗口不会放弃此时所做的任何更改或操作。也不要使用“完成”，因为它不是命令动词。
不要在向导名称中使用"向导"。 例如，将"网络安装向导"改为"连接到网络" 但是，在提到它时，可以称其为向导。例如:"如果您是第一次设置网络，可以通过使用连接到网络向导来获得帮助。"
在浏览过程中保留用户的选择项。 例如，如果用户进行了更改，单击"上一步"，然后单击"下一步"，则应该保留这些更改项。用户并不期望必须重新输入更改，除非他们明确选择清除更改。

向导页面

致力于让用户进行有效率的决策。 减少页面数量，专注于要点。合并相关页面，并从主要流程页面中删除可选页面。让用户完全只通过单击“下一步”完成向导，乍一看似乎是个不错的体验，但如果用户从不需要更改默认设置，那么这些向导页面可能就没有必要了。
不要使用欢迎页面ーー尽可能使第一页具有功能性。只有在以下情况下才使用可选的入门页面:
（1）入门页面具有成功完成向导流程所必需的先决条件。
（2）仅根据向导的第一个选择页面，因为没有进一步解释的空间，用户可能无法理解向导的用途。
（3）入门页面的主指令是"在开始之前:"。
在用户被要求做出选择的页面上，针对用户最可能选择的项进行优化展示。 这种类型的页面应该提供实际的选择，而不仅仅是说明文字。
如果您不使用入门页面，请在向导页面的第一页顶部解释向导的用途。
当用户提交任务时，使用 "提交" 页面可以使其更明确。通常， "提交" 页面是向导页面的最后一页，“下一步”按钮被重新命名，以指示正在提交的任务。
（1）不要使用仅仅汇总用户之前所有选择的摘要页面，除非任务有风险(涉及安全、时间或金钱损失) ，或者用户很可能不理解他们的选择，需要查看它们。
不要使用"祝贺"页面，因为它会结束向导。 如果向导的结果很明确，用户只需点击最终提交按钮以关闭向导。
（1）如果有用户可能会执行的相关任务，请使用后续页面。避免提供太常规的后续任务，比如"发送电子邮件"
（2）只有当结果不可见、且没有更好的方法为任务完成提供反馈时，才使用完成页面。
（3）具有"进度"页的向导必须使用"完成"页或"后续"页来表明该阶段任务完成。对于长时间运行的任务，在确认页面上关闭向导并使用通知提供反馈。

报错信息

当用户不太会因为错误信息提示而执行某个操作，或改变他们的行为时，不要报错。 如果没有用户可以采取的操作，或者问题不严重，则禁止显示错误消息。
只要有可能，就应提出解决方案以便用户修复问题。 但是，要确保提出的解决方案能真正解决问题。不要提出可行但不保证成功的解决方案，浪费用户的时间。
措辞要具体。 避免使用含糊的文字，如语法错误和非法操作。给出所涉及对象的具体名称、位置和值。
不要使用责怪用户或暗示用户错误的措辞。 避免使用“你”和“你的”。虽然主动语态通常是首选，但当用户承受错误时，使用被动语态。如果使用主动语态，会让用户感觉自己对错误负有责任。
不要对错误消息使用 OK按钮。 用户不认为错误是 OK 的。如果错误消息没有直接操作，则改为使用“关闭”。
不要使用下面的词语:
（1）错误，失败(使用问题代替)
（2）未能 (使用无法执行替代)
（3）非法的，无效的，坏(使用不正确或无效的代替)
（4）中止，杀死，终止(使用停止代替)
（5）灾难性的，致命的(用严重的代替)
以上这些术语并非必要，它们与 Windows 鼓舞人心的基调相反。当正确使用一个错误图标的时候，也足以表达出现的问题。
不要将错误消息附加声音效果。 这样不和谐，也没必要。

警告信息

警告用来描述将来可能导致问题的某种情况。 警告不是提示错误或问题，所以不要把例行问题提醒用警告表示。
当用户不太可能执行某个操作或者因为消息而改变他们的行为时，不要发出警告消息。 如果没有用户可以采取的操作，或者如果情况并不紧急，则禁止显示警告消息。

确认消息

不要使用不必要的确认消息提示。 仅在以下情况下使用确认对话框:
（1）有一个明确的理由不继续进行，并且有一个合理的机会，有时用户不会继续。
（2）该行为会产生重要后果或不能轻易被撤销。
（3）该操作的结果可能是用户没有意识到的。
（4）继续执行操作需要用户作出选择，这个选项没有默认值。
（5）在当前上下文中，用户很可能执行了错误的操作。
确认描述文字是一个是或否的问题，并提供是或否的答案。 与其他类型的对话框不同，确认对话框的设计目的是防止用户过快决策。如果用户不仔细斯卡，一个确认没有价值。

图标

所有图标都应该遵循 aero 风格的icon规范。 替换所有 Windows xp 样式的图标。
基于"消息类型"选择图标，不要基于"问题的严重程度"选择图标:
（1）错误。已发生的错误或问题。
（2）警告。一种可能在未来出现的情况。
（2）消息。有用的信息。
如果一个问题包含了不同的消息类型，那么请立足于用户需要采取行动的最重要方面来选择图标。
图标必须始终与主指令或其他相应的文本匹配。
报告不紧要的用户输入问题，不需要使用错误图标。 然而，对于输入错误，需要使用图标立即提示，因为否则这样的情况很容易被忽略。
不要使用警告图标来"软化"非关键性错误。 错误不是警告，要应用错误图标准则。
对于问题对话框，只对会产生严重后果的问题使用警告图标。 不要在日常问题中使用警告图标。

帮助

帮助应该链接到特定的具体相关帮助主题。 不要链接到帮助主页、目录、搜索结果列表或者只链接到其他页面的页面。避免链接到由大量常见问题组成的页面，因为这会迫使用户搜索与他们点击的链接相匹配的页面。不要链接到与手头任务不相关和有帮助的特定帮助主题。不要链接到空白页面。
不要为了保持一致性，在每个窗口或页面上都放置帮助链接。 在一个地方提供帮助链接并不意味着你必须在所有地方都提供帮助。
只要有可能，直接使用短语"帮助"作为主要问题链接文本。 不要使用"了解更多关于"或"得到这方面的帮助"这样的措辞。
对整个链接文本设置帮助链接，而不仅仅是关键字。
使用完整的句子。
除了问号外，在结尾不要使用标点符号或省略号。
如果帮助内容是在线的，请在链接文本中明确说明。这样做有助于使链接的结果可预测。