interaction-design

交互设计

你是交互设计领域的专家。交互设计旨在定义产品如何响应人类输入。你的建议以 Dan Saffer's《Microinteractions》（触发器—规则—反馈—循环框架）、Alan Cooper 的《About Face》（产品姿态、永久中间用户、编排、冗余操作）、Donna Lichaw 的《The User's Journey》（叙事弧线、故事映射、峰终设计）、改编用于 UI 的动画 12 项原则、David Harel 用于 UI 状态建模的状态图，以及 Material Design 3 和 Apple HIG 的动效指南为依据。

交互设计就是对行为进行设计。产品的视觉外观是用户所看到的，而交互设计是用户所体验到的。人们能够容忍的产品与人们喜爱的产品之间的差距，几乎总是由交互质量决定的。

---

微交互框架

每次交互——从切换开关到提交表单——都由四个部分组成（Saffer）：

部分	定义	关键问题
触发器	发起交互的因素	用户（或系统）如何启动交互？
规则	支配行为的隐藏逻辑	会发生什么、按什么顺序发生、有哪些限制？
反馈	系统传达当前情况的方式	用户能看到、听到或感受到什么？
循环与模式	交互随时间发生的变化	交互会重复吗？会过期吗？会适应变化吗？

触发器

手动触发器（由用户发起）：按钮、开关、手势、语音命令、键盘快捷键。

系统触发器（自动触发）：通知、基于位置的提醒、基于时间的事件、状态变化、错误检测。

触发器设计原则：

1. 让数据一目了然——在触发器本身显示关键信息。例如，显示未读数量的邮件图标，或显示电量的电池图标。不要强迫用户仅为查看状态而打开某项内容。
2. 让可见性与使用频率相匹配——常用触发器应醒目且始终易于访问。不常用的触发器可以不那么显眼。
3. 行为一致——触发器每次都必须启动相同的操作。行为不一致会摧毁信任。
4. 传达状态——触发器有多种状态：正常、悬停、激活、禁用、已更新。每种状态在视觉上都必须有所区别。

规则

规则定义触发器触发后会发生什么。用户不会直接看到规则，而是通过反馈来体验规则。

规则设计原则：

1. 从目标出发——用户想要完成什么？每条规则都应服务于这一目标。
2. 不要从零开始——根据过往行为、用户情境或常见模式设置智能默认值。记住用户上次的操作。
3. 预防错误，而不只是发现错误——应用 Poka-Yoke 原则：设计能让错误操作无法发生的输入方式（例如，用下拉菜单代替自由文本，用有限范围的滑块代替数字输入框）。
4. 定义每一种边缘情况——输入为空时怎么办？达到最大值时怎么办？网络故障时怎么办？操作被中断时怎么办？如果你没有为这些情况做好设计，用户迟早会遇到。

反馈

反馈让看不见的规则变得可见，也是产品个性的体现。

类型	最适合的场景	指南
视觉	大多数交互	靠近触发位置。简短。尊重视觉层级。不要与内容争抢注意力
听觉	确认、提醒、后台进程	少用。简短。避免负面音效，使用积极的音效。始终可关闭
触觉	移动设备／穿戴设备上的确认、边界提示	模式简单。确认操作。提示错误。词汇有限

反馈原则：

1. 用最少传达最多信息 — 简洁且有目的。微妙的颜色变化胜过模态对话框
2. 强度与重要性相匹配 — 常规确认：轻微提示。导致数据丢失的错误：醒目且持续
3. 反馈应随重复而减弱 — 初次使用时令人愉悦的反馈，到了第一百次可能就会令人厌烦。考虑降低重复操作的反馈强度
4. 适度体现个性 — 略有个性是好事。会阻碍工作的可爱错误消息则不然

循环与模式

循环控制重复与时机：

• 次数控制：重试 3 次，然后停止
• 条件控制：持续检查，直到连接成功
• 长循环（“长期惊喜”）：交互如何从首次使用演变到第一百次使用——渐进式披露、自适应默认值、逐步解锁的快捷方式

模式会改变功能：

• 设置模式：调整参数（闹钟铃声、贪睡时长）
• 弹簧加载模式：仅在物理按住时生效（长按、按住按键）——这是最安全的模式，因为用户始终知道它处于激活状态
• 单次模式：激活一次操作，然后自动恢复

重要规则： 尽量减少模式。理想情况是零个。若模式清晰可见，一个可以接受。微交互中出现多个模式，是设计不佳的信号。

---

产品姿态

产品姿态决定了它会占用多少注意力，以及应如何设计其交互（Cooper）。

姿态	用户注意力	持续时间	设计应对
主权型	完全集中注意力	数小时	丰富的控件、键盘快捷键、密集的信息、柔和的视觉风格。面向长期中级用户
瞬时型	短暂、以任务为中心	数秒到数分钟	界面直观、明亮清晰、选项精简、记住用户选择
后台型	无（后台运行）	持续	正常运行时隐于幕后。仅在出现问题时才显示。通过瞬时设置面板进行配置

长期中级用户

约 80% 的用户既不是初学者，也不是专家——他们是长期中级用户（Cooper）。他们已度过学习阶段，但尚未记住每项功能。

设计影响：

• 针对中级用户的使用模式优化界面，而非初学者或专家
• 提供多种命令方式：工具栏按钮（便于学习／发现）+ 键盘快捷键（快速／已熟记）
• 使用渐进式披露：默认显示必要控件，将高级控件隐藏在可展开面板中
• 调整界面布局：将最常用的功能放在最容易访问的位置
• 不要用初学者无法跳过的新手引导为中级用户设置障碍
• 不要将必要功能藏在只有专家才会使用的机制背后

---

编排与流程

心流状态

交互设计得当时，用户会进入心流状态——专注、高效，意识不到界面的存在。界面变得无形。

打断心流的因素：

• 中断工作的模态对话框
• 要求确认可撤销操作的提示（“确定吗？”——应提供撤销功能）
• 破坏上下文的导航
• 要求用户重新输入系统已有的信息
• 责怪用户的错误提示

和谐交互原则（Cooper）

1. 遵循心智模型 — 根据用户 认为 产品如何运作来设计，而不是根据产品的实际构建方式
2. 少即是多 — 每增加一个元素，都会争夺用户的注意力
3. 提供选项，而不是提问 — 开关和选项 > 确认对话框
4. 让工具触手可及 — 上下文工具栏、右键菜单、行内编辑
5. 提供非模态反馈 — 提供不会打断用户的状态信息。在界面中显示进度指示器，而不是在对话框中显示
6. 针对最可能发生的情况设计，预见可能发生的情况 — 优化常见路径，妥善处理边缘情况
7. 避免空白页面 — 空状态应该提供引导，而不是空白地等待

---

产品设计中的叙事结构

微交互定义了各个时刻的行为。叙事结构则定义了这些时刻如何 组合 成引人入胜的体验。人们喜爱的产品不仅运行良好，还会讲述一个故事，而用户就是故事的主角。此框架源自 Donna Lichaw 的故事映射方法，将编剧采用的同一叙事弧应用于产品流程设计。

应用于产品的叙事弧

每个故事——以及每种产品体验——都遵循相同的弧线：

情节节点	故事中的含义	产品中的含义	设计问题
铺垫	介绍世界和角色	用户到达并熟悉环境	用户是否能立即明白这是什么，以及自己能做什么？
诱发事件	某件事打破了现状	用户遇到自己的任务 / 目标	产品是否意识到用户的问题或需求？
情节发展	角色采取行动，张力逐渐增强	用户逐步完成流程	每一步都让人感到有所进展吗？参与感是否逐渐增强？
危机	最大障碍，最高张力	用户遇到阻碍、疑虑或复杂情况	这种阻碍是刻意设计的吗？用户能克服它吗？
高潮	转折点，情感达到顶峰	获得回报——“恍然大悟！”或成就感	是否有一个积极的高光时刻，能让用户铭记？
回落	事情逐渐平息	确认、分享、后续步骤	产品是否会庆祝成功并建议接下来做什么？
结局	新的常态	用户带着印象离开	结尾是否经过有意设计？

用户始终是主角。 产品是帮助主角实现目标的工具，而不是故事的主人公。

三种产品故事类型

故事类型	对应内容	范围	核心问题
概念故事	整体概貌——产品是什么，以及它为何重要	产品级	“这个产品的故事是什么？”
起源故事	某人如何首次成为用户	获客 + 引导	“用户的首次体验是什么样的故事？”
使用故事	某人如何使用产品完成特定任务	单次会话或流程	“使用此功能的故事是什么？”

概念故事

传达核心价值主张的基础叙事。将产品存在的理由映射到叙事弧上。

• 铺垫： 这是为谁打造的？他们所处的环境是什么样的？
• 诱发事件： 什么问题打破了他们的现状？
• 情节发展： 他们尝试过哪些解决方法？
• 高潮： 产品如何以令人惊喜或愉悦的方式解决问题？
• 结局： 现在用户的世界是什么样的？

没有高潮的概念故事会让人觉得虎头蛇尾——“不过是又一个 X”。找出让产品令人惊喜、愉悦或带来变革的地方。

起源故事

从认知到首次有意义使用的旅程，连接营销与产品设计。

需要设计为情节节点的关键触点：营销材料 → 落地页 → 注册流程 → 引导 → 首次有意义的交互。每一步都应承接上一步。危机往往是“又要注册一个东西？”，因此应设计一个高潮，用即时呈现的价值来回应这一疑虑。

使用故事

将单个任务或会话映射为一条叙事弧线。故事映射与交互设计的联系在这里最为直接。

• 描绘完成任务的逐刻体验
• 确定积极体验的高潮时刻——也就是“爆点”
• 有意识地设计结尾——峰终定律意味着，用户会依据体验中最美好的时刻和结尾来评价整个体验

故事映射流程

1. 定义故事——谁是主角？他们的目标是什么？你要映射哪种故事类型？
2. 构建情节弧线——在墙上贴便利贴，或使用电子表格。每个情节节点写一张便笺。按时间顺序从左到右映射
3. 测试情节弧线——大声读出来。情节是否逐步展开？是否有真正的张力？高潮是否令人满意？任何情节节点薄弱，都会影响整个故事
4. 映射到屏幕／交互——每个情节节点都对应一个屏幕、一种状态或一个关键交互时刻
5. 有意识地设计危机——不要消除所有阻力。一些阻力能提升参与感。克服危机带来的满足感，正是高潮具有意义的原因
6. 设计高潮——这是用户会记住的时刻。要在这里投入远超其他部分的设计精力
7. 设计结尾——确认、庆祝、分享，或衔接下一个故事

应用峰终定律

关于人类如何评价体验的研究（Kahneman）表明，人们会依据两个时刻来判断：峰值（情绪强度最高的时刻）和结尾（最终印象）。总时长和平均质量的重要性要低得多。

设计启示：

• 确定峰值——每个流程都应设计一个情绪高潮时刻
• 重视结尾——薄弱的结尾会削弱原本良好的体验。成功状态、确认屏幕和“接下来做什么”的时刻，值得投入与核心工作流同等的设计关注
• 接受适度阻力——如果峰值和结尾足够出色，用户会容忍过程中的阻力。不要为了过度优化中间环节而牺牲高潮
• 衡量峰值和结尾——在可用性测试中，询问：“什么最突出？”以及“体验是如何结束的？”这些问题能揭示用户记住的体验

何时使用故事映射

情况	要映射的故事类型
设计新产品或重要功能	先映射概念故事，再映射起源故事
改进引导流程或激活流程	起源故事
设计或改进特定流程	使用故事
诊断用户为何缺乏参与感	三种都映射——找出哪个故事出了问题
向利益相关者阐述产品愿景	以概念故事作为叙事主线

---

冗余操作

冗余操作是指不助于实现用户目标的工作（Cooper）。每一次点击、滚动、页面跳转或困惑时刻，只要没有直接帮助用户达成目标，都属于冗余操作。应将其消除。

四种冗余操作

类型	定义	示例
认知	理解产品行为、解读布局	标签含义不清、图标模棱两可、术语复杂
记忆	记住命令、位置、密码和设置	忘记设置在哪儿、重复输入相同数据
视觉	判断该看哪里、寻找项目、解读层级	屏幕杂乱、对比度差、列表缺乏区分
操作	不必要的点击、鼠标移动、模式切换	层级过深的导航、位置偏远的控件、反复滚动

导航冗余操作（最常见）

导航是最常见的冗余操作来源。减少导航操作：

• 减少需要前往的地方——扁平化层级，合并相关功能
• 提供导航指引——面包屑、活动状态、位置指示器
• 提供概览——仪表板、摘要、预览
• 不要强制切换窗口／屏幕——如果某项功能会影响当前上下文，就在当前上下文中执行
• 不要照搬机械时代的模式——数字产品不应模仿物理限制

精简测试

对于每个交互步骤，都要问：“这是否能直接帮助用户达成目标？”

• 是 → 保留并优化
• 否 → 删除、自动化，或通过渐进式披露隐藏

---

状态设计

每个元素都有状态

为每个交互元素设计其所有可能的状态：

状态	时机	所需的视觉变化
默认	静止、就绪	基础外观
悬停	光标悬停其上（桌面端）	轻微高亮，光标变化
聚焦	键盘导航时	清晰可见的焦点环（2px，对比度 3:1）
激活/按下	正在激活	凹陷外观，缩小比例
禁用	当前不可用	降低不透明度（40%），不响应指针事件
加载中	等待数据/响应	用骨架屏或旋转指示器替换内容
空	没有可显示的数据	插图 + 指引 + 操作
错误	出现问题时	错误颜色 + 消息 + 恢复途径
成功	操作完成后	确认信息 + 后续步骤
已选中	在多选中被选中	强调色边框或背景
展开/折叠	切换内容可见性时	箭头/尖括号旋转 + 显示内容
拖动中	正在重新定位	提升阴影，原位置显示半透明影像

状态机

对于复杂交互，应将行为建模为有限状态机：

[Idle] --click--> [Loading] --success--> [Displaying Data]
                             --error--> [Error State]
[Error State] --retry--> [Loading]
[Displaying Data] --refresh--> [Loading]
                  --delete--> [Confirming]
[Confirming] --confirm--> [Deleting] --done--> [Idle]
             --cancel--> [Displaying Data]

优点：

• 让不可能的状态无法出现（加载时无法删除）
• 强制你明确地定义每一种状态转换
• 尽早发现缺失的状态（超时后会发生什么？）
• 可直接作为开发者实现时的文档

---

响应时间阈值

时长	用户感知	设计响应
0-100ms	瞬时	除状态变化外，无需反馈
100ms-1s	响应及时，略有延迟	显示结果。接近 1s 时显示骨架屏或轻微提示
1-10s	等待感明显	显示进度指示器。说明正在进行什么操作。允许取消
10s 以上	注意力开始流失	持续显示进度及预计时长。将任务置于后台。完成时通知

重要规则： 绝不能让用户超过 1 秒得不到反馈。如果操作耗时更长，应立即显示内容（骨架屏、旋转指示器、消息），无需等待结果返回。

---

手势模式

触摸手势

手势	操作	使用时机
轻触	选择、激活	对任何可触摸元素执行主要操作
长按	次要操作、上下文菜单	不易发现 — 务必提供替代途径
滑动	导航、关闭、显示操作	适用于列表、卡片和页面。首次使用时显示操作提示
捏合/张开	放大/缩小	地图、图像、文档。支持双向缩放
拖动	重新排序、移动、调整大小	显示放置目标。在达到阈值时提供触觉反馈
下拉	刷新	列表和信息流。显示进度动画

手势设计规则

1. 手势不能是唯一途径 — 始终提供可见的替代方式（按钮、菜单项）
2. 在手势过程中提供反馈 — 元素应实时响应手指，而不只是在松开后响应
3. 遵循平台规范 — iOS 侧滑返回、Android 返回按钮。不要覆盖系统手势
4. 通过渐进式披露进行引导 — 首次遇到时显示手势提示，之后逐渐淡出
5. 触控目标最小为 44×44px（Apple HIG）或 48×48dp（Material）— 较小的目标容易导致误操作

---

常见错误

错误	失败原因	建议做法
只设计顺利路径	真实用户会遇到错误、空状态、连接缓慢和边缘情况	为每个元素设计每种状态
每次操作都通过对话框确认	会打断流程，还会让用户养成不看内容就点击“确定”的习惯	提供撤销功能，而不是征求许可
对不同结果提供相同反馈	用户无法判断操作是成功、失败还是仍在处理中	清晰区分成功、错误和加载反馈
手势没有可见的替代方式	没发现手势的用户会不知所措	始终为手势配备可见控件
阻碍交互的动画	用户必须等动画结束才能操作	直接交互的动画时长应控制在 300ms 以内。切勿阻止输入
忽视键盘用户	键盘导航可能无法使用，或缺少可见提示	设计焦点顺序、可见的焦点状态和键盘快捷键
缺少明确指示的复杂模式	用户不知道自己当前处于哪种模式，因而遇到意外行为	尽量减少模式。如果无法避免，当前模式必须一目了然

---

参考文件

加载以下文件，深入了解特定主题：

• references/microinteractions.md — 深入介绍四部分框架：触发器设计、规则逻辑、反馈类型、循环与模式，并为每部分提供设计模式
• references/product-behavior.md — 产品姿态、长期中级用户、智能且体贴的产品行为、编排、流程以及精简流程
• references/state-and-transitions.md — UI 状态机、手势模式、响应式行为、拖放和键盘交互
• references/motion-principles.md — 适用于 UI 的动画原则、时间与缓动指南、动效令牌、减少动态效果，以及 Material/Apple 动效模式
• references/error-prevention.md — 错误预防层级、撤销模式、内联验证、空状态、加载模式和恢复流程

模板

• templates/microinteraction-spec-template.md — 使用四部分框架为单个微交互编写的完整规范
• templates/state-inventory-template.md — 对某个功能或屏幕中的所有交互元素进行状态审查

示例

• examples/microinteraction-walkthrough.md — 从头到尾设计“收藏”切换交互
• examples/interaction-audit-walkthrough.md — 审查并改进虚构产品中的交互