我们常说「用户错误是产品设计的失败」，但如果把「错误」看成用户与系统期望的碰撞，可能更有洞察力。

想象一下你打开一个新app，点了「保存」却弹出「文件已存在」——你不记得之前保存过，系统却在告警。这里的痛点不在技术，而在用户的期望被系统打破。根据 Nielsen 的可用性四大原则，系统的可预测性是关键；当预测失真，用户就会陷入「失控」状态，情绪随即沦为焦躁。

我在一次项目中，负责一款任务管理工具的重构。上线后，用户量暴涨，却出现了 23% 的「数据丢失」投诉。调查显示，70% 的报错来自于用户误认为「完成」与「归档」是同一操作。那时我意识到：若把「完成」按钮放在任务列表右侧，而「归档」按钮置于上方菜单，系统的行为与用户心理的映射会更一致。

另一例子来自微信支付。当你点击「付款」后，界面直接弹出扫码窗口，用户期望能先确认金额。此处的「即时扫码」与用户的「确认后再支付」期望相悖，导致 15% 的付款失败率。解决方案是先显示一条弹窗「确认金额」，再让用户扫描。这样既满足用户的确认需求，又保持流程流畅。

如果把用户错误归因于「人失误」，会让团队忽略系统设计的责任。相反，将错误视为系统与用户期望的失配，能让产品经理把焦点放在「信息透明度」和「操作一致性」上。

你是否在最近的产品迭代中，遇到过因为期望错位导致的使用痛点？不妨在用户测试前，先问自己：用户会如何理解「X」？系统是否真的按这种方式回应？这或许能让你在「用户沮丧」之前，先把误解消除。

结尾：当我们把「错误」当作系统的反思时，或许可以说，真正的「用户错误」其实是系统没有说好「先说后做」的故事。你准备好重新书写这段对话了吗？