在国外读过设计类课程的同学，该当都或多或少都打仗过一种产品设计测试方法：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 协议。
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
