起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識針對 0-1 新產品的可用性測試方法：The Wizard of Oz Test！
大家知道什么是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 協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論，等你發揮！
