在产品管理的日常里，用户故事往往被当作填表练习。我们习惯于把它写成“作为某个角色，我想要某个功能，以便获得某个收益”。这句套话好像很完整，但它忽略了最核心的东西：用户到底想怎么用系统？从心智模型（Mental Model）的视角来看，需求的真正价值在于“怎么使用”，而不是“要做什么”。

心智模型是用户在脑中对世界的抽象框架，它决定了我们如何预测行为、做出决策。比如，当我打开Slack时，我的心智模型是“聊天就是即时发送文字、文件或表情，然后收发同伴的回复”。如果我们的用户故事只说“提供文件上传功能”，我们就没有触及用户心中的“怎么发送文件”。这就像给人写了一份购物清单，却忘记了说明“要怎么付款”。

举个经典案例：当Apple推出iPhone 12的‘无卡槽’设计时，用户故事是“让用户不必再插卡”。但真正的痛点来自用户对“卡槽”这个概念的心智模型——它代表了物理的插拔、SIM卡的更换。Apple的故事如果写成“让用户能够直接在手机内管理网络配置”，就更贴合用户在脑中对网络管理的预期。相对地，微软Teams 在推出“频道”概念时，用户故事写作强调“团队成员可以在同一个频道内讨论项目”，正是对用户‘团队协作’的心智模型的回应。

从研究角度来看，Nielsen Norman Group 2023 年的《用户体验调查》指出，80% 的用户在首次使用一个功能时会在 30 秒内放弃，如果他们找不到符合自己预期的交互方式。换句话说，用户故事若不围绕“怎么使用”构建，就等于在用户的认知地图里投下了一片“未知”雾。心理学家约翰·霍兰德在《认知负荷理论》一书中指出，过多的认知负担会导致决策疲劳，最终用户放弃。简而言之，需求如果只聚焦功能而忽略使用场景，等于给用户投下了太多认知压力。

那如何把心智模型真正融入用户故事？我建议三步：① 先做“使用者旅程图”，标出关键交互点；② 用“用户视角的动词”替代技术术语，比如“共享”而不是“上传”或“保存”；③ 在验收标准中加入“从用户的心智模型出发的可验证指标”，例如“用户能在三步内完成文件共享”。这套方法与“敏捷”本身的迭代精神不谋而合，也更容易让跨职能团队保持同一认知基准。

回到最初的思考：如果我们把需求写成“让用户在聊天窗口一键上传图片并自动生成缩略图”，那就已经把心智模型的核心——“图片即刻可见、无缝分享”——写进去了。如此一来，产品经理、设计师、开发者都能在同一张图上快速对齐，避免了“实现功能不匹配用户期待”的尴尬。

在你下次拆分需求时，先问自己：用户到底想怎样做？如果答案里没有“怎么使用”，那可能是我们还没有真正理解他们的心智模型。现在，你准备好把用户故事写得像用户的思考路径了吗？