interaction-design

交互设计

面向产品设计师、UX 设计师、UI 设计师、服务设计师和交互设计师的实践指南。本技能涵盖 IxD 工作的全部范围——从基础原则到实际的状态设计、流程规范和交互评审。

本技能涵盖的内容

• 设计并规范交互：流程、状态、转换、可供性
• 根据既定原则评估交互质量
• 编写交互规范和交接注释
• 微交互设计（触发器、规则、反馈、循环）
• 反馈系统设计：时机、类型和层级
• 响应时间标准与感知性能
• 各设计领域中不同角色的 IxD 职责
• 常见的交互反模式及其修正方法

告诉 Claude 你的需求。示例：

• “帮我设计多步骤结账的交互流程”
• “这个按钮需要哪些状态？”
• “评审一下这个交互——反馈是否在恰当的时机出现？”
• “我需要为这个拖放功能编写交互规范”
• “这个模态框的动画时长设为多少合适？”
• “这个仪表板的空状态应该怎么处理？”

---

交互设计的 5 个维度

交互设计涉及五种要素。每次交互都由这些维度中的若干项组合而成。

维度	含义	设计问题
文字	标签、说明、微文案、错误消息、按钮文字	语言是否清晰且以行动为导向？是否准确设定了预期？
视觉呈现	图标、图像、字体、颜色、数据可视化	视觉元素是否清晰传达了交互可供性？
物理对象／空间	设备类型、屏幕尺寸、输入方式（触摸／鼠标／语音／键盘）、物理环境	交互是否针对合适的输入方式和使用场景进行设计？
时间	转换时长、动画时序、响应延迟、序列	时序是否让人觉得响应迅速且合理？是否传达了状态变化？
行为	系统对用户操作的响应——产品会执行什么操作、如何反应	系统行为是否符合用户的心智模型和明确意图？

设计交互时，要识别其中涉及哪些维度。大多数交互故障都源于维度不匹配——例如，系统行为与视觉可供性相矛盾，或微文案与实际发生的情况不符。

---

核心原则

Norman 的 6 项基本原则

Norman 的 6 项基本原则仍是适用范围最广的交互质量框架。

可见性 让系统状态和可用操作清晰可见。用户不应猜测系统正在做什么，或接下来可以做什么。

• 当前状态清晰可见（已选中、加载中、已激活、出错）
• 可供操作的元素清晰可见（交互元素看起来可交互）
• 产品中的导航和当前位置清晰可见

❌ 表单提交后没有任何提示，也不显示加载状态 ✅ 点击提交按钮后，按钮立即切换为加载动画

反馈 每项操作都应立即产生可感知的响应。系统必须传达已收到用户输入，以及对输入做了什么处理。

• 立即确认（100 ms 内——早于处理完成）
• 清晰传达结果（成功、失败、进行中）
• 反馈程度与操作的重要性相称

❌ 删除操作没有确认、动画或提示 ✅ 删除操作立即显示撤销提示，然后淡出该条目

约束 仅提供当前情境下有效的操作。与其事后恢复，不如提前避免错误。

• 对无效操作禁用，而不是在用户尝试后才显示错误
• 使用渐进式披露，只显示相关控件
• 表单字段仅接受有效的输入类型

❌ 允许用户以自由文本输入日期，然后在提交时显示“日期无效” ✅ 使用日期选择器，将选择限制为有效日期

映射 控件与其效果之间的关系应当直观。控件在空间或概念上都应与其影响对象相关联。

• 向上滚动 → 内容向上移动（自然映射）
• 音量滑块从左向右增大
• “下一步”按钮在右侧，“返回”按钮在左侧

❌ 亮度控件只有一个看起来像对比度图标的标记 ✅ 滑块标注为“亮度”，并且沿着“光线更强”的方向增大

一致性 类似操作在整个产品中应有相似的表现。用户会根据模式建立心智模型——打破这些模式会导致错误和困惑。

• 内部一致性：同一组件在各处的行为相同
• 外部一致性：符合用户熟悉的平台惯例
• 在不同断点和平台间保持一致

❌ 在一个列表中可滑动关闭，在另一个列表中却不行 ✅ 所有破坏性操作都使用相同的确认模式

示能性 UI 元素的外观应反映其行为。组件的外观应能提示用户如何与之交互。

• 按钮看起来可以按下
• 可拖动元素带有清晰可见的拖动手柄，或在悬停时通过光标变化作出响应
• 可点击条目具有足够的尺寸和视觉权重

❌ 实际上是链接的纯文本，看起来却与静态正文文本完全相同 ✅ 链接带下划线或使用醒目的颜色，且非交互文本绝不使用这种样式

---

Tognazzini 的 19 项原则

这 19 项原则涵盖了更广泛的人机交互系统。 这些是供从业者采用的实践原则。

预见性 在用户需要搜索信息和工具之前，就将它们呈现出来。提前考虑用户的下一步操作。

• 在相关情境中呈现关联操作
• 预填已知数据（从账户中获取收货地址）
• 在流程进入破坏性操作环节前发出警告

自主性 用户需要感受到自己能够掌控。系统应在用户理解并且能够覆盖的约束范围内运行。

• 允许自定义默认设置
• 未经明确确认，绝不执行不可逆操作
• 透明地显示系统状态，让用户了解正在发生什么

一致性 在四个层面保持一致：产品内部、跨平台、符合行业惯例，以及符合用户预期。如有疑问，应优先遵循用户预期。 默认设置 默认设置应当是大多数用户在大多数情况下的最佳选择。让用户可以轻松更改默认设置，清晰标明默认选项，并确保其有实际意义，而不只是最安全的技术选项。

• 智能默认设置可减少常见场景中的操作阻力
• 应清晰标明默认选项
• 避免在默认选项标签中使用术语

可发现性 如果用户找不到某项功能，这项功能对他们来说就不存在。控件应清晰可见、易于访问，无需用户事先了解。

• 无需说明即可通过导航找到主要路径
• 用户应能通过探索而非查阅手册发现功能
• 对高级功能采用渐进式展示，而不是将其隐藏

用户效率 优化应着眼于用户节省时间，而非系统。常见任务应能快速完成。为专家用户提供快捷方式。最常用的路径应当最短。

• 为常用操作提供键盘快捷键
• 为重复操作提供批量处理功能
• 主要操作应可单击完成（常见任务不应需要多步骤确认）

可探索的界面 用户应能放心探索。可撤销的操作能让用户自由尝试。

• 所有破坏性操作都应支持撤销
• 提交前提供预览（例如图片裁剪、文档格式）
• 提供面包屑导航和清晰的返回路径

菲茨定律 获取目标所需时间 = f（距离、大小）。目标越大、距离越短，交互耗时和出错率就越低。

• 触控目标：最小尺寸为 44×44px（iOS/Android），48×48px（Material）
• 鼠标目标：最小尺寸为 32×32px
• 主要 CTA 应是所在区域中最大的交互元素
• 将相关操作放在彼此相近的位置
• 利用屏幕边缘和角落——它们在一个方向上是无限大的目标

降低延迟 应在 100ms 内响应输入。如果处理耗时更长，应立即确认已收到操作并显示进度。

• 0–100ms：除视觉状态变化外，无需其他反馈
• 100ms–1s：显示加载指示器（旋转图标或骨架屏）
• 1s–10s：显示进度指示器和预计完成时间
• 10s 以上：允许在后台处理，并在完成时通知用户

易学性 界面应能让用户随着时间逐渐学会，而不只是在初次使用时易于上手。专家的操作速度应快于新手。

• 随着用户积累经验，逐步展现更复杂的功能
• 为不易理解的功能提供工具提示和内联指引
• 不要只针对首次使用进行优化

隐喻 使用能准确传达系统功能的隐喻。如果隐喻造成限制或误导，就应弃用。

• “垃圾桶”图标表示删除和恢复
• “文件夹”表示整理和嵌套
• 避免使用会让人误以为存在实际限制的隐喻

保护用户的工作成果 绝不能因界面错误或用户的意外操作而销毁数据。持续自动保存，提供撤销功能，并在覆盖内容前进行确认。

• 自动保存草稿
• 离开未保存的内容前发出警告
• 验证失败时绝不清空表单

可读性 文本必须让所有用户都能清晰阅读，而不只是在理想条件下可读。

• 网页正文文字大小至少为 16px
• 对比度至少为 4.5:1（WCAG AA）
• 正文行长为 50–75 个字符
• 在 50 岁以上的用户和明亮光线条件下进行测试

简洁性 简洁不等于极简。简洁意味着减少不必要的复杂性，同时保留用户需要的所有功能。

• 采用渐进式展示，而不是移除功能
• 避免通过隐藏必要控件来营造虚假的简洁感
• 屏幕上的每个元素都应有存在的理由

状态 追踪用户所在的位置及其操作，并在不同会话间恢复状态。

• 记住滚动位置、表单进度和已打开的面板
• 清晰标明当前位置（面包屑导航、当前选中的导航项）
• 区分新内容和已访问内容

可见导航 用户应始终知道自己身处何处、可以前往哪里，以及如何返回。

• 在导航中突出显示当前位置
• 为深层层级提供面包屑导航
• 返回按钮的行为应符合预期（浏览器和原生应用）
• 切勿让用户陷入没有明显退出方式的流程

美学 视觉设计会影响用户感知到的易用性。精致的界面更容易赢得信任。

• 美学品质不是装饰，而是体现用心与品质
• 切勿让美学趋势损害易用性
• 测试视觉改动对任务表现的影响

颜色 颜色传递含义。设计时要考虑无法仅依赖颜色获取信息的用户。

• 切勿仅用颜色表示含义（错误、成功、必填）
• 通过形状、图案和标签为色盲用户提供支持
• 红色仅用于错误，切勿将红色用于中性操作

人机界面对象 无论交互对象出现在哪里，其行为都应保持一致。按钮就是按钮，链接就是链接。

• 组件的行为应能从其外观中预判
• 复用成熟模式，而不是为每个屏幕重新设计交互方式

---

NNGroup 的交互属性

NNGroup 指出了八种影响用户如何感知产品的交互特质，并由此影响用户对其背后品牌的印象。

属性	定义	设计启示
响应速度	元素对输入作出反应的速度	每次操作都需在 100ms 内得到确认
直接操控	用户是直接与对象交互，还是通过中介交互	拖放与菜单；直接编辑与表单对话框
精确度	用户控制的精细程度	可精细控制的滑块与粗略分档
可变性	实施更改的容易程度	更改某项内容需要付出多少努力？
连续与离散	平滑过渡与分步过渡	音量滑块与音量按钮
清晰的标签／反馈	系统传达可用操作及其后果的清晰程度	工具提示、标签、ARIA、辅助文本
符合预期的行为	与用户心智模型的一致程度	它的行为是否与外观所示一致？
一致性	是否符合既定模式	相同组件 → 始终有相同行为

---

响应时间与反馈设计

三个响应阈值

阈值	时间	用户感知	设计响应
即时	≤ 0.1s	感觉直接，察觉不到延迟	仅改变视觉状态（按钮激活状态）
保持流程	0.1s – 1.0s	用户注意到延迟，但仍能保持专注	加载指示器或骨架屏
注意力极限	1s – 10s	用户开始分心；必须有意识地保持专注	显示预计时间的进度指示器
放弃风险	> 10s	用户会离开，尤其是在 Web 上	后台处理 + 完成后通知

反馈类型

视觉反馈 — 默认方式。每次交互都应引发视觉状态变化。

动效反馈 — 传达正在发生变化以及变化的方向。

• 页面切换可传达导航方向（向左滑动 = 前进）
• 高度动画可传达展开／折叠
• 淡入淡出可传达出现／消失

触觉反馈 — 用于原生移动端。谨慎使用，仅用于有意义的确认。

• 成功：轻触一次
• 警告：轻触两次
• 错误：振动模式

音频反馈 — 根据情境使用。避免用于常规操作。

感知性能模式

骨架屏 — 在内容加载时显示布局结构。对于页面级内容，它比加载动画更好，因为可以缩短用户感知到的等待时间，并防止布局偏移。

乐观 UI — 在服务器确认之前，立即在 UI 中应用操作结果。失败时回滚。最适合高置信度的操作（如点赞、关注、投票）。

进度指示器 — 对于耗时超过 1 秒、需要用户等待的操作，请使用进度指示器。进度可确定时显示百分比；无法确定时使用动态指示器。

即时过渡 — 页面级过渡动画不要快于 150ms，也不要慢于 400ms。最佳时长为 200–300ms。

→ 完整实现模式请参阅 reference/response-time.md。

---

设计交互

组件状态

每个交互式组件都需要一套完整的状态。状态缺失会导致视觉回归、无障碍访问问题和行为不一致。

状态	适用时机	设计要求
默认	初始状态，尚未交互	清楚表明可进行交互
悬停	光标/指针位于元素上方（桌面端）	轻微的视觉变化；避免大幅布局偏移
焦点	键盘或程序设置的焦点	必须可见（WCAG 2.4.7）；移除轮廓时绝不能不提供替代样式
激活 / 按下	元素正被点击/轻触	显示下沉或高亮状态，以确认已接收到输入
加载中	操作进行中	禁用后续输入；显示进度
已禁用	当前无法执行操作	降低不透明度或改变样式；无悬停状态；光标：not-allowed
错误	验证失败或系统错误	红色 + 图标 + 文本；绝不能仅使用颜色
成功	操作已成功完成	提供正向确认；常规操作的确认应为短暂显示
空状态	无内容可显示	绝不能显示空白屏幕；提供上下文和下一步操作
骨架屏	内容首次加载	与即将显示的内容布局相匹配

状态设计检查清单：

• 为交互式组件定义了全部 10 种状态
• 焦点状态可见，并符合 WCAG 2.4.7
• 错误状态使用颜色 + 图标 + 文本（而非仅使用颜色）
• 已禁用状态在视觉上易于区分，但不单靠颜色来区分
• 空状态提供了继续操作的路径

交互流程

流程是用户为实现目标而在产品中经历的路径。良好的流程有明确的入口、顺畅路径、针对边缘情况的分支，以及错误恢复机制。

流程结构：

Entry point → [Trigger] → Interaction sequence → [Decision] → Outcome
                                                      ↓
                                                  Error path → Recovery → Resume

流程设计问题：

• 用户进入此流程时的目标是什么？
• 用户在每个步骤需要哪些信息？
• 决策点在哪里？每个分支会发生什么？
• 可能出现哪些问题？恢复路径是什么？
• 出口是什么？是否清晰且一致？

多步骤流程原则：

• 显示进度（步骤指示器、面包屑、百分比）
• 允许向后导航，且不丢失数据
• 自动保存进度，让用户可以稍后继续
• 在错误发生的步骤内直接显示错误，而不是等到提交时再显示
• 用户要退出并放弃操作时进行确认（“确定要离开吗？您的进度将会丢失。”）

过渡与动画

在 IxD 中，动画只有一个目的：传达信息。它传达状态变化、空间关系和系统反馈。避免将动画用于装饰。

适合使用动画的情况：

• 元素的出现或消失（淡入淡出、缩放）
• 视图间导航（滑动、推入）
• 内容的展开或折叠（高度过渡）
• 加载和进度状态
• 确认和错误状态

不适合使用动画的情况：

• 悬停状态（轻微改变颜色就足够）
• 工具提示的出现（即时显示即可）
• 文本变化
• 用户需要等待结果的任何过渡

时长指南：

交互类型	时长	缓动
微交互（按钮状态、切换）	100–150ms	ease-out
小型组件过渡（下拉菜单、工具提示）	150–200ms	ease-out
中型组件过渡（模态框、面板）	200–300ms	ease-in-out
整页过渡	250–400ms	ease-in-out
加载动画	以 1–2s 的周期循环	linear

缓动：

• ease-out — 开始快，结束慢。用于进入屏幕的元素。
• ease-in — 开始慢，结束快。用于离开屏幕的元素。
• ease-in-out — 过渡过程平滑。用于重新定位。
• linear — 匀速。用于加载指示器和进度条。

可供性与指示符

可供性 — 元素实际具备的能力（按钮可以按下）。

感知可供性 — 元素看起来能够实现的操作。这才是关键。

指示符 — 用于传达交互方式的信号（拖动手柄、下划线、文本框中的占位符）。

设计时应关注感知可供性，而不只是实际可供性：

• 没有阴影、背景和边框的扁平按钮，感知可供性较差
• 文本输入框需要边框、背景对比或下划线来表明其可编辑
• 可拖动元素需要视觉手柄或光标变化来表明其可拖动

反可供性 — 表明某项操作无法执行的信号（禁用按钮、灰显的文本框）。它们与可供性同样重要，能避免用户尝试错误操作。

心智模型

心智模型是用户对系统工作方式的内部认知。优秀的交互设计会让系统行为与用户已有的心智模型保持一致。

适合遵循心智模型的情况：

• 导航模式（返回按钮、汉堡菜单的位置）
• 表单行为（Tab 顺序、验证时机）
• 破坏性操作（先确认 → 再继续，而非先继续 → 再确认）
• 数据持久化（自动保存还是显式保存）

心智模型发生冲突时： 如果新的交互模式打破了既有的心智模型，必须：

1. 在变化发生前清楚地提示
2. 在偏离发生时提供引导
3. 考虑这种偏离是否值得付出代价

❌ 不作提示就改变滑动手势的含义
✅ 首次使用时添加工具提示：“向左滑动即可归档（之前的操作：删除）”

---

微交互

微交互是处理单一使用场景的小型、独立交互。它们构成了界面的肌理——不是引人注目的主要功能，却能让产品显得精致而用心。

微交互框架：

Trigger → Rules → Feedback → Loops & Modes

触发

什么会启动微交互？用户发起的触发是显式的（点击按钮、滑动）。系统触发则是自动的（收到通知、下载完成）。

规则

触发发生时会怎样？规则定义了行为：

• 哪些状态会改变？
• 事件按什么顺序发生？
• 有哪些限制？（能否撤销？是否有最小值或最大值？）

反馈

用户如何知道规则正在执行？

• 视觉：状态变化、动画、颜色变化
• 文本：标签变化、确认文案、错误消息
• 声音：通知提示音、错误提示音（谨慎使用）
• 触觉：确认触感（仅限原生移动端）

循环与模式

微交互会重复吗？它会根据历史记录改变行为吗？

• 用户输入时，密码强度指示器会循环运行
• 开关在两种模式之间切换
• 下拉刷新是一个循环操作，并在完成时有明确的结束状态

常见微交互示例

按钮状态： 触发条件：点击 → 规则：提交表单 → 反馈：按钮文字变为“正在保存…”，并显示加载动画 → 循环：最终显示“已保存”或“出错”

行内表单验证： 触发条件：失去焦点（离开字段） → 规则：验证格式 → 反馈：行内显示绿色勾号或红色错误消息 → 循环：字段内容变化时重新验证

开关： 触发条件：轻触 → 规则：切换布尔值 → 反馈：滑块移动、颜色变化、标签更新 → 模式：开 / 关

下拉刷新： 触发条件：下拉超过阈值 → 规则：获取新数据 → 反馈：显示加载动画和“正在刷新…”，然后更新内容 → 循环：完成后可再次刷新

点赞 / 表情回应： 触发条件：轻触 → 规则：切换已点赞状态 → 反馈：图标填充颜色，计数增加（乐观 UI） → 模式：已点赞 / 未点赞

---

针对不同角色的应用

产品设计师

你的 IxD 工作涵盖整个产品——流程、状态、反馈和过渡。

• 探索阶段：使用流程图映射完整任务，而不只是顺利路径。尽早找出分支和错误状态。
• 编写规格阶段：标注行为，而不只是外观。“所有必填字段都有效后，按钮才会启用”比展示一个灰色按钮的视觉稿更有用。
• 交接阶段：记录全部 10 种组件状态。标注过渡时长和缓动效果。对于不明显的动画，附上动效参考（Figma 原型或视频）。
• 评审阶段：将交互决策与用户目标联系起来。“这符合……的心智模型”比“我觉得这样更合适”更有说服力。

UX 设计师

你的 IxD 重点在于任务流程、信息架构和错误恢复。

• 设计任何屏幕之前，先绘制所有流程。找出死胡同——用户可以进入却无法顺利退出的状态。
• 将错误恢复视为首要设计任务，而不是事后补充。每种错误状态都需要说明：发生了什么、为什么发生，以及接下来该做什么。
• 将微文案纳入交互设计，而不是事后再写。标签、占位符、错误消息和辅助文本都是交互的一部分。
• 进行视觉设计之前，先通过基于任务的测试验证流程。

UI 设计师

你的 IxD 重点在于组件状态、动效设计和交互还原度。

• 为每个交互组件提供全部 10 种状态，而不只是默认和悬停状态。
• 使用动效系统，而不是一次性的动画。定义时长标记（快速：150ms，中等：250ms，慢速：400ms），并保持一致地应用。
• 交接之前先制作交互原型——工程师实现的是他们理解的内容，而不是他们推测的内容。
• 根据规格审查已构建的产品。缺少设计师参与时，交互质量会在实现过程中下降。

服务设计师

你的 IxD 工作不仅涉及屏幕，还延伸至跨渠道触点和面向员工的系统。

• 每个触点都会发生交互：网页、应用、自助终端、IVR、线下服务。在设计单个屏幕之前，先用服务蓝图映射所有触点。
• 面向员工的交互要求与面向客户的交互不同：优先考虑效率而非探索、容错能力，以及情境感知（员工很忙，流程中途也可能被打断）。
• 渠道之间的过渡也是交互：“你将收到一封确认邮件”就是一项交互规格。
• 同时与客户和一线员工进行测试。员工体验中的问题会演变为面向客户的问题。

交互设计师

作为专职的交互设计（IxD）角色，你负责整个行为层。

• 负责动效系统，并确保其实现保持一致。
• 对整个产品进行交互审查，找出不一致之处和缺失状态。
• 编写工程团队无需追问即可实现的行为规范。
• 与无障碍专家合作，确保交互模式支持键盘和屏幕阅读器访问。

---

交互审查清单

在交接或发布前审查设计时，请使用此清单。

流程

• 核心流程清晰明确
• 所有决策分支都已设计（而不仅仅是预期分支）
• 错误流程能够引导用户恢复，而非陷入死胡同
• 多步骤流程会显示进度，并允许向后导航
• 退出破坏性操作前会发出警告

状态

• 为每个交互组件设计全部 10 种状态
• 焦点状态清晰可见，且符合 WCAG 标准
• 错误状态同时使用颜色、图标和文本
• 空状态提供背景信息和下一步操作
• 加载状态可防止重复输入

反馈

• 每项操作都会得到即时的视觉确认（100ms 以内）
• 成功和失败状态有明显区分
• 反馈程度与操作的重要性相称
• 长时间运行的操作会显示进度

可供性

• 交互元素看起来具有交互性（感知可供性）
• 非交互元素看起来不具有交互性
• 可拖动元素带有视觉手柄或光标提示
• 禁用元素在视觉上有明显区分

动效

• 所有动画都具有传达信息的目的
• 动画时长和缓动遵循动效系统
• 动画不会延误用户继续操作
• 遵循 prefers-reduced-motion

微文案

• 按钮标签使用以操作为导向的动词
• 错误消息说明发生了什么、原因是什么，以及接下来该怎么做
• 占位文本仅作补充，不能替代标签
• 确认对话框明确指出将删除或更改的内容

无障碍

• 所有交互都支持键盘操作
• 焦点顺序遵循视觉阅读顺序
• 定时交互可以延长或暂停
• 非文本交互元素均提供 ARIA 标签

---

常见反模式

不可见的可供性

❌ 可点击文本看起来与不可点击文本完全相同 ❌ 可拖动项没有任何视觉提示 ❌ 按钮看起来像普通文本 ✅ 建立清晰、一致的交互视觉语言。交互元素应看起来具有交互性，非交互元素应看起来静态。

缺少状态

❌ 组件只有默认设计，没有错误、空、加载或焦点状态 ❌ 交接内容只展示核心流程 ✅ 交接任何组件前，都应设计好全部 10 种状态。

反馈来得太晚

❌ 表单只在提交后才验证，此时用户已经填写了五个字段 ❌ 破坏性操作没有即时反馈 ✅ 在失焦时进行行内验证。100ms 以内确认每项操作。

动画延误操作

❌ 模态框进入动画长达 600ms，用户必须等待动画结束才能进行交互 ❌ 每次导航都会运行动画过渡，让每项操作都变得更耗时 ✅ 将进入动画控制在 200–300ms。切勿让用户因为动画而等待。

没有错误恢复路径

❌ 错误消息只写着“出了点问题”，没有操作建议，也不能重试 ❌ 验证失败后表单会清空所有字段 ✅ 每个错误状态都必须说明：发生了什么 + 原因是什么 + 接下来该怎么做。保留用户输入。

未经提示就违背心智模型

❌ 滑动手势的行为与用户对其平台的预期不符 ❌“返回”按钮重置状态，而不是返回上一页 ✅ 遵循平台惯例。必须偏离时，应明确提示用户。

禁用但不说明原因

❌ 按钮呈灰色且没有工具提示或上下文说明禁用原因 ✅ 禁用状态应说明启用条件：“选择日期后即可使用。”

破坏一致性

❌ 同一组件在不同屏幕上的行为各不相同 ❌ 有些屏幕上的模态框确认按钮在左侧，另一些则在右侧 ✅ 交互模式应由系统统一决定，而非针对每个屏幕单独决定。应将其记录成文并确保遵循。

---

输出格式

启用此技能后，Claude 会根据你的需求调整输出：

交互规范

针对某个组件或流程的完整行为规范：

• 触发条件
• 状态转换
• 反馈说明（视觉、动效、文案）
• 边缘情况和错误处理
• 无障碍说明

状态表

组件所有状态的结构化表格，包含：

• 状态名称
• 视觉描述
• 触发条件
• 转换行为

流程图（文本）

流程的结构化文本表示，包含：

• 入口点
• 状态序列
• 决策分支
• 错误路径和恢复方式
• 退出点

交互评析

根据原则评估现有交互，包含：

• 违反的原则
• 这对用户为何重要
• 具体且可执行的修正方案

动效说明

动画规范：

• 动画元素和属性
• 持续时间和缓动
• 触发和退出
• 减少动态效果的替代方案

格式约定

• 多部分输出使用结构化标题
• 使用表格呈现状态集合和比较矩阵
• 使用 ❌/✅ 区分反模式与推荐做法
• 使用代码格式呈现时间值和 CSS 属性
• 添加注释说明原因，而不只是给出决定

---

参考文件

• reference/principles.md — 完整的 Tognazzini 19 项原则和 Norman 6 项原则，附有应用示例和违规模式
• reference/response-time.md — Nielsen 的 3 个响应时间阈值，以及各类加载和反馈场景对应的实现模式
• reference/patterns-and-flows.md — 常见 IxD 模式：表单、导航、搜索、新手引导、错误处理、空状态、模态框