用户点击“保存”后没有看到变化，可能再点一次，也可能刷新页面。增加一个转圈动画能缓解部分疑惑，但还不够：正在处理什么、何时算成功、失败后能否重试、网络断开后结果是否确定，都需要在设计中回答。按钮反馈是一组状态及其转换规则，不只是悬停时换一种颜色。
本文关注点击后的反馈。想了解按钮种类和视觉层级，可以先阅读常见按钮类型；这里以“保存表单”为主线，把加载、成功、错误和恢复设计完整。
先区分五种状态，避免给出错误承诺
可操作：按钮名称说明动作与结果。使用“保存修改”“提交申请”等具体表达，让用户理解点击的影响。若有不可撤回的后果，应该在动作前说明，不能等成功后才告知。
处理中：表示界面正在执行操作或等待结果。它不自动证明服务器已经收到请求，更不代表业务完成。短操作可以在按钮内显示“正在保存”，较长任务则需要在任务区域说明当前进展以及能否离开。
成功：在得到足以确认成功的结果后出现，明确保存了什么。只把按钮变绿，用户可能无法判断变化含义；可以同时显示“修改已保存”，必要时提供查看记录或继续下一步的入口。
失败：已明确无法完成当前动作，需要说明问题、保留可恢复内容，并给出合适的后续操作。字段错误引导用户修正字段，权限问题引导申请权限，网络问题才可能适合重试。
结果未知：连接中断或超时后，服务端可能已经完成操作。涉及付款、下单、提交申请等任务时，应先确认结果或提供记录查询，避免一句“失败，请重试”诱发重复操作。
加载状态要保持位置稳定，解释等待的含义
点击后的反馈应及时出现，让用户确认动作已经触发。按钮文字变成“正在保存”时，尽量保持按钮宽度与布局稳定，避免旁边的操作突然移动。仅使用旋转图标时，也应有可识别的文字或辅助名称，不能让整个反馈依赖动画。
不要把所有按钮一律禁用。如果操作之间没有依赖，其他任务可以继续；如果必须等待当前结果，应说明原因。禁用当前提交按钮能够减少连续点击，但它不是防止重复数据的完整方案。网络重试、多个浏览器窗口和客户端异常，都需要服务端的配合处理。
等待较长时，补充真实可用的信息：任务名称、已完成步骤、是否可离开、返回后到哪里查看。只有能测量进度时才显示百分比；没有进度数据，可以使用不确定进度，并清楚说明仍在处理。不要让进度条先跑到接近完成，再长时间停住，却没有解释。
如果提供取消，说明取消的是本地等待还是服务端任务。停止等待并不一定能撤销已发出的申请，界面用词需要与研发实际能力一致。对于不能取消的任务，不要放一个只会关闭提示的“取消处理”按钮。
成功反馈要对应用户刚才完成的任务
保存少量设置，可以保留在原页面，展示“修改已保存”；提交需要审核的申请，则应区分“提交成功”和“审核通过”。这两者的业务状态不同。反馈里可包含申请编号、后续流程或查看入口，但不要把尚未发生的结果写成确定承诺。
短暂消息适合补充轻量确认，关键结果则需要在页面中留下可查证的状态。用户可能正在看另一区域，几秒消失的提示不应成为唯一回执。若成功后跳转，目标页面应让用户看出刚才的动作已经完成，而不是突然回到没有说明的列表。
成功也不一定必须使用绿色。文字、图标与界面状态共同表达，才能适应色觉差异和不同主题。强调效果应与任务重要性匹配，不必让每次轻量保存都弹出需要再次确认的对话框。
失败反馈先帮助恢复，再考虑语气
“操作失败”“发生错误”只描述了结果，没有告诉用户下一步。可操作的错误提示至少回答三件事：哪里出了问题，哪些内容仍然保留，用户能够怎么处理。不能确定原因时不要编造原因，可以说明当前无法完成并提供检查或稍后重试的路径。
表单字段错误应靠近对应字段，同时在长表单顶部汇总问题。汇总与字段文案保持一致，点击后能够定位。把所有错误放进一个悬浮提示，会迫使用户记住信息再寻找位置。GOV.UK 的错误汇总组件展示了这类定位式反馈的做法。
服务异常时，保留用户输入并说明重试是否安全。上传失败可让用户重传失败文件，不一定需要把整个表单清空；权限不足时，重复点击通常不会解决问题，应提供申请权限或返回的操作。恢复按钮的名称也应描述动作，避免所有情况都使用“确定”。
错误解除后及时更新提示，但不要一边输入就反复打断用户。新错误和旧错误应对应当前数据，避免修正完成后红字仍然存在，或者未经再次校验就显示成功。
用结果未知状态，处理最容易漏掉的分支
设想用户提交申请后断网。服务器可能没有收到，也可能已生成记录但响应未返回。设计稿应为这一分支安排“正在确认结果”或可查询的任务状态，而不是直接回到最初的提交按钮。
团队需要一起确定：是否能按请求或业务编号查结果；自动重试是否安全；多久后改为人工处理；用户离开页面后如何再次查看。接口是否支持幂等，由研发确认，设计不要仅凭按钮禁用状态推断业务一定不会重复。
并非所有操作都需要同样复杂的流程。刷新搜索结果与创建付款记录的风险不同，可以采用不同恢复方式。关键是先评估重复动作的影响，再选择反馈强度，不能把同一套“加载—成功—失败”模板机械用于全部功能。
同一页面的多次操作，别让旧结果覆盖新状态
用户先保存一次，又修改内容并再次保存，两个请求的返回顺序可能与发出顺序不同。界面需要对应到各自的数据版本，不能让较早的成功响应把后来尚未保存的修改标记为“全部已保存”。设计时可以用修改中、保存中、已保存的整体状态说明这层关系，具体响应关联交给研发实现。
自动保存与手动保存同时存在时，也要明确各自覆盖范围。用户看到“已保存”后应知道保存的是当前哪些内容，附件或其他子任务尚在处理中时，需要保留对应状态，避免一个总提示掩盖局部失败。
键盘、读屏和减弱动效也需要收到反馈
用户通过键盘触发按钮后，应仍然知道当前位置。不要在显示普通状态消息时随意移动焦点；需要用户立即处理的对话框则应有完整的焦点管理和关闭路径。焦点是否移动，取决于任务变化，而不是为了让提示“更明显”。
页面局部更新时，读屏软件不一定自动读出视觉上新增的信息。研发可按消息性质采用适当的语义或实时区域；设计说明应标出哪些内容需要被获知、是否打断当前操作。W3C 的状态消息要求关注的正是这类不改变上下文的动态反馈。
动画不应成为唯一信息源。用户关闭或减弱动画后，仍要能看到“正在保存”等状态；错误不能只靠按钮抖动表达，成功也不能只靠一闪而过的粒子效果。W3C 的表单通知教程还提供了成功、错误及局部反馈的组织方式，可用于设计与开发共同检查。
按钮反馈的联调验收清单
- 点击、键盘激活和触屏操作都能及时得到反馈，按钮不会无故跳位。
- 处理中、成功、失败、无结果和结果未知各自有清楚的进入条件。
- 连续操作不会产生重复业务记录，前后端处理责任已经确认。
- 失败后保留必要内容，重试、修正或查询的入口与真实能力一致。
- 消息出现和消失时机合理，关键回执有持续可查看的位置。
- 焦点路径稳定，信息不只依靠颜色或动画，读屏用户能感知重要状态。
可以在Pixso中把按钮状态放进同一个组件练习，再用原型连接保存成功、字段错误和网络中断三条路径。与研发评审时逐条说明状态切换条件，测试人员也能直接据此设计用例。按钮反馈是否清楚，最终要在这些真实分支中判断。
