設計思考 Test 是什麼？它和一般測試有什麼不同？
設計思考 Test 是用原型進行測試，收集使用者回饋，再決定下一輪迭代方向的階段。重點是驗證假設，不是替設計找掌聲。
在品牌設計、產品介面或服務流程裡，Alice Wang 會把 Test 視為「降低錯誤投入」的關卡。越早讓使用者碰到原型，團隊越早知道哪些想法只是內部想像。
| 比較項目 | 設計思考 Test | 一般常見測試 |
|---|---|---|
| 目的 | 驗證原型與假設是否符合使用者情境 | 確認功能、品質或轉換表現 |
| 資料來源 | 使用者行為、語句、情緒與任務表現 | 錯誤紀錄、數據報表或問卷結果 |
| 下一步 | 保留、修改、重測或回到定義問題 | 修 bug、優化數據或調整設定 |
Test 階段的核心不是證明自己對，而是找出哪裡需要修正
好的設計思考測試，不是問「你喜歡嗎」，而是觀察使用者是否理解、是否卡住、是否願意繼續完成任務。使用者沉默、繞路、反覆詢問，往往比一句「看起來不錯」更有價值。
Test 在五步驟中的位置：同理、定義、發想、原型、測試
Test 接在 Prototype 之後，但它常常會把團隊帶回 Define 或 Prototype。前面用同理心地圖、使用者旅程、POV 與 HMW 找出問題，Test 則檢查這些判斷是否真的成立。
進入 Test 前要先確認什麼？
進入 Test 前，團隊至少要有清楚的 POV、HMW、可操作原型與測試目標。缺少任一項，測試容易變成聊天或主觀評分。
我不建議一有想法就急著找人測。若問題句模糊，受測者給的回饋也會分散，主管很難判斷結果是否足以支持下一步投入。
先把問題句寫清楚：POV 與 HMW
POV 用來描述「誰在什麼情境下遇到什麼需求」，HMW 則把問題轉成可發想、可測試的方向。
- POV 範例：第一次使用線上報名系統的家長，需要在手機上快速確認課程時間，因為他們通常是在通勤或午休空檔完成報名。
- HMW 範例：我們可以如何讓家長在 1 分鐘內確認課程資訊並完成下一步？
用 5W2H 檢查測試目標是否具體
| 面向 | 檢查問題 | 範例 |
|---|---|---|
| Who | 要找誰測？ | 近 3 個月內曾線上報名課程的家長 |
| What | 要測什麼假設？ | 使用者能否找到課程時間與費用 |
| Where | 在哪個情境測？ | 手機瀏覽器或遠端視訊 |
| How | 如何執行？ | 給任務、觀察操作、訪談追問 |
| How much | 成本與時間是否可控？ | 每位 20 至 30 分鐘，先測 3 至 5 位 |
確認原型夠用即可，不必做到完美
Test 階段需要的是能讓使用者理解情境並完成任務的原型，不一定是完整 UI。紙本流程、簡報頁、低擬真線框、可點擊原型都可以使用。
- 如果要測資訊架構，用低擬真原型即可。
- 如果要測視覺信任感，可提高品牌與版面細節。
- 如果要測服務流程，可用流程稿或角色扮演。
設計思考 Test 的 6 步驟流程
設計思考 Test 可分成 6 步驟：列假設、選對象、設任務、寫問題、做紀錄、整理洞察。每一步都要服務迭代決策。
Step 1：列出要驗證的假設
先列高風險假設，避免一次測太多。高風險通常代表如果判斷錯誤，後續設計、開發或品牌溝通成本會明顯增加。
- 價值假設：使用者是否真的需要這個解法？
- 理解假設：使用者是否看得懂內容與流程？
- 可行性假設：使用者是否能在現有情境完成任務？
Step 2：選擇測試對象
受測者應符合 Persona、使用情境與排除條件。找錯人測，結果看似順利，實際上只是測到不相關族群的偏好。
| 篩選欄位 | 應確認內容 |
|---|---|
| 目標族群 | 是否符合主要使用者輪廓 |
| 近期經驗 | 是否有相近任務或需求 |
| 使用情境 | 是否會在真實生活中遇到此流程 |
| 排除條件 | 是否為內部同仁、熟人或過度熟悉專案者 |
Step 3：設計測試任務
測試任務要像真實情境，不要像功能導覽。任務應描述目標，避免直接告訴使用者要按哪個按鈕。
任務範例：你想替小孩報名週六下午的設計課，請在這個頁面找到適合的課程，並完成報名前需要確認的資訊。
Step 4：撰寫訪談與追問問題
問題要開放、中立、可追問。比起問「這個設計清楚嗎」，更適合問「你剛剛看到這裡時，以為下一步要做什麼？」
- 你剛剛停下來時，在想什麼？
- 哪一個資訊讓你不確定？
- 如果這是你平常會遇到的情境，你會怎麼處理？
Step 5：記錄行為、語句與情緒反應
紀錄不能只寫結論。使用者說了什麼、做了什麼、在哪裡停頓，都是判斷設計思考 Test 結果的重要資料。
Step 6：整理洞察並決定下一輪迭代
整理時要把零散回饋轉成決策。我的做法是先分成「可直接修正」、「需要重測」、「可能回到定義問題」三類，避免會議只停在心得交換。
設計思考 Test 要找幾個人測？怎麼篩選？
初期原型測試可先找 3 至 5 位高度相關使用者。這不是統計抽樣，而是為了快速找出重複出現的理解問題與行為卡點。
初期原型測試可先找 3-5 位高度相關使用者
3 至 5 位適合早期質化測試，因為團隊要找的是明顯模式，不是估算市場比例。如果第 2 位和第 3 位都卡在同一個步驟，這個訊號就值得修正。
不要只找同事、朋友或最容易配合的人
同事和朋友通常太熟悉你的語境，也比較不願意給直接回饋。對台灣中小企業來說，若預算有限，至少要找接近真實客群的人，而不是只找最方便的人。
測試時要問什麼？使用者測試問題清單
使用者測試問題應分成操作前、操作中、操作後。操作前理解情境，操作中觀察行為，操作後追問原因與替代選擇。
操作前：確認背景與情境
- 你最近一次遇到類似需求是什麼時候？
- 你平常會用哪些方式解決這件事？
- 你在做這類決定時，最在意哪些資訊？
- 過去有沒有讓你覺得麻煩或不安心的經驗？
操作中：觀察卡住點，不急著解釋
- 你現在會先看哪裡？
- 你覺得下一步可能是什麼？
- 剛剛停下來的原因是什麼？
- 有沒有哪個字或畫面讓你不確定？
操作後：追問原因，而不是只問喜不喜歡
- 哪一段最容易理解？為什麼？
- 哪一段讓你最猶豫？
- 如果不能使用這個方案，你會改用什麼方式？
- 在什麼條件下，你會願意繼續使用或付費？
如何判斷 Test 結果？設計思考測試指標與決策表
Test 結果要同時看質化回饋與行為證據。使用者是否理解、能否完成任務、是否願意繼續，是判斷迭代方向的核心。
質化指標：使用者是否理解、是否卡住、是否願意繼續使用
| 指標 | 觀察方式 | 可能意義 |
|---|---|---|
| 理解度 | 能否說出頁面或流程目的 | 資訊架構是否清楚 |
| 困惑點 | 停頓、反問、重複查看 | 文案或互動提示需要修正 |
| 需求強度 | 是否描述真實使用情境 | 假設是否貼近使用者需求 |
量化指標：任務完成率、錯誤次數、完成時間
早期 Test 不需要追求大型數據，但可以記錄基本量化訊號，協助團隊比較不同版本。
- 任務完成率：是否完成主要任務。
- 錯誤次數：是否點錯、看錯或走到無關流程。
- 完成時間：是否明顯超出預期。
- 放棄點：在哪一步停止或要求協助。
決策方式：保留、修改、重測、回到前一步
| 結果訊號 | 決策 | 下一步 |
|---|---|---|
| 多數人理解且能完成任務 | 保留 | 進入下一輪細節設計 |
| 目標正確，但局部卡住 | 修改 | 調整文案、流程或畫面層級 |
| 修正後仍需確認 | 重測 | 用新版原型測同一假設 |
| 使用者需求與原先判斷不符 | 回到定義 | 重寫 POV 或 HMW |
設計思考 Test 常見錯誤
設計思考 Test 常見錯誤包括過度解釋、找錯人、一次測太多假設，以及把稱讚當成通過。這些都會讓團隊測了卻沒學到。
錯誤一：測試時一直解釋自己的設計
如果主持人一直補充說明，測到的會是解釋能力，不是原型本身。遇到使用者卡住時，先記錄，再用中立問題追問原因。
錯誤二：一次測太多假設
同一輪測試若同時測價格、流程、品牌信任、功能理解，最後很難判斷哪個因素影響結果。每輪應先聚焦最有風險的 1 至 3 個假設。
錯誤三：把「使用者說喜歡」當成通過
「喜歡」只是意見，不一定代表會使用、會付費或會推薦。真正有用的訊號，是使用者能完成任務，並說得出在什麼情境下會採取行動。
錯誤四：測試失敗就否定整個設計思考
Test 發現問題是正常結果。比較成熟的團隊不會急著把失敗歸咎於方法，而是回頭檢查問題定義、Persona、原型與測試任務是否對齊。
不同情境下，設計思考 Test 可以怎麼用？
設計思考 Test 可用在產品介面、服務流程與工作坊教學。只要有假設、有原型、有使用者情境，就能透過測試與迭代降低錯誤成本。
產品介面：測流程是否順手
例如報名頁、購物流程、後台功能，可請使用者完成指定任務，觀察是否找得到按鈕、是否理解欄位、是否能完成送出。若涉及按鈕層級，也可銜接 button design guidelines 的介面判斷。
服務流程：測使用者是否知道下一步
門市預約、客服轉接、課程報名都適合用 Test 檢查。服務設計常見問題不是流程不存在，而是使用者不知道現在到哪一步、下一步要等誰通知。
工作坊教學：讓團隊學會從回饋修正
課程講師可讓小組用紙本原型互測，再要求學員把回饋轉成下一版修改。這比只講同理、定義、發想更能讓團隊理解設計思考的學習迴圈。
設計思考 Test 工具與模板整理
Test 階段最實用的工具是三種表：假設驗證表、使用者測試紀錄表、測試後決策表。它們能把回饋整理成可討論的資料。
假設驗證表
| 假設 | 風險 | 測試方式 | 判斷證據 | 結果 | 下一步 |
|---|---|---|---|---|---|
| 使用者能在首頁找到報名入口 | 高 | 任務測試 | 是否在未提示下找到入口 | 待填 | 待填 |
使用者測試紀錄表
| 任務 | 行為觀察 | 使用者語句 | 情緒反應 | 卡住點 | 初步洞察 |
|---|---|---|---|---|---|
| 找到課程費用 | 反覆滑動頁面 | 「我以為價格會在上面」 | 猶豫 | 資訊位置不明顯 | 費用資訊層級需提高 |
測試後決策表
| 問題 | 證據 | 影響程度 | 決策 | 負責人 | 重測條件 |
|---|---|---|---|---|---|
| 使用者看不懂下一步 | 3 位中有 2 位停在同一畫面 | 高 | 修改 | 設計師 | 新版提示文案完成後 |
若團隊正在整理品牌定位，可把 Test 結果回填到 brand positioning strategy 與 brand guideline manual，讓設計判斷不只停留在畫面偏好。若原型來自 AI 工具，也可對照 canva ai magic design 或 ai design tools comparison 的工具選擇。
設計思考 Test 階段是什麼？
設計思考 Test 階段是把原型交給目標使用者操作，透過觀察、訪談與任務結果，驗證假設是否成立，並決定下一輪迭代方向。
設計思考 Test 和 Prototype 有什麼差別？
Prototype 是把想法做成可被理解或操作的原型；Test 是用原型收集使用者回饋與行為證據。前者是測試媒介，後者是驗證與學習過程。
設計思考 Test 一定要找真實使用者嗎？
最好找接近真實情境的目標使用者。若時間有限，也應優先找符合 Persona 與使用需求的人，而不是只找同事或朋友。
設計思考 Test 要找幾個人測才夠？
早期原型測試可先找 3 至 5 位高度相關使用者。目標是找出重複出現的問題與高風險假設，不是做統計推論。
原型一定要做得很完整才能測試嗎？
不需要。只要原型足以呈現任務情境，就可以測試。紙本、線框、簡報、流程稿或可點擊原型都能使用，重點是能驗證當前假設。
測試時可以向使用者解釋產品功能嗎？
可以提供必要任務背景，但不應主動解釋操作方法或替使用者找答案。若需要大量解釋才懂，通常代表原型或資訊設計需要修正。
使用者說喜歡，就代表測試通過嗎？
不代表。喜歡是主觀意見，還需要觀察使用者是否能完成任務、是否理解價值、是否願意在真實情境中採取行動。
測試失敗要回到設計思考哪一個步驟？
要看失敗原因。若是畫面或流程問題，可回到 Prototype；若是需求判斷錯誤，應回到 Define，重新檢查 POV、HMW 與使用者情境。
設計思考是誰提出的？
設計思考並非單一個人一次提出，而是由設計、創新管理與教育領域逐步發展而成。實務上更重要的是理解同理、定義、發想、原型、測試之間如何循環。
設計思考 Test 適合企業內部流程改善嗎？
適合。企業可用 Test 檢查內部表單、報名流程、客服交接、教育訓練或跨部門協作是否清楚。只要能做出流程原型並找到實際使用者，就能測試與迭代。