在《绿野仙踪》中，绿灯管的魔法并非真正的魔法，而是幕后的工作人员在灯光下操作的伪装。正如产品经理们在早期研发时往往把焦点放在高保真原型上，忽略了真正决定产品命运的「心智模型」。

所谓心智模型（Mental Model）是用户脑中对系统行为的隐形蓝图。它决定了我们在使用产品时的期望、思考路径和行为决策。若产品与用户的心智模型不匹配，即使界面再华丽，也会被用「功能不对用」所抵制。低保真原型正是用来检验这些蓝图的试金石。

为什么低保真？因为它成本低、迭代快，能让我们把重点放在「想法对不对」，而不是「实现对不对」。举个例子：2011 年的 Airbnb 当时只用一张简单的照片加上两行文字，后台其实是由人手动回复邮件的「Wizard of Oz」实验。结果显示，用户对房源的期待与他们的心智模型高度契合，随后才正式投入开发。再比如 Dropbox 在 2012 年早期，团队通过模拟文件同步的行为（用户上传文件后人工同步到服务器）验证了「同步即刻可见」这一核心假设，最终才投入真正的后端代码。

要进行 Wizard of Oz 测试，先明确你想验证的核心假设：
① 用户是否认为「X」能做到「Y」；
② 在什么场景下「Z」需要触发；
③ 用户在遇到问题时的心理预期。然后用纸、白板或 Figma 制作最简交互流程，背后放一个人或一台脚本来「伪装」系统反应。招募真实用户，让他们完成任务，记录下他们的言行、提问和情绪波动。你会发现，用户的第一句话往往最能揭示他们的心智模型。

工具不一定高大上。只要你能让参与者相信你在「真正」操作系统，就可以用一张纸做出 「点击即完成」。若想要更系统化，可以使用 InVision 或 Framer 这类原型工具，配合 Zapier 或 Integromat 让后台自动返回结果。记住，Wizard of Oz 的核心是「先验证思维，再验证技术」。

优点显而易见：
① 费用极低，几天就能完成；
② 能提前发现心智模型偏差，避免后期昂贵改造；
③ 让团队聚焦在用户真正需要的功能上。缺点则是：如果未能精准模拟真实交互，可能导致数据失真；如果过度依赖，忽略后端实现的可行性，也会产生「先做错再修」的成本。

你是否在过去的项目里，只因为「交互看起来好看」就忽略了心智模型的验证？在下一次迭代前，先把这套 Wizard of Oz 的流程写进需求评审，或许能让你的产品走得更稳、更快。