Wizard of Oz 測試 Wizard of Oz Testing

什麼時候該用它？

你有一個很酷的產品點子，但要把它真的做出來需要 3 個月和 500 萬。在砸錢之前，Wizard of Oz 測試讓你用「人工模擬」代替「技術實作」，先確認使用者是不是真的想要這東西。

• AI/ML 功能驗證前：演算法還沒訓練好，但想先確認推薦結果是否符合使用者期待
• 自動化流程測試：想做一套自動客服，但不確定使用者會問什麼、回答品質要多高才夠
• 新互動模式探索：語音操控、手勢辨識、聊天機器人 — 技術還不成熟但想先驗證需求
• 資源極度有限：新創早期只有 2-3 個人，沒有工程資源但需要證明概念給投資人看
• 市場需求不確定：技術上做得到，但不確定有沒有人願意付錢用
• 複雜後端邏輯的前期驗證：定價引擎、配對演算法、風控模型 — 先用人腦跑，確認邏輯對了再寫程式

框架結構

Wizard of Oz 測試的核心概念來自《綠野仙蹤》— 那個藏在布幕後面操控一切的「巫師」。使用者以為自己在跟系統互動，其實背後是真人在操作。

前台介面（使用者看到的）

使用者看到的是一個「看起來像真產品」的介面：

• 可以是真的 App 畫面（用 Figma 做的高擬真原型）
• 可以是網頁表單
• 可以是聊天視窗
• 甚至可以是 Email

重點：介面要夠像真的，讓使用者產生「我正在用一個產品」的感覺，而不是「我正在參加實驗」。

後台操作（巫師做的事）

一個或多個「巫師」（通常是團隊成員）在幕後即時回應使用者的操作：

• 使用者下了搜尋，巫師手動挑結果推回去
• 使用者問了問題，巫師手動寫答案
• 使用者上傳了照片，巫師手動分類後回傳結果

關鍵要素：

• 速度：回應時間要合理，不能讓使用者等太久而起疑
• 一致性：多個巫師之間要有 SOP，確保品質一致
• 紀錄：每一次互動都要記錄下來，作為後續分析的數據

觀察與紀錄

測試的真正價值在於觀察：

• 使用者的行為路徑跟你預期的一樣嗎？
• 使用者對結果滿意嗎？會不會反覆操作？
• 哪些操作頻率最高？這就是你的核心功能
• 使用者有沒有做出你沒預期到的事？

來源與歷史

• 1984：Jeff Kelley 在博士論文中首次正式描述 Wizard of Oz 方法，用於研究自然語言介面的可用性
• 1993：Nils Dahlbäck 等人在 HCI 研究中系統化 Wizard of Oz 的實驗設計方法論，使其成為人機互動研究的標準工具
• 2001：IDEO 將 Wizard of Oz 納入 Design Thinking 工具箱，從學術走入商業實務
• 2011：Eric Ries《精益創業》推廣後，Wizard of Oz 成為 MVP 驗證的經典手法之一
• 2020s：AI 產品爆發，Wizard of Oz 再度翻紅 — 用人工標註模擬 AI 回應，驗證 AI 產品概念

真實案例：Zappos 如何用 Wizard of Oz 驗證線上賣鞋

Zappos 創辦人 Nick Swinmurn 在 1999 年做了一個經典的 Wizard of Oz 測試：

1. 前台：架了一個簡單的網站，放上鞋子的照片和價格
2. 後台（巫師）：有人下單後，Swinmurn 自己跑去附近的鞋店用原價買那雙鞋，然後寄給客人
3. 觀察：真的有人願意在網路上買鞋，而且退貨率沒有想像中那麼高

他沒有建倉庫、沒有跟品牌簽經銷合約、沒有物流系統。但他驗證了最關鍵的假設：人們願意在看不到實體的情況下花錢買鞋。

數據成果：這個驗證讓 Swinmurn 拿到了第一輪融資。Zappos 後來在 2009 年被 Amazon 以 12 億美元收購。如果當初直接蓋倉庫和系統，可能燒完資金就倒了。

另一個案例是 IBM 在 1984 年用 Wizard of Oz 測試語音聽寫系統。使用者對著麥克風說話，螢幕上「即時」出現文字 — 其實背後是打字員在高速輸入。這個測試發現使用者說話的方式跟寫字完全不同，幫助 IBM 修正了整個語音辨識的產品方向，節省了預估 1,800 萬美元的開發成本。

使用步驟

Step 1：定義核心假設

你要驗證什麼？把最關鍵的 1-2 個假設寫清楚。例如：「使用者願意透過聊天機器人完成退貨流程」或「個人化推薦能讓加購率提升 20%」。

Step 2：設計前台介面

做一個「看起來像真產品」的介面。不需要完美，但要夠真實。用 Figma、Webflow、或簡單的 HTML 頁面都行。重點是使用者不會意識到背後是人工操作。

Step 3：建立巫師 SOP

寫清楚巫師的操作流程：收到什麼輸入、要在幾秒內回應、回應的格式和品質標準是什麼。如果有多個巫師，要有統一的判斷標準。

Step 4：執行測試

找 10-20 個目標使用者來實際操作。觀察他們的行為、記錄互動內容、追蹤關鍵指標（完成率、滿意度、再次使用意願）。

Step 5：分析結果並決策

整理觀察紀錄，回答最初的假設。如果驗證成功，你現在有了真實數據來支撐開發決策。如果失敗，你省下了幾個月的開發時間。

這樣做 vs 避免這些

這樣做

• 把巫師的回應時間控制在合理範圍 — 如果你模擬的是 AI 即時回應，不能讓使用者等 30 秒
• 測試結束後 debrief — 告訴使用者真相，收集他們「知道是人工後」的反應（這本身也是有價值的數據）
• 用真實的目標用戶，不要找同事當受試者 — 同事會不自覺地配合你
• 把巫師操作的每一步都記錄下來，這些紀錄就是未來寫需求規格的素材

避免這些

• 不要讓前台介面太粗糙 — 使用者如果覺得是假的，行為就不真實了
• 不要測太久 — 1-2 週足夠，拖太久只會浪費巫師的人力
• 不要同時驗證太多假設 — 一次測一個核心假設，結果才乾淨
• 不要把 Wizard of Oz 當成長期方案 — 它是驗證工具，不是產品架構