桌面应用程序的 UX 清单

2024-07-22

注意

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

下面收集了 UX 指南中的一些重要准则。您可以使用此清单来确保程序用户界面正确处理这些重要项目。

Windows

支持最低为 800x600 像素的 Windows 有效分辨率。 对于必须在安全模式下工作的关键用户界面 (UI)，支持 640x480 像素的有效分辨率。请务必考虑任务栏使用的空间，为任务栏显示的窗口保留 48 个垂直相对像素。
优化可调整大小的窗口布局，使有效分辨率达到 1024x768 像素。 以仍然可行的方式来自动调整这些窗口的大小以适应较低的屏幕分辨率。
请务必以每英寸 96 点 (dpi) （以 800x600 像素）、120 dpi（以 1024x768 像素）和 144 dpi（以 1200x900 像素）的模式测试窗口。 检查布局问题，例如剪裁控件、文本和窗口，以及图标和位图的拉伸。
对于具有触摸和移动使用场景的程序，请优化为 120 dpi。 高 dpi 屏幕目前在触摸和移动电脑上普遍存在。
如果某个窗口是所有者窗口，则最初会将其“居中”显示在所有者窗口的顶部。 从不在下面。对于后续显示，如果这样做可能更方便，请考虑将其显示在其最后一个位置（相对于所有者窗口）。
如果窗口是上下文相关的，则应始终显示在启动窗口的对象附近。 但是，将其放在不碍事的地方（最好向下和向右偏移），这样物体就不会被窗户遮挡。

Layout

调整窗口内控件和窗格的大小以匹配其典型内容。 避免截断文本及其关联的省略号。用户永远不需要与窗口交互来查看其典型内容，而应该保留大小调整和滚动以查找异常大型内容。具体检查：
- 控件大小。 根据控件的典型内容调整控件大小，必要时让控件更宽、更高或多行。调整控件的大小，以消除或减少在具有大量可用空间的窗口中滚动。此外，在有大量可用空间的窗口中，绝不能出现截断的标签或截断的文本。但是，若要使文本更易于阅读，请考虑将行宽限制为 65 个字符。
- 列宽。 确保列表视图列具有合适的默认、最小和最大尺寸调整。选择不会导致截断文本的默认列宽的列表视图，尤其是在列表视图中有可用空间时。
- 布局平衡。 窗口的布局应该大致平衡。如果布局感觉左重，请考虑加宽使控件，并将一些控件移动到右侧。
- 布局调整大小。 当窗口可调整大小且数据被截断时，请确保更大的窗口尺寸能显示更多数据。数据被截断后，用户希望调整窗口大小以显示详细信息。
如果窗口尺寸小于某个值则内容将不再可用，请设置最小窗口尺寸。 对于可调整大小的控件，请将可调整大小的最小元素尺寸设置为其最小功能尺寸，例如列表视图中的最小功能列宽度。

文本

尽可能使用普通的对话术语。 专注于用户目标，而不是技术。如果您要解释复杂的技术概念或操作，这尤其有效。想象自己站在用户旁边，向他们解释如何完成任务。
礼貌、支持和鼓励。 用户绝不应该感到屈尊俯就、受到指责或恐吓。
删除冗余文本。 在窗口标题、主要说明、补充说明、内容区域、命令链接和提交按钮中查找冗余文本。通常，在主要说明和交互式控件中保留全文，并删除其他位置的任何冗余。
对标题使用标题样式大写，对所有其他 UI 元素使用句子样式大写。。 这样做更适合 Windows 系统风格。
- 例外：对于旧版应用程序，可以根据需要对命令按钮、菜单和列标题使用标题样式大写，以避免混合大写样式。
对于功能和技术名称，要保守地使用大写字母。 通常情况下，只有主要部分应大写（使用标题式大写）。
对于功能和技术名称，要一致地使用大写字母。 如果名称多次出现在 UI 屏幕上，它应始终以相同的方式显示。同样，在程序中的所有 UI 屏幕上，名称应一致显示。
不要大写通用用户界面元素的名称，例如工具栏、菜单、滚动条、按钮和图标。
- 例外：地址栏、链接栏、功能区。
键盘按键不要全部使用大写字母。 正确的做法是，请使用标准键盘使用的大写字母，如果键盘上没有标注按键，则使用小写字母。
省略号表示不完整。 省略号在 UI 文本中的用法如下所示：
- 命令。 表示命令需要其他信息。若某个操作只有在需要其他信息时才会显示另一个窗口，请勿使用省略号。隐式动词为显示另一个窗口的命令不使用省略号，例如“高级”、“帮助”、“选项”、“属性”或“设置”。
- 数据。 表示文本被截断。
- 标签。 表示任务正在进行中（例如，“正在搜索...”）。

提示：带有未使用空间的窗口或页面中的截断文本指示布局不佳或默认窗口大小过小。努力使布局和默认窗口大小能够消除或减少截断文本的数量。请参阅布局以了解详细信息。

不要使用不是链接的蓝色文本，因为用户可能会认为它是链接。 在使用彩色文字的地方使用粗体或灰色。
请谨慎使用粗体来吸引人们对用户必须阅读的文本的关注。
使用主要说明简明扼要地解释用户在特定窗口或页面中应该做什么。 良好的主要说明能传达用户的目标，而不是仅仅专注于操作用户界面。
以命令性指令或特定问题的形式表达主指令。
不要在控制标签或主要说明的末尾使用句号。
在句子之间使用一个空格。 不是两个。

控件

常规
- 标记每个控件或控件组。异常：
  - 文本框和下拉列表可以使用提示来标记。
  - 下级控件使用其关联控件的标签。自旋控件始终是下级控件。
- 对于所有控件，默认情况下选择最安全（以防止丢失数据或系统访问）的值。 如果安全和可靠不是考虑因素，选择最有可能或最方便的值。
- 首选受约束的控件。 尽可能使用受约束的控件（如列表和滑块），而不是无约束的控件（如文本框），以减少对文本输入的需求。
- 重新考虑禁用的控件。 禁用的控件可能很难使用，因为用户必须从字面上推断出它们被禁用的原因。当用户期望应用控件时禁用该控件，而且他们可以轻松推断出禁用控件的原因。如果用户无法启用该控件，或者他们不希望应用该控件，则删除该控件；或将控件保留为启用状态，但在使用错误时提供错误消息。
  - 提示：如果您不确定应禁用控件还是应提供错误消息，请先编写可能提供的错误消息。如果错误消息包含目标用户不太可能快速推断出的有用信息，请使控件保持启用状态并提供错误。否则，请禁用该控件。
命令按钮
- 优先选择特定标签，而不是通用标签。 理想情况下，用户无需阅读其他任何内容即可了解标签。比起静态文本，用户更有可能阅读命令按钮标签。
  - 例外：如果取消的含义明确，请勿重命名“取消”按钮。用户不必读取所有按钮来确定哪个按钮取消操作。但是，如果不清楚取消的是什么操作，例如当有多个挂起的操作时，请重命名为“取消”。
- 提出问题时，请使用与问题匹配的标签。 例如，提供“是”和“否”响应是或否问题。
- 不要在不是属性表或控制面板项的对话框中使用“应用”按钮。 “应用”按钮表示应用挂起的更改，但使窗口保持打开状态。这样，用户就可以在关闭窗口之前评估更改。但是，只有属性表和控制面板项才有此需求。
- 如果取消操作会使环境恢复到之前的状态（不产生任何副作用），则为按钮添加“取消”的标签；否则，请给按钮添加“关闭”（如果操作已完成）或“停止”（如果操作正在进行中）标签，以表示它会保持当前更改的状态不变。
命令链接
- 始终在一组两个或多个命令中提供命令链接。 从逻辑上讲，没有理由提出只有一个答案的问题。
- 提供明确的“取消”按钮。 不要为此目的使用命令链接。很多时候，用户会意识到他们不想执行某项任务。使用命令链接取消将要求用户仔细阅读所有命令链接，以确定哪一个表示取消。使用显式“取消”按钮，用户可以有效地取消任务。
- 如果提供显式“取消”按钮会留下单个命令链接，请同时提供用于取消的命令链接和“取消”按钮。 这样做可以清楚地说明用户有选择。在表述该命令链接时，要说明它与第一个回复的不同之处，而不是只说 "取消 "或一些变体。
“不再显示此项<>”复选框
- 请考虑使用“不再显示此项<>”选项，以允许用户取消定期的对话框，前提是没有更好的替代方法。 如果用户真的需要，最好始终显示对话框，或者直接消除对话框（如果他们不需要）。
- 将<项>替换为特定项。 例如，“不要再次显示此提醒”。在一般情况下提及对话框时，使用“不要再次显示此消息”。
- 在选项下添加以下句子，明确指示何时将用户输入用于将来的默认值：将在将来默认使用所选内容。
- 默认情况下不要选择该选项。如果对话框真的应该只显示一次，不用问就这样做。 不要使用此选项作为惹恼用户的借口，确保默认行为不会令人恼火。
- 如果用户选择该选项并单击“取消”，则此选项生效。 此设置是元选项，因此它不遵循不留副作用的标准“取消”行为。请注意，如果用户将来不想看到对话框，他们很可能也希望取消对话框。
链接
- 不要分配访问键。使用 Tab 键访问链接。
- 不要将“单击”或“单击此处”添加到链接文本。 这没有必要，因为链接就意味着单击。
工具提示
- 使用工具提示为未标记的控件提供标签。 无需仅仅为了一致性而提供带标签的控件工具提示。
- 如果这样做很有帮助，工具提示还可以为标记的工具栏按钮提供更多详细信息。 不要只是重复或给出标签中已有的内容的措辞重述。
- 避免覆盖用户即将查看或与之交互的对象。 始终将提示放在对象的一侧，即使指针和提示之间需要分离。只要对象与其提示之间的关系清晰，某些分离就不是问题。
  - 例外：列表和树中使用的全名工具提示。
- 对于项集合，请避免覆盖用户可能查看或与之交互的下一个对象。 对于水平排列的项目，请避免将提示放在右侧；对于垂直排列的项目，请避免在下方放置提示。
渐进式披露
- 使用“更多/更少”渐进式披露按钮可隐藏用户通常不需要的高级或很少使用的选项、命令和详细信息。 不要隐藏常用项，因为用户可能找不到它们。但请确保隐藏的任何内容都有值。
- 如果表面始终显示某些选项、命令或详细信息，请使用以下标签对：
  - 更多/更少的选项。 用于选项或选项、命令和详细信息的混合。
  - 更多/更少的命令。 仅用于命令。
  - 更多/更少细节。 仅供参考。
  - 更多/更少的<对象名称>。 用于其他对象类型，例如文件夹。
- 否则:
  - 显示/隐藏选项。 用于选项或选项、命令和详细信息的混合。
  - 显示/隐藏命令。 仅用于命令。
  - 显示/隐藏详细信息。 仅供参考。
  - 显示/隐藏<对象名称>。 用于其他对象类型，例如文件夹。
进度栏
- 对需要一定时间的操作使用确定进度条，即使无法准确预测该时间量。不确定进度条显示正在取得进展，但没有提供其他信息。不要仅仅因为可能缺乏准确性而选择不确定的进度条。
- 如果可以准确估算，请提供剩余时间。 准确的剩余时间估算非常有用，但偏差很大或波动很大的估算则没有帮助。可能需要执行一些处理，然后才能提供准确的估计值。如果是这样，请不要在此初始期间显示可能不准确的估计值。
- 不要重启进度。 如果进度条重新启动（可能是因为操作中的某个步骤完成），进度条将丢失了价值，因为用户无法知道操作何时完成。相反，让操作中的所有步骤共享一部分进度，并让进度条一次完成。
- 提供有用的进度详细信息。 提供其他进度信息，但前提是用户可以利用它做些什么。确保文本的显示时间足够长，以便用户能够阅读。
- 不要将进度条与忙碌的指针组合在一起。 使用其中一种，但不能同时使用两者。
提示
- 当屏幕空间非常有限，不宜使用标签或指令（例如在工具栏上）时，请使用提示。
- 提示主要用于以紧凑方式标识文本框或组合框的用途。 它不得是用户在使用控件时需要查看的关键信息
- 提示文本不得与真实文本混淆。 为此，请按以下步骤操作：
  - 用灰色斜体绘制提示文本，用黑色罗马字体绘制实际输入文本。
  - 提示文本不应可编辑，用户点击文本框或标签进入文本框后，提示文本就应该消失。
    - 例外：如果文本框具有默认输入焦点，则会显示提示，并且在用户开始键入后才会消失。
- 不要使用结束标点符号或省略号。
通知
- 将通知用于与当前用户活动无关、不需要用户立即采取行动且用户可以自由忽略的事件。
- 不要滥用通知：
  - 仅当需要时才使用通知。 当您显示通知时，可能会打扰用户，甚至惹恼他们。要确保中断是合理的。
  - 对不需要用户立即操作的非关键事件或情况使用通知。 对于需要立即用户操作的关键事件或情况，请使用替代 UI 元素（如模式对话框）。
  - 不要对将通知用于功能广告！

键盘

将初始输入焦点分配给用户最有可能首先与之交互的控件，这通常是第一个交互控件。如果第一个交互式控件不是好的选择，请考虑更改窗口的布局。
向所有交互式控件分配制表位，包括只读编辑框。异常：
- 对作为单个控件的相关控件集（如单选按钮）进行分组。此类组具有单个制表位。
- 适当包含组，以便箭头键在组中向前和向后循环，并保留在组中。
选项卡顺序应从左到右，从上到下。 通常，Tab 顺序应遵循阅读顺序。考虑将常用控件进行例外处理，将它们放在 Tab 键顺序的前面。 Tab 应在两个方向上循环遍历所有制表位而不停止。在组中，Tab 顺序应按顺序排列，无一例外。
在制表位中，箭头键顺序应从左到右、从上到动，无一例外。箭头键应在两个方向上循环浏览所有项而不停止。
按以下顺序显示提交按钮：
- 确定/[执行]/是
- [不执行]/否
- Cancel
- 应用（如果存在）

其中 [执行] 和 [请勿执行] 是主要指令的具体响应。

不要将访问键与快捷键混淆。 虽然访问键和快捷键都提供对 UI 的键盘访问，但它们有不同的用途和准则。
尽可能为所有交互式控件或其标签分配唯一访问键。只读文本框是交互式控件（因为用户可以滚动和复制文本），因此它们受益于访问键。不要将访问键分配给：
- “确定”、“取消”和“关闭”按钮。 Enter 和 Esc 用于其访问键。但是，始终将访问键分配给表示“确定”或“取消”、但具有不同的标签的控件。
将快捷键分配给最常用的命令。 不经常使用的程序和功能不需要快捷键，因为用户可以改用访问键。
不要将快捷键设为执行任务的唯一方法。 用户还应能够将鼠标或键盘与 Tab、箭头和访问键一起使用。
不要为已知快捷键分配不同的含义。 因为它们是记忆性的，所以众所周知的快捷方式的含义不一致会令人沮丧并且容易出错。
不要试图分配系统范围的程序快捷键。 仅当程序具有输入焦点时，程序的快捷键才会生效。

鼠标

切勿要求用户点击对象以确定其是否可点击 用户必须能够仅通过目测来确定是否可点击。
- 主要 UI（如提交按钮）必须具有静态单击提示功能。用户不必将鼠标悬停来发现主要 UI。
- 辅助 UI（如辅助命令或渐进式披露控件）可以在悬停时显示其单击提示。
- 文本链接应静态提示链接文本，然后在悬停时显示单击提示（带手指针的下划线或其他表现形式更改）。
- 图形链接仅在悬停时显示手指针。
仅对文本和图形链接使用手（或“链接选择”）指针。 否则，用户必须单击对象来确定它们是否为链接。

对话框

模式对话框需要交互，因此，在继续执行任务之前，请将其用于用户必须响应的内容。 确保中断是合理的，例如对于需要完成的关键或非经常性一次性任务。否则，请考虑无模式替代方法。
无模式对话框不需要交互，因此当用户需要在对话框和所有者窗口之间切换时使用它们。 它们最适合用于频繁、重复或正在进行的任务。但是，功能区、工具栏和调色板窗口通常是更好的替代方法。

属性表

确保属性是必需的。 不要为了避免做出艰难的设计决定，而在属性页面中添加不必要的属性。
从用户目标而非技术角度展示特性。 仅仅因为属性配置特定技术并不意味着必须以该技术呈现该属性。
- 如果您必须从技术角度来呈现设置（可能是因为您的用户认识该技术的名称），请简要描述用户利益。
使用特定的有意义的选项卡标签。 避免使用可应用于任何选项卡的通用选项卡标签，例如“常规”、“高级”或“设置”。
避免使用常规页面。 无需拥有“常规”页。仅在以下情况下使用“常规”页：
- 这些属性适用于多个任务，并且对大多数用户有意义。不要在“常规”页上放置专用属性或高级属性，但您可以通过“常规”页上的命令按钮访问它们。
- 这些属性不适合更具体的类别。如果这样做，请改用该名称作为页面名称。
避免高级页面。 仅在以下情况下使用高级页面：
- 这些属性适用于不常见的任务，主要对高级用户有意义。
- 这些属性不适合更具体的类别。如果这样做，请改用该名称作为页面名称。
如果属性窗口只有一个选项卡且不可扩展，请不要使用选项卡。 请改用带有“确定”、“取消”和可选“应用”按钮的常规对话框。但是，可扩展属性窗口（可由第三方扩展）必须使用选项卡。

向导

首先考虑轻型替代项，例如对话框、任务窗格或单页。 向导是一种繁重的 UI，最适合用于多步骤、不经常执行的任务。您不必使用向导，即可在任何 UI 中提供有用的信息和帮助。
仅当无需承诺即可前进到下一页时才使用“下一页”。 如果无法通过单击“后退”或“取消”来撤销前进到下一页的效果，则将其视为承诺。
仅使用“返回”更正错误。 除了更正错误，用户也不应该为了完成任务而点击“返回”。
当用户提交到任务时，请使用提交按钮，该按钮是主要指令的特定响应（例如打印、连接或开始）。 不要使用通用标签（如“下一步”（这并不意味着承诺）或“完成”（不具体））来提交任务。这些提交按钮上的标签本身应该有意义。提交按钮标签始终以动词开头。 异常：
- 当特定响应仍为通用时，例如“保存”、“选定”、“选择”或“获取”，请使用“完成”。
- 使用“完成”可更改特定设置或设置集合。
仅对选项使用命令链接，而不使用承诺。 特定的提交按钮比向导中的命令链接更能表明承诺。
使用命令链接时，请隐藏“下一步”按钮，但保留“取消”按钮。
对“跟进”和“完成”页使用“关闭”。 请勿使用“取消”，因为关闭窗口不会放弃此时所做的任何更改或操作。不要使用“完成”，因为它不是祈使式动词。
不要在向导名称中使用“向导”。 例如，使用“连接到网络”而不是“网络设置向导”。但是，可以接受将向导称为向导。例如：“如果您是第一次设置网络，可以使用‘连接到网络’向导获取帮助”。
通过导航保留用户选择。 例如，如果用户进行更改，请单击“返回”，然后单击“下一步”，这些更改应被保留。除非用户明确选择清除更改，否则用户不需要重新输入更改。

向导页面

专注于高效的决策。 减少关注基本信息的页面数。合并相关页面，并将可选页面从主流程中移除。让用户完全通过向导单击“下一步”起初看起来可能是一种不错的体验，但如果用户永远不需要更改默认值，则这些页面可能就没有必要了。
请勿使用欢迎页，尽可能使第一页具有功能性。 仅在以下情况下使用可选的“开始”页：
- 向导具有成功完成向导所需的先决条件。
- 用户可能无法根据向导的第一个“选择”页面了解向导的目的，并且没有进一步说明的空间。
- 开始页面的主要说明是“开始之前：”。
在要求用户做出选择的页面上，针对最有可能出现的情况进行优化。 这类页面应该提供实际选择，而不仅仅是说明。
- 如果不使用“开始”页，请在第一页选择的顶部解释向导的目的。
使用“提交”页面明确用户何时提交任务。 通常，“提交”页是选项的最后一页，并重新标记“下一步”按钮以指示正在提交的任务。
- 不要使用仅汇总用户先前选择的摘要页面，除非任务有风险（涉及安全性、时间或金钱损失），否则用户很可能不了解他们的选择，并且需要查看它们。
不要使用除了结束向导未执行任何操作的祝贺页面。 如果用户能清楚地看到向导结果，只需在最后提交按钮上关闭向导即可。
- 当用户可能执行后续操作的相关任务时，请使用“跟进”页面。避免熟悉的后续任务，例如“发送电子邮件”。
- 仅当结果不可见并且没有更好的方法为任务完成提供反馈时，才使用“完成”页。
- 具有进度页的向导必须使用“完成”页或“跟进”页来指示任务完成。对于长时间运行的任务，请关闭“提交”页上的向导，并使用通知提供反馈。

错误消息

如果用户不太可能根据消息执行操作或更改其行为时，则不要提供错误消息。如果没有用户可以执行的操作，或者问题不重要，请禁止显示错误消息。
尽可能提出解决方案，以便用户解决问题。 但是，请确保建议的解决方案有可能解决问题。不要浪费用户的时间，提出有可能但无法实现的解决方案。
具体。 避免使用模糊措辞，例如语法错误和非法操作。提供涉及对象的特定名称、位置和值。
不要使用指责用户或暗示用户错误的措辞。 避免在措辞中使用“你”和“你的”措辞。虽然主动语态通常更受欢迎，但当用户是主体，如果使用主动语态可能会因错误而感到自责时，还是要使用被动语态。
不要对错误信息使用“OK”。 用户不会认为错误是“OK”的。如果错误消息没有直接操作，请改用“关闭”。
请勿使用以下词语：
- 错误，失败（改用“问题”）
- 未能（改用“无法”）
- 非法、无效、错误（改用“不正确”或“无效”）
- 中止、终止（改用“停止”）
- 灾难性、致命（改用“严重”）

这些术语既无必要，也有悖于 Windows 鼓励性的基调。相反，正确使用错误图标会充分表明存在问题。

错误消息不要伴有音效。 这样做令人不快且没有必要。

警告消息

警告描述的是将来可能导致问题的情况。 警告不是错误或问题，因此不要将常规问题描述为警告。
如果用户不太可能根据消息执行操作或更改其行为时，则不要提供警告消息。 如果没有用户可以执行的操作，或者情况并不严重，请取消警告息。

确认

不要使用不必要的确认。 仅在以下情况下使用确认：
- 有明确的理由不继续进行，而且有时用户不继续进行也是合理的。
- 该操作具有重大后果，或者无法轻易撤消。
- 该操作会产生用户可能不知道的后果。
- 继续操作要求用户做出没有合适默认值的选择。
- 考虑到当前情况，用户很可能执行了错误的操作
用是或否的问题来表述确认，并提供是或否的答案。 与其他类型的对话框不同，确认旨在防止用户做出快速决策。如果用户没有将其视为响应，则确认没有价值。

图标

所有图标都应遵循 Aero 风格图标准则。替换所有 Windows XP 风格图标。
根据标准图标的消息类型选择标准图标，而不是基础问题的严重性：
- 错误。 发生了错误或问题。
- 警告。 将来可能会引起问题的情况。
- 信息。 有用信息。

如果问题结合了不同的消息类型，请关注用户需要处理的最重要方面。

图标必须始终与主指令或其他相应文本匹配。
非关键用户输入问题不需要错误图标。 但是，就地错误需要图标，否则这种上下文反馈很容易被忽视。
不要使用警告图标来“软化”非严重错误。 错误不是警告；请应用错误图标指南。
对于问题对话框，请仅对产生重大后果的问题使用警告图标。 不要对常规问题使用警告图标。

帮助

指向特定相关帮助主题的链接。 请勿链接到帮助主页、目录、搜索结果列表或仅链接到其他页面的页面。避免链接到以大量常见问题列表形式构建的页面，因为这会迫使用户搜索与他们点击的链接匹配的页面。不要链接到与当前任务无关且无帮助的特定帮助主题。从不链接到空页面。
不要将帮助链接放在每个窗口或页面上，以便保持一致性。 在一个位置提供帮助链接并不意味着必须在所有地方提供它们。
只要有可能，短语“帮助”就会根据帮助内容所解答的主要问题来链接文本。 不要使用“了解更多”或“获取相关帮助”的措辞。
使用整个帮助链接作为链接文本，而不仅仅是关键字。
使用完整的句子。
不要使用结尾标点符号或省略号，但问号除外。
如果帮助内容处于联机状态，请在链接文本中明确说明。 这样做有助于预测链接的结果。