向导

注意

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

尽管这个奇妙、异想天开的名字，但向导并不是一种特殊的用户界面形式，而且它们只有特定的效用范围。

向导用于执行多步骤任务。

向导的多个步骤显示为一系列页面。

向导通常包括以下类型的页面：

• 选项页用于收集信息并允许用户做出选择。
• “提交”页用于执行无法通过单击“返回”或“取消”撤消的操作。
• “进度”页用于显示长时间操作的进度。

新式向导设计注重效率，使“进度”页可选项用于更短的操作，并且通常在开头和结尾省去传统的 欢迎页 和 恭喜页面 。

所有向导页都具有以下组件：

• 用于标识向导名称的标题栏，左上角有一个“后退”按钮，以及一个带有可选“最小化/最大化”和“还原”按钮的“关闭”按钮。 请注意，标题栏还包括一个图标，用于在任务栏上标识它。
• main说明，用于通过页面解释用户的目标。
• 具有可选文本和可能的其他控件的内容区域。
• 具有至少一个提交按钮的命令区域，用于提交到任务或继续执行下一步。

尽管向导有多个步骤，但从用户的角度来看，这些步骤必须全部添加到单个任务中。 这是“一个向导，一个任务”的基本向导设计原则。

因此，在本文中，任务是向导的基本功能 (例如，安装向导的任务是) 安装程序。 子任务是较大任务 (例如，安装向导的子任务可能是将程序配置为) 安装。 最后，每个向导页被视为给定子任务或任务 (中的一个步骤，例如，配置程序) 可能涉及两到三个步骤。

注意： 单独的文章中提供了与 设置、 对话框和 进度栏 相关的指南。

这是正确的用户界面吗？

向导可用于需要多个输入步骤的任何任务。 但是，有效的向导还有其他要求：

• 向导是否执行单个原子任务？ 不要使用不是单个任务的交互， (整个程序绝不应是向导，除非它执行单个任务) 。 不要使用向导来组合独立任务或基本上不相关的步骤。

• 是否可以减少所需问题的数量？ 是否有可接受的默认值，这些默认值适用于大多数情况，或者以后可以根据需要进行调整？ 因此，是否可以减少页数？ 如果是这样，请尝试简化任务，使其可以在单个页面上显示， (如对话框) ，或者无需完全输入 (允许直接) 执行任务。

• 必须按顺序提供所需问题吗？ 有几个可能但可选的问题吗？ 如果是，请考虑使用对话框或选项卡式对话框。

  正确：

  

  Microsoft PowerPoint 打印选项对话框包含许多用户输入选项，因此你可以在向导中显示它们。 但是，无需按顺序提供它们，因此对话框是更好的选择。

向导是一种相对繁重的用户界面形式;如果有合适的、更轻的解决方案可用，请使用它！

设计概念

过度使用向导

从历史上看，向导不同于普通 UI，因为它们旨在帮助用户执行特别复杂的任务， (步骤驻留在不同位置) ，并且通常具有内置智能来帮助用户成功。 目前，所有 UI 都应设计为使任务尽可能简单，因此无需出于此目的而使用特殊 UI。

然而，人们仍然相信向导是一种特殊的 UI，这主要是因为它们被称为“向导”， (比“对话”和“属性窗口”) 更具创造性。 相反，最好将它们视为多步骤任务，而不是特别注意这一事实。

在创建向导之前，请考虑是否确实必须中断用户从程序main流。 可能有一个更轻的内联上下文解决方案，最终会觉得对用户更有帮助和更高效。 例如，程序中设计不当的功能不需要向导来解释和简化它;它需要重新设计功能本身。 不应将向导用作带助修复程序更基本的问题。

向导确实具有适当的功能

向导是简化用户体验的关键之一。 它们允许你执行复杂的操作（例如程序配置），并将其分解为一系列简单的步骤。 在此过程中的每个时间点，都可以提供所需内容的说明，并显示允许用户进行选择和输入文本的控件。

某些类型的多步骤任务适合向导窗体。 例如，在 Windows 中，一些向导涉及 (Internet 或公司网络或外围设备（如打印机和传真机）) 的连接功能。

连接到网络是 Windows 中适用于向导的典型任务。

此处，向导的功能是在现成的操作系统) (已知和稳定的东西与与电话公司或 Internet 服务提供商) 的连接安排 (未知和可变内容之间进行调解。 计算生态系统的复杂性已经足够大了，因此使用向导来降低这种复杂性确实很有帮助。

适用于 Windows 向导的其他类型的任务包括高端功能 (（如语音和手写识别) ）和丰富的媒体体验 (（例如配置用于制作和发布电影) 的选项）。 还可以为更基本的多步骤任务（例如故障排除）部署向导。 简言之，如果不同的用户可能希望以截然不同的方式体验你的程序，这可以指示需要向导及其用于多个用户输入点的容量。

对于程序来说，提前一点设计时间来确定向导正在服务的函数，以及该函数是否真的上升到部署向导的级别是值得的。

向导长度

设计问题自然会出现在页面和选项的数量和组织方面。 例如：

• 向导的页数是否最佳？ 还是至少一个所需的范围？
• 向导是否应简洁和简化，以便用户可以尽快完成它？
• 是否应该有更多的页面需要更少的选择？ 还是复杂性更高的页数更少？ 哪种设计更可用？
• 能否通过应用 UI 约定（如选项卡式页面）来设计更快的向导体验？

Microsoft 曾建议将三个或更少页面的向导设计为简单向导，而四个或更多页的向导使用高级向导设计， (请参阅 1999) 中的 Windows 用户体验 指南。 但是，当前的向导设计标准省去了简单和高级表单 (使用欢迎和祝贺页面) 之间的主要差异之一，因此这些类别现在感觉不足，并且决定设计选择的页数似乎任意。

向导的长度应与任务要求一样长或短;其长度没有固定的准则。 单页向导实际上应该显示为一个对话框，因此对于向导来说，两页可能是最精简的窗体。

正确：

此任务的选项太少，因此将其呈现为向导会浪费。 对话框是此用户界面的相应形式。

在范围的另一端，如果向导包含多个决策点和分支，并且经常导致用户失去导航路径的跟踪，则表示已超出实际限制，应减少向导的长度。 或者，可以将向导分解为多个不同的任务。

确定最适合向导的长度时，请特别注意目标用户。 面向最终用户（如家庭消费者和办公室工作人员）的程序往往使用向导来隐藏复杂性;向导尽可能短，具有简洁、简单的页面设计，并为尽可能多的选项预先选择默认值。 相比之下，面向 IT 专业人员的服务器向导或程序往往更长、更复杂。 这组目标用户对做出配置决策的容忍度要高得多，如果隐藏了太多复杂性，实际上可能会变得可疑。

如果向导本质上简化了复杂的任务，那么对于技术复杂的受众来说，它应该相对最少地执行，而对于新手用户群来说，它应该相对积极。

正确：

此向导页专为最终用户设计，因为它减少了简单的逻辑二进制选择（安装或卸载）的潜在复杂主题。

正确：

在 Microsoft SQL Server 2008 的设置向导中，页面设计更加繁忙，许多选项需要更多思考，但目标受众是希望严格控制功能选择的数据库管理员。

最后，请注意执行特定任务的频率。 不经常执行的任务可能会部署较长的向导，而频繁执行的任务肯定更简洁。

分支创建

对于较长的向导，可能需要创建任务流的分支，其中页面序列可能会根据用户提供的“上游”输入而有所不同。分支本质上是用户不分配的，因此必须设计用户体验来传达稳定性。 建议在整个向导中不要超过两个会导致分支的决策点，单个分支中不要有一个嵌套分支。

有关在分支向导中创建稳定用户体验的指南，请参阅本文指南部分中的 分支 。

提供导航指南

当任务中有许多步骤时，导航指南非常有用，用户可能会失去在序列中的位置，或者只是想要知道需要多长时间才能完成。

导航指南通常显示为向导的页面或部分列表，看起来有点像目录，位于每页左侧的列或窗格中。 尽管该列表在整个向导中保留 (同一页列表显示在每) 页上，但有一些视觉方法可以指示用户当前按顺序 (的位置，例如，使用粗体来区分活动页面或部分) 。

导航参考线可以是顺序的，也可以是非顺序的。 顺序类型显示过去的页面以及已知的未来页面。 如果步骤已知且页面是依赖的，则可以用步骤（而不是页面）来呈现未来。 然后，可以在页面变得已知时动态填充页面。 由于导航顺序是固定的，因此导航指南不是交互式的。

非顺序导航指南是交互式导航指南，因此用户可以直接重新访问以前查看的页面。 对于设计为可选的页面，它们还可以跳过导航序列。 可选页面必须具有在大多数情况下可接受的默认值。 使用此类型的指南：

• 以前查看过的页面始终可以直接查看。
• 如果将来的页面具有先决条件，则可能无法查看它们。
• 应将可以访问的页面与无法 (的页面进行明显区分，例如使用) 活动或禁用的链接，以及必需或可选的页面。

在这种情况下，用户可能会对“后退”按钮的含义感到困惑。 单击“后退”会引导你访问导航指南中的上一页或部分，还是查看的最后一页或部分？ 由于 Windows 向导现在将“后退”按钮放在向导页的左上角，而不是与其他提交按钮一起放在右下角，因此用户会像在 Web 上一样考虑“后退”功能。 因此，最佳解决方案是为后退按钮提供 Web 导航，这意味着 (单击“后退”会指向) 查看的最后一页或部分，并使用向导导航指南进行顺序导航。

页面完整性

向导设计不仅涉及与整个任务流相关的决策（如如何处理导航和分支体验），还涉及与构成向导的各个页面相关的决策。 设计良好向导页面的最重要原则是完整性：页面的内容应属于一起。

如果每个页面在概念上挂在一起，仅处理整体任务的一个方面，则向导页面的可用性要高得多。 main指令是实现此目标的主要方法。 向用户明确标识页面的目标或用途。 补充说明和页面上的任何控件都直接与main指令相关。 尽管向导页面应该向用户提供需要一些想法的选项，但这种工作感觉并不奏效，因为它与页面本身的完整性紧密联系在一起。

遗憾的是，向导设计人员经常误认为用户快速单击“下一步”按钮是页面可用性、简单性和完整性的证据。 最终的向导体验不是“下一步”、“下一步”、“下一步”、“下一步”、“完成”。 虽然这种体验表明默认值是精心选择的，但它也表明向导并非真正必要，因为所有选项都是可选的。

在视觉对象和文本方面，将这些元素缩减为裸体。 抵制将多个子任务捆绑在单个页面上的冲动， (“burrito 向导”) 或求助于选项卡来呈现复杂的输入要求。 单个页面应涵盖向导整体任务的单个子任务。

不正确：

由于需要三个选项卡的相当密集的用户输入，此向导页尝试完成太多操作。

在大多数情况下，在整个向导中维护每个页面的大小，以形成一致的外观。 尽管 Windows 向导允许调整大小的页面，以便页面的大小与内容量匹配，但只有少数向导使用此选项。

最后，通过 序列维护每个向导页的结构元素。 例如，不要将左上角的“后退”按钮移回一两页的提交按钮区域。 此级别的布局一致性可帮助用户在向导中感觉稳定。 将此视为页面视觉完整性的基线。

查找适当的通信级别

用户在屏幕上阅读大块文本的容忍度较低，在 UI 界面中，更不容许其明确用途是快速完成任务。

向导倾向于过度沟通。 它们在屏幕上占用了大量空间，这似乎鼓励驱动器填充空间。 这就像帕金森定律的变体：UI 文本将展开以填充可用空间。

这种过度的罪魁祸首之一是冗余。 由于早期向导设计中使用的模板，同一语言可能会出现在页面上的多个位置，例如标题栏、标题、正文文本、控件标签等。

聘请专业编辑无情地修剪向导文本是值得的。 消除单个页面上不必要的问题和选项，并消除整个向导中的整个页面作为一个整体 (例如，传统的欢迎和祝贺页面) 。 使用目标受众用于描述任务的语言（而不是你或你的团队内部使用的技术或功能的行话）使用简明的main说明，直接到达页面的位置。 这种以用户为中心的方法对于改进程序向导的通信至关重要。

特别注意向导的语气：有时程序最持久的印象不是你说什么的结果，而是你怎么说的结果！ 在向导中，用户可以使用友好的对话语气，当程序要求输入时，自由使用第二人称代词 (“you”) 。 有关更多指南，请参阅 样式和音调。

减少向导页面上的字数通常值得称赞，但请注意不要走得太远。 如果任务很重要，并且需要向导，用户确实希望有足够的信息做出明智的选择。 以下示例演示如何在不牺牲含义的情况下压缩向导文本。

之前：

之后：

此向导页的编辑版本提供面向任务的main指令，删除main指令下不必要的解释性段落，并修订检查框标签以阐明检查框的用途。

如果你只做三件事...

1. 使用适当的 UI 映射要完成的任务，以便执行该作业;当你认为需要从用户那里收集大量输入时，不要简单地默认为向导。

2. 仔细考虑向导的长度和结构;希望使用短的、非分支的向导来尽可能简单地保持体验，以便用户可以返回到其主要任务或对程序的兴趣。

3. 确保向导中每个页面的完整性：页面的内容应明确属于一起。

准则

常规

• 首先考虑轻型替代项，例如对话框、任务窗格或单页。 无需使用向导， 可以在任何 UI 中提供有用的信息和帮助。

• 使用向导执行多步骤任务。 使用多页对话框执行具有反馈的单步任务。 有关更多指南，请参阅 对话框。

  正确：

  

  

  在此示例中，Windows 网络诊断由进度和结果页组成。 由于任务只是一个步骤，因此它不需要用户在向导中所需的导航按钮。 它实际上显示为多页对话框。

窗口大小

• 选择一个窗口大小，该大小可以显示所有向导页面，而无需垂直或水平页面滚动。 虽然页面上的控件可能需要滚动，但向导页面本身不得滚动。

• 将窗口大小调整到足以舒适地执行任务。 页面布局不应狭小或要求用户过度滚动或调整大小。

• 但不要使窗口过大。 更大的窗口使任务感觉更复杂，并且需要额外的移动才能进行交互。

• 对于可从更多屏幕空间中受益但不需要屏幕空间的向导，请使用可调整大小的窗口。 分配适当的最小大小。 当页面需要与可调整大小的内容（如大型列表视图）交互时，可调整大小的窗口非常有用。

  正确：

  

  良好：

  

  在此示例中，调整窗口大小可帮助用户查看完整列表。

• 请考虑使用动态大小的向导，其页面大小会根据其内容需要而更改。 这样一来，向导就可以适应包含各种内容的页面布局。

• 如果用户可能认为更改在其向导体验中缺乏稳定性，则首选静态大小调整而不是动态调整。 视觉稳定性通常胜过内容的调节。 大多数向导应采用标准静态窗口大小，并保留动态大小以用于特殊情况。

向导长度

• 使向导尽可能简洁和简化。 删除不必要的选项和问题，并使用智能默认值来减少用户输入所需的页数。
  • 例外： IT 专业人员和其他技术用户对较长的向导和详细的输入要求具有更高的容忍度。
• 使向导至少包含两页。 应改为将单页向导重新设计为对话框。
• 不要仅仅通过增加每个页面的复杂性来减少向导的页计数。 例如，包含三个需要用户输入的选项卡的向导页应重新设计为三个单独的页面。
• 不要通过使每一页变得如此简单，以便用户在整个序列中不经意地单击“下一步”来增加向导的页计数。 这是一个常见的向导设计缺陷。 如果向导页不需要至少进行某种程度的思考，则它可能根本不需要在向导中。

分支创建

• 首选非分支向导设计，而不是分支。 非分支向导往往更简单、更短且易于导航。 分支向导使用户更难确定任务中的步骤数及其在序列中的位置。

• 如果必须进行分支，请使用以下方法之一帮助用户定位自己：

  • 枚举页面。 一种常见方法是指示用户在每个页面上序列中的位置，例如使用短语“步骤 X/Y”。确保终结点 (Y) 稳定。 如果更改值，则会破坏用户的信心。

  • 包括子步骤的概念 (如步骤 2a（共 6) ）。

  • 使步骤独立于页面，其中每个步骤可能涉及多个页面。 例如，旅行服务可能基于行业已建立的电子商务约定使用向导组织。

    正确：

    

    逻辑标签可以为分支向导的用户提供足够的方向。

  • 将可选步骤视为枚举序列中的持久性步骤。 例如，如果分支只是跳过几个可选步骤，则只需跳过反馈中的步骤，而不是重新编号。 因此，如果用户在页面 2 上做出选择，导致第 3 页和第 4 页可选，则显示步骤 1、2、5 和 6（共 6 步）。 不要对步骤 5 和 6 重新编号。

  • 如果向导使用单个分支，并且分支在任务早期发生，请在该点启动序列，然后直接使用非分支方法。 也就是说，从分支点开始，按顺序前进到分支的末尾。

• 如果必须进行分支，请在单个向导中将分支数限制为一个或两个分支。 切勿在分支中包含多个分支 (“嵌套”分支) 。

提交按钮

• 当用户提交任务时，请使用提交按钮，该按钮是对main指令 (的特定响应，例如打印、连接或开始) 。 请勿使用泛型标签（如“下一步” (这并不表示承诺) 或完成 (这不是提交任务的特定) 。 这些提交按钮上的标签本身应该有意义。 始终使用谓词启动提交按钮标签。 异常：
  • 当特定响应仍为泛型时，请使用“完成”，例如“保存”、“选择”、“选择”或“获取”。
  • 使用 Finish 更改特定设置或设置集合。
• 单个向导可以有多个提交点，但首选单个点。
• 如有必要，可以重命名或隐藏页面上的提交按钮。 这种灵活性是 Windows 中新向导设计的优势之一，而旧版向导中却不可用。 请注意，隐藏提交按钮不同于禁用它。
• 避免禁用正面提交按钮。 否则，用户必须推断禁用提交按钮的原因。 最好让提交按钮保持启用状态，并在出现问题时提供有用的错误消息。 仅当这样做的原因明显且明确时，才能接受禁用按钮。
• 不要将导航按钮 (“下一步”和“上一) ”与“提交”按钮混淆。 下一步意味着在不承诺的情况下在向导中取得进展;“后退”应始终在下一页上可用，单击“后退”应撤消上一个“下一步”按钮的效果。 如果这是不可能的，则用户正在做出承诺，并通过提交按钮上的特定标签来指示这一点。 有关“下一步”和“后退”按钮的更多指南，请参阅 导航。

“取消”按钮

• 不要要求用户确认他们是否确实打算取消。 这样做可能会令人讨厌。 异常：
  • 此操作具有重大后果，如果不正确，则无法轻松修复。
  • 此操作可能会导致用户时间或精力的显著损失。
  • 该操作显然与其他操作不一致。
• 允许用户重启向导，以防他们因错误取消。
• 请勿禁用“取消”按钮。 异常：
  • 如果取消是有害的，则可能会在独立向导中执行任务时出现这种情况。
  • 如果无法取消，则可能是向导无法控制所有步骤的情况。

“关闭”按钮

• 对“Follow-Up”和“完成”页使用“关闭”。 请勿使用“取消”，因为关闭窗口不会放弃此时执行的任何更改或操作。 请勿使用 Done，因为它不是命令性谓词。
• 执行任务后，“取消”应成为) 独立向导的“关闭” (。 关闭的效果只是关闭窗口。

其他控件

• 仅将命令链接用于选项，而不用于承诺。 特定提交按钮表示承诺比向导中的命令链接好得多。
• 使用命令链接时，请隐藏“下一步”按钮，但保留“取消”按钮。

使用页面 (与对话框或内联 UI)

• 通常，页面优先于对话框。 用户希望向导是基于页面的。
• 使用对话框来帮助完成页面， 例如使用对象选取器和浏览器。
• 使用对话框提供适用于整个页面的错误消息，以及单击提交按钮导致的错误消息。
• 使用内联演示文稿进行简单的动态行为， 例如渐进式披露和上下文 UI。
• 对应用于特定控件的错误消息使用内联演示文稿。

向导页面

• 专注于高效决策。 减少页数，以专注于基本信息。 合并相关页面，并从main流中取出可选页面。 让用户在向导中完全单击“下一步”可能看起来是一个很好的体验，但如果用户永远不需要更改默认值，则可能不需要页面。

• 将每个页面设计为具有单一用途和视觉一致性。 有关详细信息，请参阅 页面完整性。

• 请勿使用欢迎页面 - 尽可能使第一页正常运行。 仅在以下情况下才使用可选入门页：

  • 向导具有成功完成向导所需的先决条件。
  • 根据向导的第一个“选择”页，用户可能无法理解该向导的用途，并且没有进一步解释的余地。
  • 入门页main说明为“开始之前：”。

  不正确：

  

• 新式向导选择功能第一页。 此处除了单击“下一步”，无需执行任何操作。 为什么强制用户在其宝贵的时间支付此令牌税？

• 在要求用户做出选择的页面上，针对最可能的情况进行优化。 这些类型的页面应提供实际选择，而不仅仅是说明。

  • 如果不使用入门页，请在第一页选项顶部说明向导的用途。

• 使用“提交”页在用户提交任务时明确说明。 通常，“提交”页是选项的最后一页，“下一步”按钮会重新标记以指示正在提交的任务。

  • 请勿使用仅汇总用户先前选择的摘要页面，除非任务 (涉及安全性，或者时间或金钱损失) ，或者用户很有可能需要查看其选择。

• 使用“进度”页可显示长时间操作的状态。 成功完成后，进度页应自动转到下一步。 仅当用户需要看到的问题时，它才应保留在进度页上。 单击“返回进度”页应该不会产生任何副作用。

  • 使用单个确定的进度栏。 遵循 确定的进度栏准则，包括：
    • 清楚地指示完成。 除非操作已完成，否则不要让进度栏达到 100%。
    • 不要重启进度。 如果 (重启进度栏会丢失其值，可能是因为操作中的某个步骤完成) 因为用户无法知道操作何时完成。 相反，让操作中的所有步骤共享一部分进度，并让进度栏完成一次。
  • 提供进度栏上方当前步骤的简明说明。 对于快速操作，此类文本是不必要的;仅使用进度栏就足够了。 对于需要一分钟或更长时间的操作，文本可能会有所帮助。
    • 使用句子片段，通常以谓词开头，以省略号结尾。 示例：正在复制文件...、安装所需的组件...
    • 将文本放在条形图上方，而不是下方。
    • 不正确：
    • 
    • 在此示例中，解释性文本应显示在进度栏上方。
    • 不要将进度页乱乱显示不必要的详细信息。 此页不用于技术支持;它适用于用户。
    • 不正确：
    • 
    • 在此示例中，GUID 等技术详细信息对用户毫无意义。

• 请勿使用不执行任何操作但结束向导的祝贺页面。 如果向导结果对用户非常明显，只需在最终提交按钮上关闭向导即可。

  • 当用户可能执行相关任务作为后续任务时，请使用Follow-Up页面。 避免熟悉的后续任务，例如“发送电子邮件”。
  • 仅当结果不可见且没有更好的方法为任务完成提供反馈时，才使用“完成”页面。
  • 具有“进度”页的向导必须使用“完成”页或Follow-Up页来指示任务完成。 对于长时间运行的任务，请关闭“提交”页上的向导，并使用通知提供反馈。

• 仅当输入复杂且用户需要查看时，如果任务涉及重大风险 (（例如财务转换) ），或者向导会根据用户输入采取不明显的操作， (通过透明) 建立信任时，才使用“摘要”页面。 通常，摘要页面不符合此相关性栏，可以省略。

• 如果由于无法从中恢复的问题而无法完成向导，请使用错误页。 在此页面上，用明确的语言解释问题是什么，没有技术行话的用户将无法理解。 此外，提供用户可采取的实际步骤来解决问题。 有关更多指南，请参阅 错误消息。

  • 例外： 如果向导完成时出现可从中恢复的次要问题，请将问题作为附加任务而不是错误呈现。 使用积极、面向成功、鼓励的语言，而不是错误、失败或问题等术语。 请勿使用错误图标。

导航

• 仅当在没有承诺的情况下前进到下一页时，才使用“下一步”。 如果无法通过单击“后退”或“取消”撤消其效果，则前进到下一页被视为承诺。
• 仅使用“返回”来更正错误。 除了更正错误之外，用户不必单击“上一步”就能在任务中取得进展。
• 通过导航保留用户选择。 例如，如果用户进行更改，请单击“后退”，然后单击“下一步”，应保留这些更改。 用户不需要重新输入更改，除非他们明确选择清除更改。
• 除非重复这些步骤有害，否则不要禁用“后退”按钮。
• 允许用户在以下导航方案中浏览或修订选项：
  • 用户提供输入，单击提交按钮，单击“返回”以查看以前的更改，不更改任何内容，然后再次单击“提交”按钮。 通常，这应该是可能的，第二个提交应该只是进入下一页 (，因为任务已经) 完成。
  • 用户提供输入，单击提交按钮，单击“返回”以查看以前的更改，更改某些内容，然后再次单击“提交”按钮。 通常，这应该是可能的，第二个提交应使用更改的输入重做任务， (替换或撤消第一个) 的效果。

帮助

• 设计向导页面以提供足够的信息，以便无需在程序帮助中引用文档。 向导已经将用户从与程序所需的直接交互中带走;要求用户寻求外部帮助会进一步将其从此状态中删除。 帮助应该是例外，而不是规则。
• 如果必须提供帮助的访问点，请使用页面内容区域左下角的链接 (命令区域) 上方。 此链接应是简短的，通常以用户最可能希望回答的问题的形式使用短语。
• 正确：
• 
• 此帮助链接很合适，因为这样的基本背景信息会使向导页面变得混乱。

文本

常规

• 使用你和你的 引用用户和用户的计算机、文档、设置等。 请勿使用第一人称 (我、我的) 来引用计算机或向导。 但是，在用户选择的选项中使用第一个人身份是可以接受的。 示例：我仅使用 检查 框。
• 每个向导页都必须有main指令。

标题

• 将向导的名称放在标题栏中。 使用 标题样式大写。
• 标题不应包含标点符号，带问号的标题除外。
• 请勿在向导标题中包含“向导”一词。 例如，使用“连接到网络”而不是“网络设置向导”。

按钮

• 不要在“后退”按钮上包含文本。 请改用未标记的箭头字形。

• 在“下一步”按钮上添加文本。 除了“下一步”一词之外，请勿使用字形 (，如 > 或 >>) 。

• 使用特定的提交按钮标签，这些标签本身有意义，并且是对main指令的响应。 理想情况下，用户无需阅读任何其他内容即可了解标签。 用户读取命令按钮标签的可能性远高于静态文本。

• 如果可能，请不要对提交按钮标签使用“完成”一词，因为通常有一个更好、更具体的提交按钮：

  • 如果单击该按钮提交到任务 (因此任务尚未) 执行，请使用以谓词开头的特定标签，该谓词是响应main指令 (示例：Print、Connect、Start) 。

  • 如果已在向导中执行任务，请改用 Close。

    异常：

    • 当特定标签仍为通用标签（例如“保存”、“选择”、“选择”或“获取”）时，可以使用“完成”。
    • 当任务涉及更改设置或设置集合时，可以使用“完成”。

• 使用谓词启动提交按钮标签。 例外为“正常”、“是”和“否”。

• 使用 句子样式大写。

• 不要使用结束标点符号。

文档

• 尽管大多数 Windows 向导在标题中不再具有“向导”一词，但在文档中将向导称为向导是可以接受的。 此引用应为小写。
• 正确：
• 如果是首次设置网络，可以使用 “连接到网络 ”向导获取帮助。
• 早期 Windows 版本中的某些旧版向导可能会在标题中包含 Wizard。 在引用其中一个向导时，可以使用 [X] 向导来避免说出 [X] 向导。
• 将向导中的单个屏幕作为页面引用。