反馈应出现在操作发生处
别名: 操作点反馈 · action-effect coupling · local confirmation
概念解释
双击一张照片，红心从照片中间炸开，人会把「已喜欢」算在刚才那一下上。同一动作若只在导航栏闪一句「已收藏」，因果就松了——时间对得上，位置对不上。操作点反馈（co-located feedback）要求可见结果长在动作发生的那个坐标上：被点的心、被提交的按钮、被拖动的滑块本身。
它管的是归因，不是「消息够不够显眼」。一条又大又红的横幅如果长在别的地方，仍然可能没被算进这次操作。
机制
动作和效应在大脑里按共同编码绑在一起：效应出现在动作的地点，才会被登记为这次动作的结果。时间接近只能完成一半绑定；地点拆开之后，效应会被当成系统自己冒出来的事件，或者干脆不当一回事。于是出现典型的二次点击——按钮其实已经提交，人因为在按钮上看不到变化，又按了一次。
控件自己的状态变化（按下凹陷、数字步进、开关位移）是成本最低的共位，因为它不另占一层。另起一条 toast、一条横幅，等于把效应从动作地点搬走。
怎么研究
比较同一操作的三种效应位置：控件内部、控件紧邻、远离的全局条。不要问「你看见提示了吗」，问「刚才那一下做成了没有」以及是否发生重试。
自变量：效应与接触点的距离、效应是否改写控件自身、持续时间。 因变量：无提示条件下的结果判断正确率、重复点击次数、从按下到停止等待的时间。
适合用真实表单和真实列表，而不是孤立按钮；连续任务里人更不会主动去远处找证据。
边界
动作的结果根本不在这个控件上（「支付已受理」要去订单列表核对）时，共位只能给一枚本地回执，真正的结果仍要在结果所在地出现。全页跳转本身就是最大的位置变化，落地页的标题变化已经在承担确认，再在旧页弹一条已无意义。屏幕阅读器不使用坐标，共位要改写成控件状态或焦点处的语音。多人协作画布上，别人的操作没有本地接触点，共位原则对「谁做的」帮不上忙，得靠作者标记。
怎么落地
- 能改控件自身就改自身：开关滑过去、步进器数字跳、喜欢的图标填实。不要把这些成功态只写到别处。
- 控件装不下完整结果时，在它旁边出一枚不抢行的本地回执，再链到结果页。
- 会触发提交的按钮，在请求期间就地进入进行中，避免空白等待被理解成没按上。
- 验证：关掉网络或故意延迟，看人会不会在按钮上反复点。反复点说明成功信号没长在动作地点。