interaction-patterns-components

交互模式组件

目的

帮助 Agent 选择、评估和设计有效的 UI 交互模式与可复用的产品组件。

此技能涵盖导航模式、菜单、卡片、表格、仪表板、模态框、流程、状态和组件行为。它只在影响交互清晰度、层级、无障碍性或组件可用性时关注视觉润色。

何时使用此技能

当用户提出以下任一需求时，使用此技能：

• 评估、重新设计或进行 UX 审查，涉及应用屏幕、网站、产品流程、线框图、组件或前端实现。
• 选择 UI 模式，例如导航、菜单、面包屑、仪表板、卡片、表格、表单、模态框、向导、分栏窗格、标签页、折叠面板、工具栏、悬停工具、列表、网格或反馈状态。
• 设计可复用组件或设计系统行为。
• 提供有关交互行为、无障碍性、响应式行为、组件 API 或 UI 状态处理的前端指导。
• 制定产品 UX 建议，且最佳方案取决于任务、用户技能、设备环境、数据复杂度或风险。

何时不使用此技能

如果用户主要需要以下内容，请勿将此技能作为主要框架：

• 与交互清晰度无关的品牌形象、插画、情绪板或视觉润色。
• 标签、帮助文本、错误信息和微文案以外的深度文案撰写、信息传达策略或内容设计。
• 纯平面设计、Logo 设计或营销创意。
• 原生语音、AR/VR、空间交互或非屏幕交互设计，除非任务还涉及基于屏幕的控件或配套 UI。
• 后端架构、数据库设计或 API 设计，除非实现约束会影响组件行为。

核心原则

1. 从用户、目标和情境出发

在选择组件之前，先明确用户想要完成什么。表单、菜单、表格、模态框或仪表板都只是实现用户目标的手段。不断追问“为什么”，直到足以明确任务、风险和成功标准，从而设计出最简单且实用的界面。

默认：根据功能推断用户目标并继续。只有在缺失的情境会改变模式选择时才提问，例如用户是专家还是新手、使用移动设备还是桌面设备，或操作风险高还是低。

2. 将交互视为对话

每个 UI 都应像体贴的伙伴一样回应：倾听、确认输入、显示进度、防止困惑，并明确指出下一步。通过可见状态、反馈、标签、焦点行为和恢复路径，将这些特性融入组件。

默认：每个交互组件至少应定义默认、悬停／按下（如适用）、焦点、加载、禁用、成功、空和错误状态。

3. 选择能保留上下文的最简单模式

优先采用能让用户保持方向感并减少不必要导航的模式。让工具靠近其作用对象，但不要将关键操作隐藏在仅悬停时才出现的功能中，也不要使用含义模糊的图标。

默认：当原位编辑、上下文工具、行内验证和同页预览能够减少上下文切换且易于发现时，优先使用它们。

4. 保持方向感

用户需要知道自己身处何处、可以去往何处、发生了什么变化，以及如何恢复。导航不只是界面装饰；它还包括路标、层级、面包屑、进度指示器、深层链接、退出方式和稳定的屏幕区域。

默认：提供稳定的主导航模式、清晰的页面标题、可见的当前位置，以及可返回上一层或父级上下文的路径。

5. 让信息结构决定布局

布局应体现任务结构，而不是装饰。使用分组、邻近关系、对齐、视觉层级、渐进式展示和屏幕区域来呈现关联和优先级。

默认：每个任务区域设置一个清晰的主要操作；将相关控件分组；让最重要的内容或对象成为关注中心。

6. 让模式匹配数据和任务

只有当表格、卡片网格、列表、仪表板、信息流、向导或详情页符合用户比较、浏览、选择、创建、监控或编辑的内容时，才算合适。

默认做法：对于结构化、可比较、可排序的数据，使用表格或紧凑列表；对于类型各异且视觉上易于辨认的项目，使用卡片或缩略图；对于陌生的分步任务，使用向导；对于专家反复执行的工作，使用更紧凑的工作区，并提供快捷方式和清晰可见的工具。

7. 让操作安全

通过预览、撤销、取消、清晰的标签、仅对重大操作进行确认，以及可靠的恢复机制，支持用户安全地探索。避免对常规且可撤销的操作设置阻塞式确认。

默认做法：操作可撤销时，优先提供撤销，而不是确认。仅在操作具有破坏性、成本高、不可逆、涉及隐私或财务，或影响范围广时，才使用确认或缓冲步骤。

8. 为中断、重新进入和重复操作而设计

用户会改变方向、暂停、恢复、重复操作，也会依赖记忆。保持状态稳定，避免意外调整控件的位置，在适当时记住安全的进度，并优先显示近期或重复的操作。

默认做法：尽可能保留未保存的工作；从详情页返回后，保留筛选条件和滚动位置；用户开始任务后，不要移动控件。

9. 让表单简短、明确且易于填写

只询问当前所需的信息。使用标签、提示、合适的输入类型、智能默认值、验证、示例和错误恢复机制。不要只依靠占位文本提供标签或说明。

默认做法：使用可见标签；大多数表单采用单列布局；将行内错误与对应字段关联；尽可能接受灵活的输入格式；只有在置信度高且用户可以编辑时，才智能预填内容。

10. 将模式构建为可复用的系统

除非上下文有特殊要求，否则不要创建一次性组件。明确组件的职责、变体、状态、无障碍行为、响应式行为、内容规则和应急方案。

默认做法：从现有设计系统或常见 UI 框架出发，再有意识地扩展。将库视为基础，而非上限。

参阅 references/principle-cards.md，了解每项原则如何作为可复用卡片。

默认建议

除非用户的具体情境足以支持例外，否则请采用以下默认做法。

领域	默认建议	通常最合适的原因	适用例外的情况
产品目标	优先帮助用户完成任务，而非展示功能。	用户使用 UI 是为了达成目标。	屏幕主要用于探索、教育或宣传。
受众	面向能力强但时间紧张、专业水平各异的用户进行设计。	大多数产品需要同时服务初学者和回访用户。	产品明确只面向专家、类似信息亭，或仅供一次性使用。
平台	从响应式、兼顾移动端的设计着手，再针对大屏幕进行优化。	小屏幕会促使设计者确定优先级并采用可复用的内容单元。	工具是仅供桌面端使用的高密度专业工作区。
导航	使用稳定的全局导航，并配合局部导航提示。	可预测性能够降低认知负担。	产品是单任务流程或沉浸式画布。
信息密度	采用适中的信息密度，并渐进式展示信息。	这样便于浏览，又不会造成信息过载。	专家工作流需要高密度数据和高效键盘操作。
屏幕结构	选择一种主导的屏幕类型：概览、专注、创作或执行。	清晰的组织原则让屏幕更易理解。	仪表板／工作台确实需要多个区域。
列表	用列表／表格进行比较；用卡片呈现内容丰富或视觉性强的条目。	设计模式应与用户的浏览任务相匹配。	条目的内容或选择行为与众不同。
主要操作	每个任务区域设置一个视觉上突出的主要操作。	这样可以避免注意力分散，并明确下一步。	多个操作确实同等重要且使用频繁。
模态框	复杂工作流应避免使用模态框；专注、打断式且范围明确的任务则可使用。	模态框会打断上下文，并使导航／焦点管理更复杂。	轻量级浮层比页面导航更能保留上下文。
向导	仅用于用户不熟悉、按顺序执行的多步骤任务。	它们能减轻顺序设置过程中的认知负担。	专家用户需要非线性编辑或比较。
仪表板	展示可指导行动的监控信息，而非装饰性指标。	仪表板应支持决策和分诊。	仪表板明确用于提供环境状态感知。
表单	尽量减少字段，为所有字段添加标签，将内容分组，并在行内验证。	这样可以减少操作成本并防止错误。	法律、合规或运营要求必须增加字段。
默认值	仅在默认值很可能正确且易于更改时预填。	合理的默认值可以减少操作成本，同时不剥夺控制权。	错误的默认值会带来高昂代价或造成误导。
错误处理	优先预防错误，然后说明问题并帮助用户恢复。	错误恢复也是交互的一部分。	实时预防会打断专家的工作流程。
动效	使用过渡效果帮助用户保持方向感，而非用于装饰。	动效可以展现因果关系、连续性和变化。	用户偏好减少动态效果，或动效会增加延迟。
无障碍	将键盘、焦点、标签、对比度和屏幕阅读器语义视为基本要求。	无障碍是交互质量的一部分。	绝不可忽略；只能调整实现方式。
设计系统	复用现有组件，并记录其变体／状态。	这样可以减少不一致和 UX 债务。	现有组件不具备无障碍性或不适合任务。

必要的用户问题

仅当答案会改变模式选择或风险模型时，才提出聚焦的问题。不要询问常规的最佳实践问题。

以下情况未知且与决策实质相关时，请提出问题：

1. 主要任务和成功结果：存在多个相互竞争的目标时。
2. 受众的技能水平和使用频率：需要在引导式流程和专家工作区之间做选择时。
3. 平台／设备背景：移动设备、触控、桌面端信息密度、键盘使用或响应式行为会影响设计时。
4. 数据形态和规模：需要在列表、表格、卡片网格、仪表盘、信息流、筛选、分页或可视化之间做选择时。
5. 操作风险／可逆性：需要决定是否提供撤销、确认、预览或缓冲步骤时。
6. 导航深度和信息架构：需要在扁平、中心辐射、树形、金字塔、向导或工作区模型之间做选择时。
7. 设计系统／前端约束：用户需要可直接用于实现的指导时。
8. 无障碍或合规要求：特定领域的要求可能超出基础无障碍标准时。

使用以下格式：

question({
  question: "What is the primary task users must complete on this screen?",
  recommended_default: "Optimize for the most frequent task and make secondary actions available but less prominent.",
  options: [
    "Find or browse items",
    "Compare and select items",
    "Create or edit something",
    "Monitor status or metrics",
    "Complete a step-by-step process",
    "Other / custom"
  ]
})

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

工作流

A. 评审现有 UI

按以下顺序检查：

1. 用户目标和任务匹配度
   明确屏幕旨在帮助用户完成什么。指出那些优先服务于产品而非用户的控件、文案或屏幕。

2. 信息架构和屏幕类型
   判断屏幕属于概览、聚焦、创建、执行、仪表盘、流程还是工作区。检查模式是否与任务匹配。

3. 寻路和导航
   检查位置提示、入口、退出路径、面包屑、进度指示器、深层链接，以及用户能否从死胡同中恢复。

4. 层级、分组和布局
   检查主要对象／操作是否一目了然；相关元素是否分组；视觉权重是否符合优先级；渐进式披露是否使用得当。

5. 交互清晰度和组件行为
   检查可操作性提示、标签、操作位置、反馈、状态变化、悬停／触控行为、键盘行为、加载、空白和错误状态。

6. 安全性和恢复能力
   检查撤销、取消、预览、确认、错误预防，以及流程被中断时的恢复能力。

7. 表单和输入行为
   检查标签、必填／选填指示、输入类型、提示、默认值、验证和错误措辞。

8. 数据展示和浏览
   检查表格、卡片、仪表盘、筛选、排序、数据提示和可视化是否有助于比较和决策。

9. 无障碍和包容性
   检查键盘使用、焦点顺序、语义、标签、对比度、减少动态效果、目标尺寸、非颜色提示和屏幕阅读器行为。

10. 前端可行性和设计系统适配度
    检查组件复用、响应式布局、设计令牌化、状态复杂度、性能和可维护性。

按以下格式返回评审意见：

## Overall diagnosis
[1-3 sentence summary]

## Highest-impact fixes
1. [Fix] — [why it matters] — [pattern/component recommendation]
2. ...

## Component-level notes
- [Component]: [issue] → [recommended behavior]

## Accessibility and implementation notes
- [Specific requirement or constraint]

## Tradeoffs
- [When another pattern might be better]

B. 创建或改进设计

按以下顺序进行：

1. 明确用户问题和成功结果。
2. 仅在必要时确认受众技能、平台、数据规模和操作风险。
3. 选择屏幕类型：概览、聚焦、创建、执行、仪表盘、流程或工作区。
4. 选择导航模型和寻路提示。
5. 建立布局层级和分组。
6. 选择组件并明确其职责。
7. 定义行为：交互、反馈、状态、验证、转换、键盘／焦点和恢复。
8. 定义响应式行为和设计系统变体。
9. 执行质量检查清单。
10. 将建议说明为对用户任务的益处，而非风格偏好。

按以下格式返回新建议：

## Recommended pattern
[Pattern and why it fits]

## Structure
[Regions, navigation, hierarchy]

## Component behavior
[States, actions, feedback, validation]

## Accessibility and frontend notes
[Semantics, keyboard, responsive, state management]

## Alternatives considered
[Why not the likely alternatives]

决策框架

将以下模式选项作为起点：

屏幕与流程模式

• 概览屏幕：用于列表、网格、搜索结果、信息流、仪表板或集合，供用户选择接下来要查看的内容。
• 聚焦屏幕：用于某个对象、媒体项、记录、画布或地图成为关注中心的场景。
• 创作工作区：用于用户创建或操作内容的场景；谨慎使用工具栏、调色板、检查器和直接操作。
• 任务屏幕：用于支付、预订、导入、导出、设置或确认等单一且范围明确的任务。
• 向导：用于用户不熟悉且有依赖关系的有序步骤。避免用于专家反复执行的任务。
• 仪表板：用于监控、分流和决策。避免将其做成装饰性的指标拼盘。
• 模态框／叠加层：用于必须中断当前操作或保留底层页面上下文的范围明确的任务。避免用于深层流程、大型表单，或用户需要与背后页面内容对照的场景。
• 多个工作区／分屏视图：用于需要比较和编辑多个对象的专家级或高上下文任务。
• 设置编辑器：用于持久化偏好设置和配置；按用户的心智模型分组，而非按实现模型分组。

导航模式

• 扁平导航：用于少量并列的目的地。
• 中心辐射式导航：用于用户在各项任务之间需要返回中心位置的场景。
• 树形／多级导航：用于大型分层信息空间。
• 金字塔式导航：用于从顶层探索进入更具体的页面，同时保留跨分支导航路径的场景。
• 分步导航：用于有序流程。
• 宽菜单／菜单页：用于用户需要总览并直接访问多个目的地的场景。
• 面包屑：用于深层层级导航，但不要将其作为唯一的主要导航方式。
• 进度指示器：用于用户需要了解多步流程进度的场景。
• 安全退出路径：始终为模态框、向导或深层导航场景提供安全的退出方式。

列表与内容模式

• 表格：用于结构化数据，供用户按属性比较行、排序、筛选、扫描精确值或执行批量操作。
• 密集列表：用于文本密集的条目或类似收件箱的分流场景。
• 卡片：用于包含图片／标题／摘要／操作的条目，其中每个条目都是一个独立对象。
• 缩略图网格：用于视觉上易于辨认且需要通过图片浏览的条目。
• 轮播：谨慎用于数量少、可选且视觉丰富的内容；不要将必选项隐藏在轮播中。
• 分页：适用于位置、有限集合、SEO 或性能很重要的场景。
• 无限列表：用于信息流／探索场景，此时精确位置不那么重要；保留加载状态和返回位置。
• 双面板选择器／分屏视图：用于用户浏览列表并查看详情，同时不丢失列表上下文的场景。
• 列表内嵌详情：用于无需完整导航即可展示简短且相关详情的场景。

操作与命令

• 将常用操作放在其影响对象附近。
• 让破坏性和高风险操作在视觉和空间上都与常规操作明显区分。
• 小型相关操作集可使用按钮组；避免混合优先级不同且无关的操作。
• 使用能明确指出受影响对象或操作的菜单标签。
• 对结果不确定的更改提供预览。
• 为长时间运行的操作提供取消功能。
• 为可撤销的操作和探索过程提供撤销／历史记录。
• 仅在专家反复执行的任务中使用宏或已保存的操作。

表单和控件

• 优先选择与数据类型匹配的输入方式：有限选项使用下拉选择或单选按钮，多选使用复选框，近似范围使用滑块，小幅数值增减使用步进器，开放文本使用文本字段，大型已知选项集使用自动补全。
• 对于已知的结构化字符串，如果系统能够安全解析，应采用宽容的格式。
• 当精度、防错或合规性比灵活性更重要时，使用结构化格式。
• 在相关字段旁提供提示。
• 占位符仅作补充；必须保留可见标签。
• 使用动态验证，但不要在用户输入过程中惩罚用户。
• 使用可能正确、可见且可编辑的智能默认值和预填内容。

反馈和微交互

• 立即显示直接操作的结果。
• 对需要明显时间的操作显示进度。
• 仅在通知及时、相关且可操作时使用通知。
• 当可视化定量状态有助于比较、预测或采取行动时，使用可视化方式呈现。
• 让通知操作保持精简直接。
• 使用过渡效果体现连续性，而不是拖慢任务。
• 遵循减少动态效果的设置。

实用规则

1. 推荐组件时，必须说明它服务于什么用户任务。
2. 优先省去一个步骤，而不是让这个步骤更好看。
3. 不要将主要操作隐藏在菜单、仅悬停时显示的控件或含义模糊的图标中。
4. 当用户需要比较、参考或浏览其后方内容时，不要使用模态框。
5. 当用户需要非线性编辑或专家级操作速度时，不要使用向导。
6. 对于用户需要按多个属性排序、比较或批量编辑的数据，不要使用卡片。
7. 当图像识别是主要行为时，不要使用表格进行视觉内容丰富的浏览。
8. 传达状态或选择时，不要只依赖颜色。
9. 用户熟悉控件位置后，不要重新排列控件，除非这样做的收益显著且经过测试。
10. 不要用占位文本代替标签。
11. 不要通过确认来阻止可撤销的操作；应提供撤销功能。
12. 不要在没有明确反馈和恢复方式的情况下自动前进、自动提交或自动删除。
13. 不要一次展示所有可能的操作；在上下文表明相关时再显示高级操作。
14. 不要让键盘快捷键成为完成任务的唯一方式。
15. 不要把组件库当作完整的 UX 解决方案；应定义针对具体任务的行为和状态。

无障碍和包容性要求

每项建议都必须满足以下基本要求：

• 优先使用语义化 HTML 或平台原生语义。
• 为输入项提供可见标签，为控件提供无障碍名称。
• 确保所有交互元素都可通过键盘访问。
• 定义合理的焦点顺序，并显示焦点状态。
• 仅在真正的模态框中锁定焦点；关闭后将焦点还原到触发控件。
• 仅在原生语义不足时使用适当的 ARIA。
• 以编程方式将错误消息与字段关联。
• 不要依赖仅悬停时触发的交互；应提供点击、轻触或键盘操作方式。
• 不要只依赖颜色；还应配合文本、图标、形状或位置。
• 遵循减少动态效果的偏好设置。
• 设计移动端或触摸界面时，确保目标尺寸适合触摸操作。
• 必要时确保加载、空内容、成功和错误状态会被告知用户。
• 让禁用控件的状态易于理解；如果可能，应说明操作不可用的原因。
• 除非已知目标受众熟悉高级桌面操作惯例，否则应避免使用依赖这些惯例的交互模式。

前端实现指南

当输出包含实现指南时，请说明：

组件结构

定义各个子部分：根元素、标签、触发器、内容、项目、操作、辅助文本、错误文本、图标、徽章、覆盖层、背景遮罩、页脚和任何插槽。

状态

对于每个组件，定义：

• 默认状态
• 悬停、按下、选中、展开、折叠状态（如适用）
• 键盘焦点可见状态
• 禁用和只读状态
• 加载和骨架屏状态
• 空状态
• 成功状态
• 警告状态
• 错误状态
• 离线或数据过时状态（如适用）
• 减少动态效果时的替代方案

语义结构

优先使用原生元素：

• 使用 button 执行动作，而不是可点击的 div。
• 使用 a 进行导航。
• 将 label 与输入框关联。
• 对真正的表格数据使用 table、thead、tbody、th、td。
• 对真正的模态框使用 dialog 或符合无障碍要求的模态框模式。
• 使用列表（ul、ol）表示列表结构。
• 使用地标元素（nav、main、aside、header、footer）划分页面区域。

键盘行为

为菜单、对话框、标签页、手风琴、表格、网格、自动补全和可拖动交互指定键盘行为。为拖放操作提供非拖动的替代方式。

响应式行为

定义组件如何适配：

• 堆叠或折叠次要区域。
• 保留主要任务和操作。
• 避免隐藏必需的导航，且不提供可发现的替代方式。
• 确保触控目标足够大。
• 在视口变化时保留状态。

设计系统集成

• 复用现有的间距、颜色、排版、层级、圆角和动态效果令牌。
• 仅针对有实际行为或语义差异的情况创建变体。
• 避免使用会改变组件含义的一次性样式覆盖。
• 说明内容限制、截断、换行以及内容过长或为空时的处理方式。
• 说明不应使用组件的情形。

性能与可维护性

• 仅在确有需要时使用虚拟化，并妥善处理无障碍访问和位置恢复。
• 避免无限加载，确保用户能够恢复浏览位置或访问页脚内容。
• 避免过多动画和布局偏移。
• 对开销较大的数据可视化和仪表板采用渐进式加载。
• 让加载状态发挥作用：先显示稳定区域，并优先呈现可读内容。

质量检查清单

定稿建议前，请确认：

• 用户任务明确。
• 推荐模式适合任务、数据形态、用户技能、平台和风险。
• 主要操作清晰，不会与同等权重的操作相互竞争。
• 导航和退出路径清晰可见。
• 状态变化会提供即时且易懂的反馈。
• 已定义空、加载、错误、成功和禁用状态。
• 针对破坏性或代价高昂的操作，采取了适当的预防措施或恢复方案。
• 表单尽量减少输入，提供标签和提示，验证方式得当，并能妥善恢复。
• 组件支持键盘操作，且屏幕阅读器能够理解。
• 响应式行为能够保留主要任务。
• 建议可通过可复用组件和令牌实现。
• 已说明权衡和替代方案。

请参阅 references/checklists.md 中的完整检查清单。

常见误区

• 根据对组件的偏好而非用户任务进行设计。
• 将主页或仪表板当作包罗万象的页面。
• 在复杂任务中过度使用模态框。
• 将重要操作藏在仅悬停时才出现的工具中。
• 让每个操作在视觉上都显得重要。
• 用户需要比较时却选择卡片。
• 用户需要视觉浏览时却选择表格。
• 在专家工作流中使用向导。
• 为常规且可撤销的操作使用确认对话框。
• 对不熟悉的操作使用没有标签的巧妙图标。
• 使用骨架屏或旋转指示器，却不保留布局或显示进度。
• 忽略键盘和焦点行为。
• 创建绕过设计系统的一次性组件。
• 为追求新颖而牺牲熟悉的交互方式。

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

如何向用户解释推荐理由

请从以下方面进行解释：

1. 用户任务：“用户需要按状态和日期比较各行，因此表格比卡片更合适。”
2. 认知负担：“这样可以让下一步操作始终清晰可见，避免用户记住自己选择了什么。”
3. 上下文保留：“分栏视图可以在详情变化时保持列表可见。”
4. 安全性：“这里撤销比确认更合适，因为该操作可逆且频繁。”
5. 无障碍性：“必须能通过键盘访问该操作，且不能依赖悬停。”
6. 实现方式：“可以复用现有表格组件，并添加空状态、错误状态和加载状态。”

避免说“看起来更好”，除非视觉变化能直接改善层级、可读性、可供性或无障碍性。