ux-usability-foundations

UX 可用性基础

目的

帮助 Agent 打造易于理解、易于使用、宽容且符合用户预期的界面。将可用性视为产品行为，而非表面装饰。Agent 应将含糊或脆弱的 UI 转变为这样的界面：用户能快速弄清楚这是什么、在这里能做什么、自己身处何处、发生了什么、如何恢复，以及付出这些努力是否值得。

何时使用此技能

当用户要求你从可用性角度评估、重新设计、创建或指定 UI、流程、表单、应用屏幕、网站、仪表板、引导流程、设置页面、结账流程、导航模型、状态行为或组件交互时，使用此技能。也可用于处理可供性／提示、反馈、约束、错误、空状态／加载状态／成功状态、以识别代替回忆、任务清晰度和前端行为。

何时不使用此技能

除非相关选择会直接影响用户的理解、控制或恢复能力，否则不要将此技能作为深入研究操作、品牌风格体系、视觉润色、字体设计、前端架构或说服／增长策略的主要技能。

核心原则

1. 从目标出发，而非从屏幕出发。 在调整控件或布局前，先明确用户的目标、任务、情境和可能具备的知识。设计需求应先描述用户需求，再考虑界面组件。
2. 让下一步操作一目了然。 优先采用不言自明的界面。如果任务本身较新颖或复杂，就用结构、标签、示例和反馈让界面不言自明。
3. 展示可执行的操作。 交互元素必须看起来可交互。只读元素不能看起来像可编辑。隐藏手势必须提供可见的替代方式。
4. 符合用户的心智模型。 使用用户理解的概念、名称和顺序；除非用户需要，否则不要暴露数据库表、文件路径、内部 ID 或任意系统状态。
5. 以识别代替回忆。 将所需选项、上下文、示例和状态保持可见，或确保用户可以轻松找到。
6. 减少工作量并删去冗余。 移除那些服务于系统而非用户目标的任务：重新输入、转移数据、寻找控件、配置显而易见的默认值，或回答可推断的问题。
7. 引导选择，但不要让用户应接不暇。 使用渐进式披露、合理默认值、分组和优先级。
8. 立即提供有用的反馈。 每项重要操作都需要得到回应，说明系统是否已收到操作、发生了什么变化、是否需要等待，以及接下来可以做什么。
9. 先预防错误，再解释错误。 尽可能使用约束、安全默认值、预览、宽容的输入方式、行内验证和撤销功能。
10. 问题归咎于设计，而非用户。 错误表明用户预期与实际情况不符，或出现了未支持的边缘情况。保留用户已完成的工作，并引导其恢复。
11. 遵循平台规范和惯例。 在合适时使用用户熟悉的模式。只有当新行为明显有助于用户达成目标，并且用户能够发现和恢复时，才打破惯例。
12. 无障碍是在压力下仍可用。 针对不同能力、设备、读写水平、压力和环境，设计易于感知、操作简单、清晰易懂且宽容的界面。

请参阅 references/principle-cards.md，了解每项原则对应的可复用卡片。

默认建议

产品目标

默认优先优化用户的主要任务，再考虑次要业务诉求。只有法律、安全、欺诈、隐私或业务关键要求才可优先于此。请思考：“哪项义务必须打断或限制主要任务？隐藏或延迟处理它会带来什么后果？”

受众

默认面向积极主动但容易分心、领域知识一般且记忆不完美的用户。若产品主要由受过培训的专业人员在稳定条件下频繁使用，则调整这一假设。请思考：“主要面向首次／偶尔使用的用户、频繁使用产品的中级用户，还是受过培训的专业人员？”

平台和输入方式

默认遵循平台惯例，并在相关情况下支持指针、触控、键盘和辅助技术。平台或输入方式的限制不明确时，请先询问。

信息密度

默认提供足够的上下文，便于识别和决策，同时将少用的高级控件隐藏在清晰的入口后。比较、监控或专家工作流除外。请询问：“用户需要用于监控或比较的概览密度，还是用于完成任务的逐步聚焦？”

导航

默认清楚显示当前位置、当前对象和状态，方便用户访问主要区域，并提供明显的返回或继续路径。仅在刻意设计的引导流程中例外。请询问：“用户应该能够自由浏览，还是此流程应该有意限制导航？”

标签和语言

默认使用通俗、以任务为导向的标签，并采用用户熟悉的词汇。使用内部术语、巧妙表达、法律术语或领域专用术语前，请先询问。

表单

默认使用常驻标签、恰当的输入类型、提前说明的限制条件、适时的行内验证、保留已填写的数据，以及明确的主要操作。只有在专家可能更重视信息密度或速度而非新手易懂性时才询问。

错误处理

默认优先预防错误；若发生错误，应说明发生了什么、为何重要，以及如何修复，同时避免丢失工作成果。错误详情涉及敏感信息、受监管信息或安全问题时，请先询问。

破坏性操作

默认将破坏性操作的视觉优先级设得较低，直到最终审核或确认步骤。可撤销的操作优先提供撤销功能；不可逆、代价高昂、涉及法律或安全的操作则需确认。请询问操作是否可逆，以及可能造成的损害。

反馈和状态

默认即时提供接收反馈，延迟时显示进度，完成时明确提示；对于长期运行或影响重大的操作，应持久显示状态。请询问哪些状态变化需要打断用户。

无障碍访问

默认遵循以 WCAG 为导向的基础要求：使用语义化控件、支持键盘操作、清晰显示焦点、提供程序化标签、保证足够的对比度、不仅依靠颜色传达含义、使用易读的文案，并确保状态更新适合屏幕阅读器。不得违反这些基础要求。

必须向用户询问的问题

不要询问常规的最佳实践问题。仅在答案会改变建议时，提出一个有针对性的问题：

• 不清楚主要用户或任务。
• 操作会带来安全、财务、法律、隐私、医疗或不可逆的后果。
• 新手和专家需要不同的行为方式。
• 平台或输入方式的限制不明确。
• 可能需要使用指定术语或合规文案。
• 用户要求采用非标准、隐藏式或操纵性的模式。
• 信息密度与清晰度之间，或引导流程与自由导航之间确实存在取舍。

请使用以下格式：

question({
  question: "What is the primary task this interface must help users complete?",
  recommended_default: "Optimize for the most common successful task first, then make secondary actions available but visually quieter.",
  options: [
    "Complete one focused task",
    "Compare or monitor multiple items",
    "Explore and choose among options",
    "Other / custom"
  ]
})

需要完整的决策问题集时，请使用 references/decision-prompts.md 中可供提问工具直接使用的问题提示词。

评审现有 UI 的工作流

按以下顺序检查：

1. 用户目标与任务匹配度。
2. 第一眼能否理解。
3. 定位：当前位置、对象、状态，以及前进或返回的路径。
4. 操作是否易于发现。
5. 选项的质量和优先级。
6. 标签和语言。
7. 反馈和状态。
8. 错误预防和恢复。
9. 对识别的支持与记忆负担。
10. 无障碍访问和输入方式覆盖。
11. 前端可行性和边界状态。
12. 根据任务影响、频率、严重程度和修复工作量确定优先级。

评审报告应包括：影响最大的可用性问题、快速改进项、行为和规格细节、无障碍注意事项，以及风险和取舍。

创建或改进界面的工作流

1. 明确用户、目标、成功条件和风险。
2. 选择最简单且实用的流程。
3. 梳理用户的概念和用语。
4. 构建清晰的界面结构和操作层级。
5. 除非任务原因足以支持自定义行为，否则采用标准模式。
6. 设计默认、悬停、聚焦、激活、加载、成功、空状态、验证、错误、离线、禁用和权限状态。
7. 添加限制、验证和恢复机制。
8. 兼顾首次使用和重复使用。
9. 验证无障碍性。
10. 从任务进展、认知负荷、预期和风险的角度解释设计决策。

决策框架

问问自己：

1. 问题出在理解、选择、控制、反馈、导航还是恢复？
2. 设计能否预防问题，而不是事后解释？
3. 界面能否让用户通过识别而非回忆来操作？
4. 标准模式能否解决问题，而无需用户学习新用法？
5. 哪些元素是主要、次要、次级或危险操作？
6. 用户需要更多信息、更少选项，还是更合理的操作顺序？
7. 用户能否注意到状态变化？
8. 如果用户分心、赶时间、使用触控或键盘、使用辅助技术，或正在从错误中恢复，会发生什么？
9. 哪些操作可撤销、代价高昂或不可逆？
10. 这是在服务用户的任务，还是系统的便利？

实用规则

清晰易懂，便于浏览

• 通过标题、结构和主要操作，清楚呈现每个屏幕的用途。
• 使用描述性按钮文案，例如“发送发票”“保存更改”或“预约”，而不是“提交”。
• 让点击或轻触目标看起来像控件，不要依赖悬停状态。
• 使用标题、分组、留白和列表，方便用户浏览。
• 删除会分散用户对任务注意力的文案和装饰元素。

可供性、指示符和控件

• 当行为符合预期时，使用原生控件。
• 对不熟悉或影响重大的操作，使用带标签的图标。
• 明确区分链接、按钮、已选项、禁用项、可编辑字段和静态文本。
• 除非提供可见的替代方式，否则不要将必要操作隐藏在手势、长按、悬停或小型溢出菜单中。

选项与渐进式披露

• 初始选项仅限于当前决策所需的范围。
• 设置安全且可能符合用户意图的默认值。
• 在用户需要时再显示高级选项。
• 当用户需要从相似的方案、产品、记录或设置中进行选择时，使用对比结构。

反馈与状态

• 收到命令后立即提供简短反馈。
• 对延迟和异步操作显示进度。
• 当结果不可见时，确认操作已完成。
• 清楚显示当前选择、当前页面、当前筛选条件、未保存的更改以及离线／同步状态。
• 避免对常规且无需操作的情况提供嘈杂的反馈。

错误与恢复

• 在可行的情况下，提交前验证限制条件。
• 保留无效的用户输入，使其清晰可见且可编辑。
• 在受影响的控件旁显示错误；对于较长的错误信息，提供摘要。
• 对可撤销的操作提供撤销功能；对不可逆或高风险的操作要求确认。
• 出现可恢复的问题后，绝不要让用户从头开始。

导航与定位

• 显示当前所在的版块、对象和状态，以及可用的前进／返回路径。
• 在层级较深时使用面包屑导航，但不要用它替代清晰的导航。
• 仅将标签页用于同一上下文中同级的版块。
• 对不常用或受空间限制的操作，使用抽屉／菜单；避免隐藏常用的主要导航。
• 用户从详情页返回列表时，保留路由、筛选条件和滚动位置。

易于学习

• 首次使用时提供临时且聚焦于任务的帮助。
• 优先使用内嵌示例和空状态指引，而非独立的帮助文档。
• 随着用户反复成功使用，逐步减少新手指引。
• 为“长期中级用户”设计：他们了解基础知识，但并非什么都记得。

无障碍与包容性要求

• 优先使用语义化 HTML 和原生元素，而非自定义控件。
• 确保所有交互元素都有无障碍名称。
• 让焦点顺序与视觉顺序／任务顺序一致。
• 提供清晰可见的焦点指示器。
• 确保所有操作都支持键盘操作。
• 将标签、提示和错误信息与表单控件关联。
• 不要只依靠占位文本充当标签。
• 不要只依靠颜色传达信息。
• 以恰当的方式播报异步状态和错误。
• 确保对话框打开时会锁定焦点，关闭时会恢复焦点。
• 尊重减少动态效果的偏好设置。
• 确保目标尺寸适合触控操作，并考虑不同的动作能力。
• 在满足任务和领域要求的前提下，使用尽可能简单的表达。

前端实现指南

语义化结构

• 使用 <button> 执行操作，使用 <a> 进行导航。
• 为输入框提供持久且可通过程序识别的标签。
• 使用 fieldset/legend 将相关的单选框／复选框分组。
• 按逻辑顺序使用标题。
• 使用表格呈现表格数据，而非用于布局。

状态与反馈

• 在适用时，涵盖默认、悬停、可见焦点、激活、选中、展开／折叠、禁用、加载、成功、警告、错误、空、离线和只读状态。
• 根据需要使用 aria-expanded、aria-controls、aria-selected、aria-current、aria-invalid、aria-describedby 和实时区域。
• 仅在禁用控件的原因显而易见或已作说明时才禁用；否则应允许用户操作并为其提供指引。
• 通过待处理状态和幂等的服务端处理，避免重复提交。

表单

• 适当使用 type、autocomplete、inputmode、min、max、step 和约束。
• 如果用户可能输入等效格式，应让输入方式保持灵活。
• 对复杂字段，在失焦或提交时验证；只有在验证条件稳定且有帮助时，才在输入时验证。
• 尽可能在发生错误、刷新、身份验证中断和网络故障后保留已填写内容。

响应式与输入行为

• 不要假设用户可以悬停。
• 在小屏幕上，确保主要操作易于触达，且不会隐藏上下文。
• 确保文本可以放大或重排，且功能不会受损。
• 使用纯键盘、屏幕阅读器基础功能、触控、窄视口、慢速网络和高倍率缩放进行测试。

质量检查清单

• 明确说明用户的主要目标。
• 用户一眼就能看出屏幕的用途。
• 主要操作比次要操作更醒目。
• 标签使用用户熟悉的语言。
• 无需悬停即可发现交互元素。
• 尽量减少必选项，并将其分组。
• 在产生重要影响的操作后提供状态反馈。
• 尽可能避免错误；无法避免时，让错误易于恢复。
• 让破坏性操作可撤销，或明确要求确认。
• 确保用户不会因验证、身份验证、网络或导航问题而丢失工作成果。
• 导航应回答“我在哪里？”和“我可以去哪里？”。
• 纳入无障碍设计基础要求。
• 确保前端行为可以实现。

使用 references/checklists.md 中的完整检查清单。

应避免的常见错误

• 先搭建应用界面框架，再处理任务。
• 把“易于使用”当作一项检查清单。
• 将主要操作藏在菜单、手势或图标后面。
• 明明可以使用清晰直白的标签，却偏要使用巧妙含蓄的标签。
• 把所有操作都设计得同等重要。
• 询问系统可以安全推断的信息。
• 让用户记住隐藏的说明或状态。
• 用不断弹出的确认框取代撤销功能。
• 在错误文案中责怪用户。
• 使用未说明原因的禁用控件。
• 只依靠颜色传达信息。
• 设计不支持键盘和辅助技术的自定义控件。
• 把无障碍视为最后的审核环节。
• 混淆视觉简洁与任务复杂度降低。

完整的反模式列表请参阅 references/anti-patterns.md。

• 忽略空、加载、离线、验证、权限和边界状态。

如何向用户解释推荐理由

使用此模式：

I recommend [change] because users are likely trying to [goal]. The current version makes them [think/remember/guess/recover] unnecessarily. This change makes [action/state/recovery] visible and reduces [specific risk or effort]. The main tradeoff is [cost], which is acceptable unless [context that would change the decision].

不同意用户要求的模式时：

I would not hide this behind an icon-only menu because it is the primary path for the task. A better default is a visible labeled action. Use the menu only for secondary or infrequent actions.