D1.01.2Input acknowledgement设计研究
无法立即给出结果时先确认输入已被接收
别名: 接收确认 · acknowledgement feedback · 已收到
概念解释
输入确认（input acknowledgement）是在最终结果尚不可得时，系统先让用户知道输入已到达并被识别的反馈。它说的是「收到」，不是「办成了」：发送按钮被锁定、文件进入上传队列、订单显示处理中，都是接收确认；把它写成成功或完成会错误地承诺尚未发生的结果。异步系统把这两个状态分开，用户才能停止重复输入，同时正确期待后续等待。
机制
等待中最稀缺的是对系统状态的可见证据。用户无法从静默界面区分点击未命中、网络未送达、服务器排队和任务正在执行，于是会用再次点击、返回重试或放弃来降低不确定性。接收确认把问题从「系统有没有听到」缩小为「什么时候完成」，并把注意从触发控件迁移到后续状态。它必须足够快且与具体输入绑定；泛泛的全局提示不能证明刚才那一次操作被接收。
怎么研究
可将同一耗时任务分别设计为无反馈、立即接收确认、接收确认加过程状态，比较重复提交率、等待时的主观确定性、错误恢复和对完成时刻的判断。关键变量包括确认出现延迟、确认与触发点的距离、文案是否区分接收与完成、任务实际时长及失败率。测试不能只让用户等待顺利完成的样本；断网、排队、取消和服务端拒绝才能检验确认是否被误解为成功。
边界
接收确认不替代真正的结果，也不能成为掩盖失败的永久「处理中」。对金融扣款、删除、发布等有后果操作，确认必须能通向可验证的最终状态；若输入尚未离开设备或只被本地缓存，也应如实表述。对于即时、可逆且结果已在操作点显现的交互，再增加一层通知反而会冗余并打断节奏。
怎么落地
- 为每个可能超过短暂等待的提交定义 received、processing、completed 与 failed 状态，不以一个「成功」覆盖全程。
- 在触发控件或对应对象附近立刻显示已接收的证据，并防止同一请求在未明确允许时被再次提交。
- 用可核对的对象状态、队列位置或任务记录承接处理中状态；失败时保留原输入并给出下一步。
- 在弱网、后台恢复和重复点击测试中检查：用户能否说清系统已经收到了什么、尚未完成什么。