大家知道什么是The Wizard of Oz Test （绿野仙踪测试法）吗？认识的话，有了解有多少呢？一起来看看下面这篇文章的相关内容吗？

在国外读过设计类课程的同学，应该都或多或少都接触过一种产品设计测试方法：The Wizard of Oz Test（绿野仙踪测试法）。但为什么国内似乎很少提及这个测试方法和理念？是地缘差异还是观念的不同？

本文就来介绍一下这个曾在国外流行一时的绿野仙踪测试方法 The Wizard of Oz Test。

一、The Wizard of Oz Test是什么？

“The Wizard of Oz” 是一个童话故事《绿野仙踪》，故事里有个看上去“很强大的”大魔法师，能够震慑和控制住普通民众，但其实法师幕后只是一个普通人在操纵机器来吓唬人。“The Wizard of Oz Test” 直译过来即为 “绿野仙踪测试”，它借用的就是这个大魔法师的隐喻。

这个测试方法的起源可以追溯到 1975 年，当时的设计研究者唐·诺曼（Donald Norman，《设计心理学》系列的作者) ，为测试者安排了一项任务：使用一款新机器“旅行自助服务机”。

测试者在使用这个机器时，并不知道这款机器的幕后其实有一个工作人员在实时响应他们的每一次点击操作、提供给他们想要的各种资料和信息。整个测试过程很像现在的一句玩笑话：“有多少智能，就有多少人工”。

唐·诺曼希望通过这项研究，帮助机器设计者收集和了解用户心目中的“旅行自助服务机”，应该提供哪些服务功能。

类似的还有 1984 年 IBM 对于他们的新产品“监听打字机” 的测试过程：用户在产品交互界面端说话，产品系统背后的工作人员根据用户所说的内容打字，文字内容会反馈到用户看到界面上：

因此在 The Wizard of Oz test（绿野仙踪测试）的测试过程中：- 对于控制测试的研究人员和产品设计师来说，就是要当场快速响应并给出反馈，以实现和了解用户的诉求，充当“智能”背后的“人工”。

– 对于测试的用户来说，用户的所有需求几乎都可以被满足。整个测试对于用户来说也很像是一场“开放式游戏”，用户可以按照自己的想法和需要来选择或编写游戏故事的发展方向。

二、适用于哪些设计场景？

理解了上述概念，你会发现：The Wizard of Oz test（绿野仙踪测试） 其实是用来探寻用户的本质需求，并以此确定产品应该提供哪些功能和服务。这种测试方法更适用于对新产品或新功能的猜想验证和功能探索，因而侧重点并不在于检测产品已有功能的易用性。

这种特性也使得这个测试工具更适用于从 0 开始的新产品的设计起步阶段，产品的设计研发团队和用户一起通过测试来进行共创，以发现产品应该具备的形态和功能。

另外，The Wizard of Otest（绿野仙踪测试）也并非是单一形式的设计工具，而是 一系列设计工具和方法的统称，它们的共性功能和特征是：在一个界面/产品原型 demo 中，通过人工响应的方式来快速、暂时的满足和反馈测试者的需求。

比如一个最初级、简易的实践方式就是：你可以准备很多写着产品功能的卡片，并将这些功能卡片贴在几张大白纸上，做为产品的原型的一级、二级界面。用户可以自己选择保留、更换或去除掉其中的一些功能，如果用户想要的卡片上没有的功能，就当场立即做一张功能卡片补充上，以此来判断用户对于产品功能定义和需求。

在国外创业潮时期或在高校做概念设计时，The Wizard of Oz test（绿野仙踪测试）都是很好的测试方式。用户测试和产品可用性测试的方法有很多种，但这些方法之间并不存在绝对的优劣，只有满足你的测试目的的工具，才是值得用的工具。

专栏作家

元尧，微信公众号：长弓小子，人人都是产品经理专栏作家。一线互联网大厂B端体验设计师，清华大学美术学院本硕连读。曾负责国内最大开源组件库Ant Design组件的设计和运营工作，目前负责国际业务线B端产品体验设计和组件库的搭建工作。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。