上周帮朋友改一个内部管理系统的按钮，他坚持要把「提交」按钮做成带弹窗确认+3秒倒计时+成功动画的三段式流程。我说：‘这只是一个录入员工姓名和工号的表单。’他愣了一下，说：‘可我们UI规范里写了，所有操作都要有反馈。’
这句话暴露了一个常见误区：把交互模型等同于动效堆砌，或者干脆当成产品经理画的那张流程图。其实，用户界面交互模型是更底层的东西——它定义了用户怎么想、系统怎么应、两者之间那条看不见的协议是怎么运转的。
不是流程图，是状态契约
比如一个搜索框，表面看只是输入+回车=出结果。但背后可能藏着三种交互模型：
- 即时查询模型：输入每个字都触发请求（适合关键词联想）；
- 提交驱动模型：必须点搜索或按回车才发请求（适合复杂筛选）；
- 混合模型：前三个字静默等待，第四个字开始节流查询（兼顾响应与性能）。
选哪种，不取决于设计师喜欢哪套交互动效，而取决于用户此刻的意图节奏。在招聘后台搜「Java工程师」，用户要的是精准结果，不是边输边刷的干扰；而在知识库搜「报错 404」，用户正焦躁翻文档，越快看到相关日志片段越好。
模型藏在代码里，不在设计稿上
很多前端同学写交互逻辑时，习惯先写 DOM 操作，再补事件监听，最后硬塞 loading 状态。这样容易让交互变成「操作-响应」的线性链条，漏掉中间态。真正的交互模型需要显式建模状态流转：
const searchMachine = {
initial: 'idle',
states: {
idle: { on: { INPUT: 'typing' } },
typing: {
on: {
INPUT: 'typing',
SUBMIT: 'searching',
BLUR: 'idle'
}
},
searching: {
on: { SUCCESS: 'results', FAILURE: 'error' }
},
results: { on: { INPUT: 'typing', CLEAR: 'idle' } },
error: { on: { RETRY: 'searching', INPUT: 'typing' } }
}
};这段状态机代码没写一句 UI 渲染，但它锁定了用户所有合法操作路径。比如在 ‘searching’ 状态下，用户按 ESC 不会清空输入框（因为没定义 ESC 事件），但点击「重试」就自然跳转——模型本身就在约束行为边界。
别用模型套用户，要让模型贴着用户走
某电商 App 曾上线过「滑动删除订单」功能，手势流畅、动效丝滑。结果客服电话暴增：老人用户反复滑不动，以为手机坏了；年轻用户则误触删单，又找不到撤销入口。后来改成底部固定「删除」文字按钮+二次确认弹窗，投诉降了七成。
这不是交互退化，而是模型切换：从「手势直觉模型」回归到「显式操作模型」。前者依赖肌肉记忆和屏幕反馈精度，后者依赖认知确定性和容错空间。没有优劣，只有匹配度。就像微信聊天框长按录音、点击加号展开工具栏——同一界面里混用了两种模型，因为语音输入需要快速启动，而图片发送需要明确选择。
交互模型不是贴在墙上的方法论海报，它活在用户皱眉的0.3秒里，藏在你删掉的第三行冗余代码中，也卡在那个被你注释掉的 else 分支里。