guided-gui-design

引导式 GUI 设计

在产品本身必须教会用户如何使用时，用此技能设计面向用户的屏幕。

此技能与 gui-standards 规则模块相辅相成： gui-standards 规定不可妥协的义务；此技能则提供其背后的理论、设计视角、工作流和判断指导。

需要了解其基本原理、具名来源锚点或更深入的审查视角时，请阅读 references/hci-usability-foundations.md。

核心目标

设计屏幕，让首次使用的用户无需额外的聊天说明，也能理解：

1. 此屏幕能帮助他们实现什么目标。
2. 他们应该先做什么。
3. 他们当前正在操作什么状态。
4. 哪个结果最重要。
5. 如果操作出错，如何恢复。

理论视角

将这些视角用作诊断工具，而非僵化规则。如果不同视角相互冲突，应优先考虑任务成功、错误预防和可恢复性。

视角	核心问题	设计启示
以任务为中心／以人为中心的设计（ISO 9241-210）	UI 是否符合用户的实际工作和使用情境？	围绕任务组织，而非围绕实现模型
Norman：执行鸿沟与评估鸿沟	用户能否无需转换就形成意图并判断结果？	通过易于发现的控件和清晰可见的反馈，弥合这两种鸿沟
Norman：可供性、示能标识、映射、约束、反馈、概念模型	用户能否判断哪些操作可行、自己选择了什么、发生了哪些变化？	让操作、选择、系统状态和结果清晰可见
Nielsen 10 项启发式原则	UI 是否能显示状态、使用熟悉的语言、防止错误并支持恢复？	优先考虑可见性、一致性、防错、识别和用户控制
Shneiderman 8 项黄金法则	是否支持一致性、快捷操作、反馈、闭环和可逆性？	提供一致的流程、撤销、对话闭环和信息丰富的反馈
认知负荷理论／工作记忆（Miller、Cowan）	用户一次必须在脑中记住多少内容？	减少同时进行的决策，采用渐进式呈现，将状态外化
Hick-Hyman 定律	某个决策点是否有太多权重相同的选项？	限制同一层级的选项；分阶段做出决策；使用合理的默认值
Fitts 定律	主要操作是否易于触达和点击？	让常用目标足够大；放置在工作区域附近
Steering 定律	用户是否必须沿着狭窄路径（菜单、通道）操作？	避免狭长的悬停路径；拓宽常用交互通道
Gestalt 原则（接近性、相似性、连续性、闭合性、共同区域、共同命运、图形与背景）	分组和层级是否一目了然？	通过间距、对齐、对比和围合来呈现结构
视觉层级与扫描模式	视线是否会首先落在最重要的内容上？	利用字重、字号、对比度和位置来体现重要性
信息气味（Pirolli）	标签和链接是否能预示用户将找到什么？	让标签具体描述目标内容或结果
Reason：失误与错误／Poka-yoke	常见错误会是操作失误（动作）还是判断错误（意图）？	限制输入，确认破坏性操作意图，让错误恢复成本低
无障碍（WCAG / POUR）	更多用户能否感知、操作、理解并信赖 UI？	提供标签、焦点、对比度、键盘支持、非颜色提示，并尊重减少动态效果的偏好
平台惯例（Material、HIG、Fluent）	UI 的行为是否符合该平台用户已有的预期？	遵循平台惯例；仅在理由充分时偏离

默认工作流

1. 找出用户的真实目标

用直白的任务语言描述目标。

• 好：Capture, annotate, and save the correct tutorial shot
• 不好：Manage shot manifests、Edit rendering metadata

UI 必须围绕用户要完成的工作来组织，而不是围绕 内部数据模型。

2. 定义主要路径和状态模型

更改布局前，先说明：

1. 用户的主要操作路径。
2. 所需的最低限度设置。
3. 重要的系统状态和状态转换。
4. 用户应该评估的结果。

示例：

1. 选择目标项。
2. 做出更改。
3. 查看结果。
4. 保存或重试。

如果屏幕混合了多项工作，就将它们分开，或将次要工作置于从属位置。

3. 降低首次使用时的认知负担

减少用户开始时需要思考的内容：

• 首先只显示下一个有意义的决策（渐进式披露）。
• 让次要控件在视觉上更低调。
• 等用户了解上下文后再显示高级详情。
• 优先提供一个明确的下一步操作，而不是多个同等重要的选项 （Hick-Hyman 定律）。
• 通过可见标签、预览和当前选择指示器提供所需上下文，而不是 要求用户在不同屏幕间记忆信息。
• 优先采用能自我说明的 UI，而不是始终显示说明性文字。
• 只有当无法从 UI 本身推断出下一步操作时，才添加说明性文字。

4. 去除内部用语和记忆负担

将无关的实现语言和仅在网站内部使用的行话替换为普通的任务用语。

• 好：Choose the shot to edit
• 不好：Select output artifact、Bind manifest target

如果某个精确的操作术语或领域术语确实属于用户实际工作的内容，就保留它。只去掉反映实现模型而非用户任务的措辞。如果仍需解释某个领域术语，就在文中就地说明，且不要打断流程。

5. 让状态和下一步操作一目了然

在每个阶段，用户都必须能够回答：

• 我在哪里。
• 我当前正在操作什么。
• 我现在应该做什么。
• 执行后会发生什么。
• 执行后有什么变化。

在交互流程中（拖放、选择、移动、比较、批注、多选），始终要以明显的视觉方式区分当前选择、来源、目标和结果，不能只依赖颜色。结合颜色与形状、粗细、图标、文字或位置，确保存在色觉差异或低对比度显示时，状态仍然清晰。

6. 降低交互成本

主要操作必须易于发现、触达和点击（Fitts 定律）：

• 常用目标的尺寸要适合输入设备。
• 将紧密关联的控件放在一起。
• 将主要确认操作放在其所提交的内容附近。
• 避免狭窄且层级很深的悬停路径（转向定律）。
• 减少同时显示的同等突出选项数量。

如果用户必须停下来比较许多选项才能开始，就简化选项，或分阶段呈现。

7. 防止错误并支持恢复

设计时要防范失误，而不只是满足顺利完成的理想路径：

• 区分失手（意图正确，操作错误）和误判（意图错误）。通过限制输入来减少失手；通过确认或预览来减少误判。
• 让破坏性或不可逆操作在视觉上明显区别，并要求明确确认。
• 尽可能在输入边界处防止无效状态（防错设计）。
• 在导致问题的控件旁显示验证信息，而不只是放在汇总区域。
• 在操作过程中，而不只是操作完成后，让用户容易找到并使用撤销、重试、重置和取消功能。
• 如果重新创建草稿的代价很高，就妥善保留草稿内容。

8. 优先显示最有助于决策的结果

输入就绪后，优先呈现主要结果或下一检查点：

• 确定用户应该据以做出判断的唯一结果。
• 将其放在辅助诊断信息上方。
• 将说明、假设和元数据放在后面，或折叠起来。

9. 有意识地运用视觉结构

运用格式塔原则和视觉层级，在用户阅读任何文本之前传达结构：

• 利用邻近性和共同区域将相关控件归为一组。
• 保持对齐和间距一致，减少视觉干扰。
• 通过尺寸、字重和对比度区分重要程度。
• 利用边框和图形与背景的区分，将活动区域与背景界面元素分开。

让屏幕上最重要的元素在视觉上最突出。

10. 从一开始就将无障碍纳入设计

无障碍是基线要求，而不是最后的收尾工作：

• 每个交互控件都需要无障碍名称和可见的焦点指示器。
• 主要流程必须能仅用键盘按逻辑顺序完成。
• 为颜色提示配上非颜色提示。
• 至少达到 WCAG 2.1 AA 对比度要求。
• 使用动画或半透明效果传达状态时，尊重平台对减少动态效果和减少透明度的偏好设置。

11. 像首次使用的用户一样检查屏幕

检查用户是否能按页面顺序操作并成功完成任务。

最低限度的检查问题：

1. 我能否从顶部开始阅读，或沿着视觉路径操作？
2. 我能否在几秒内知道这个屏幕的用途？
3. 我知道此刻正在对什么对象进行操作吗？
4. 我知道下一步该做什么吗？
5. 操作后，我能看到发生了什么变化吗？
6. 如果我犯了错，能恢复吗？
7. 我是否看到了用户可能无法理解的内部术语？
8. 在常见视口尺寸下，主要 UI 是否避免了水平滚动？
9. 在缩窄的宽度下，是否存在溢出、裁切或意外换行问题？
10. 能否通过键盘并借助可见的焦点提示完成主要流程？
11. 在灰度视图中，所有状态提示是否依然清晰（信息不能只依赖颜色）？

对于任何重大 GUI 变更，都应截图并进行视觉检查，然后再将工作视为完成。抽查常见宽度和缩窄后的宽度。

常见改进

• 将设置移到结果上方。
• 使用任务相关的措辞重命名各个部分。
• 将空状态改为明确的下一步操作，并提供示例。
• 将校验信息放在有问题的控件旁边。
• 在需要之前折叠元数据和高级详情。
• 添加持久的选中状态或来源／目标高亮，且不能只依赖颜色。
• 将保存、应用或确认操作放在其提交的内容旁边。
• 在用户容易卡住的地方添加撤销、重置或重试功能。
• 增大触控设备上主要操作的目标尺寸。
• 为仅含图标的控件添加无障碍名称或可见标签。

轻量评估方法

选择成本最低、又能揭示实际失效模式的方法。

• 启发式评估——根据 Nielsen 的 10 项启发式原则或 Shneiderman 的 8 项规则为屏幕打分；成本低，能发现明显问题，但容易受已知模式影响。
• 认知走查——针对主要任务的每个步骤，询问：用户会知道该怎么做吗？会看出如何操作吗？会理解反馈吗？
• 首次点击／首次使用测试——让用户首次看到屏幕，并观察他们先看哪里、先点哪里。
• 出声思考法——让用户在操作屏幕时说出自己的推理过程；这能揭示概念模型与 UI 之间的不匹配。

优先提供具体的失败案例和截图，而不是抽象地宣称 UI“直观”。

交付预期

使用面向用户的措辞描述变更：

• 哪项任务现在更容易完成。
• 用户现在首先会看到什么。
• 用户接下来要做什么。
• 消除了哪些困惑或错误风险。
• 有哪些证据支持该结论（截图、走查结果，或基于具名启发式原则的评估）。

除非有人要求，否则 Agent 不得围绕内部组件名称来撰写报告。