帘子后面是个人：UX 中的绿野仙踪法
在童话《绿野仙踪》里，桃乐丝跋山涉水去见传说中无所不能的奥兹国大巫师。见面时，巫师呈现为一个巨大、威严、声如洪钟的形象。直到她的小狗扯开帘子——大家才发现，所谓大巫师不过是个普通老头，在后面操纵机关假装强大。
这个”帘子背后的反转”，就是一种在 UX 领域安静用了 50 年、在 AI 时代重新变得关键的研究方法——绿野仙踪法（Wizard of Oz Method）。
这到底是什么
绿野仙踪法的做法很简单：让用户以为自己在与一个完全自动化的系统互动，但其实背后是一个真人在实时生成回复。用户以为在和聊天机器人、语音助手、推荐引擎对话，实际上是你的同事在键盘后面打字。
这么做的目的也很简单：在没真正造出系统之前，先测试这个系统带来的体验是否成立。
为什么现在特别有用
很多现代产品都有一个共同的麻烦：它们开发成本高、风险大，而且要等底层技术真正做出来以后，才能知道体验好不好。
- 对话式 UI
- LLM 驱动的推荐系统
- 语音助手
- 实时检索类界面
如果做出来体验不好，几个月的工程就白烧了。绿野仙踪法把这个流程反过来：先验证交互体验，再决定要不要投入真正的工程建设。
和童话的对应关系
| 童话里 | 方法里 |
|---|---|
| 看似强大的”奥兹巫师” | 看似智能的”自动化系统” |
| 帘子后操纵机关的老头 | 手动写回复的真人操作者 |
| 桃乐丝相信巫师是真的 | 测试用户相信系统是真的 |
这个名字是 1983 年研究员 Jeff Kelley 在约翰·霍普金斯大学研究自然语言界面时起的。方法本身更早：1973 年，Don Norman 和 Allen Munro 就用它测试过自动化机场终端。
五个步骤
- 定义测试目标——要验证的是一个功能、一个流程，还是整体体验？
- 搭一个”假”原型——Figma 原型、脚本、甚至用现成工具代替新功能都可以。
- 确定操作者如何回复——预设固定回复、现场即兴、或者两者混合。
- 培训操作者 + 预演一次——找同事做一次试运行，通常能发现你事先没想到的漏洞。
- 跑测试、收数据、迭代。
对话式 UI 一般推荐用”混合模式”：常见回复准备好模板，遇到意外情况操作者临场发挥。
最经典的案例：Zappos
用绿野仙踪法做出的最有名的产品，其实根本不是软件——是美国的在线鞋店 Zappos。
创始人 Nick Swinmurn 在砸钱做仓库、库存系统、物流自动化之前，先做了一个很简单的网站，上面挂着鞋的图片。用户一下单，他就自己跑到附近的鞋店买一双，然后寄给客户。网站看起来像是一家电商公司，帘子后面其实就是他一个人开着车到处买鞋。
他不是在测物流，他是在测一个问题：人们到底会不会在网上买鞋？
等这个问题答案是”会”，后面那些重投资才值得做。
要不要告诉用户真相？
通常不告诉。因为一旦用户知道对面是真人，他们会下意识地”配合”，给出比真实系统宽容得多的反应，数据就失真了。
如果用户直接问：“这是人在回复吗？“——让他们继续当作是真系统在用就行。如果研究涉及比较明显的”欺骗”，结束后简单说明情况，并给用户撤回数据的权利。
收益与代价
你得到的：
- 低成本、快速的概念验证
- 真实交互数据，不是焦点小组的嘴炮
- 在大笔工程投入前排雷，尤其对 AI 产品特别有用
你付出的：
- 操作者可能出错，而真正的系统不会那么出错
- 规模小，不适合大样本量
- 做得粗糙，用户事后会觉得被耍了
一句话结论
在造巫师之前，先在帘子后面放一个人。
如果一个聪明人在后面手动操作都撑不起好体验，那么一个半成品模型加上不稳定的 API 更不可能撑起来。每一个昂贵的、AI 驱动的产品想法，都值得在动工之前先跑一次绿野仙踪测试——而不是等到上线之后才发现问题。