操作必有反馈 | 设计交互 | 做产品

操作必有反馈

用户点了一下，屏幕上必须有东西变化。没有变化，他的默认假设是没点上。

你会遇到的现象

• 用户连点三次提交，后台收到三条重复数据

• 点了之后过两秒才有反应，中间那两秒他以为坏了

• 操作成功了，但页面上看不出哪里变了

三层反馈

层什么时候出现它回答的问题

即时反馈 手指抬起的瞬间 我点上了吗。按钮变色、变成加载态、涟漪效果

结果反馈 操作完成时 成功了还是失败了。轻提示、状态标签、错误信息

状态反馈 操作完成之后一直存在 现在是什么状态。列表里的数据真的变了、标记变了

第三层最容易被漏。弹了个「保存成功」但列表还是旧数据，用户会怀疑到底存没存上，然后刷新一遍页面确认。

按耗时选形式

0.1 秒以内 直接给结果，不用加载态 加了反而闪一下，更难受

0.1 到 1 秒 按钮变加载态就够 局部反馈，别遮住整页

超过 1 秒 骨架屏或进度条，让他知道还要多久 超过 10 秒要允许后台运行，别把人困在这一页

不确定要多久的操作，进度条至少要动。一个卡住不动的进度条比没有进度条更让人焦虑。

乐观更新

有一类操作可以不等服务器：点赞、收藏、勾选待办。界面先按成功处理，请求失败了再退回来并提示。

• **适合用的：轻量、高频、失败了退回来代价很小的操作。**点赞点错了退回去，用户不会有损失。

• **不适合用的：涉及钱、不可逆、或者结果需要服务端计算的操作。**下单、支付、删除，都要等真实结果。

• **失败时必须退回并说明。**悄悄退回去比不做乐观更新更糟——用户以为成功了，过一会儿发现没有。

给 AI 的话

复制 CLAUDE.md · 反馈规则

## 操作反馈

任何会触发请求的操作，都要实现三层反馈：
1. 即时：点击瞬间按钮进入 loading 态并禁用，防止重复提交。
2. 结果：成功或失败都要有明确提示。失败的提示要包含
 原因和下一步（见提示语规范）。
3. 状态：操作完成后，页面上相关的数据必须同步更新，
 不能只弹提示不刷新列表。

按耗时选形式：
- 1s 骨架屏或进度条
- > 10s 允许后台运行，给出可离开的入口

乐观更新只用于点赞、收藏、勾选这类轻操作，
且失败时必须回滚并提示。涉及金额、删除、
不可逆的操作一律等待服务端结果。

接着看

四态齐全 四态管的是页面进来时的数据，反馈管的是用户点击之后的结果。两者要用同一套视觉语言。

提示的五种形式 结果反馈用哪一种形式，取决于这件事的强度。成功提示用轻提示，失败要看影响面。

可撤销优于确认 结果反馈里带一个撤销按钮，往往比操作前弹窗确认体验更好。