H5.06.2notification action feedback设计研究
操作结果需在通知上反馈
别名: 通知操作反馈 · 栏内结果 · action acknowledgement
概念解释
人在卡片上点了动作之后，结果必须写回这张卡片：变成「已归档」、收成一条短确认、或明确「没发出去」。卡片若保持点之前的样子，人无法知道指令有没有被接住，接下来不是再点一次，就是打开应用去核对——快捷动作省下的切换被要了回来。
这条只谈动作之后的承认。它不规定哪些动作该出现在通知上，也不谈破坏性动作该不该放。
机制
通知栏不是应用内页面，没有持久的对象视图给人对照。唯一还在场的表面就是这张卡。反馈必须落在卡上，否则状态在别处更新、人的眼睛还在栏里。网络是异步的：点下去到服务器确认有缝。缝里若无进行中标记，人会当成没点到。缝的另一头若失败却无报错，人会当成已经做完。
反馈还要能被扫视读到，不能只靠消失。卡瞬间拿走，人以为自己划掉了而不是完成了。先改文案或出短暂确认，再决定是否移除，闭合才可感知。
怎么研究
让人在卡片上执行动作，操纵反馈形态：无变化、立刻消失、进行中再成功/失败、成功文案停留。问「现在是什么状态」，并看有没有重复提交或进应用核对。
自变量：反馈形态、延迟时间、失败是否可重试。 因变量：状态判断正确率、重复点击、不必要的应用打开、未完成却以为完成的比例。
实验室网速快，测不到「点了没反应」。要插入明确延迟和失败。不要用任务完成时长当唯一指标——人可以很快点完同时完全不知道结果。
边界
系统会在动作成功后立刻撤卡（部分桌面环境），此时反馈要抢在撤卡前出现，或改用一条替换卡。辅助技术必须能读到新状态，只改颜色不够。批量摘要上对其中一个成员动手，反馈应落到该成员，而不是整卡闪一下。离线队列要区分「已排队」和「已完成」，两者都是合法反馈，混用会造成对账错误。
怎么落地
- 点下后立刻进入进行中，禁止在无反馈窗口里再点同一动作。
- 成功把卡片改写成结果（已回复、已归档），停留到人扫一眼或短超时后再移除。
- 失败留在原卡上，说明原因和下一步（重试、去应用），不要静默恢复成未操作。
- 验证：把网络拖慢并失败一次。人应能说出「正在发送」和「没发出去」；若卡片看起来从未被点过，或人打开应用去确认，反馈就没落在通知上。