【設計思考｜測試】設計驗證基礎概念與實務（上）
講師：黃勇偉
本週很榮幸邀請到在 104 人力銀行擔任用戶研究員的黃勇偉老師，來為 DT 的社員們介紹設計思考的最後一步「測試」。如果想了解測試的基本概念及完整流程，就一起接著看下去吧！
如果還沒看過發想階段的社課回顧可以點擊下方連結 ↓↓
講師介紹：
勇偉老師擁有多年用戶研究員經驗，現任職於 104人力銀行的用戶研究團隊，致力於使用各種研究方法，來分析用戶的行為及需求，並持續創造符合市場與用戶需求的產品。
文章目錄
一、設計驗證基礎概念
二、概念測試 & 易用性測試
三、測試專案流程
四、受試者招募
五、測試訪談腳本一、設計驗證基礎概念
在上一篇設計策略（超連結）中，提到了「見識謀斷」的概念可以協助定義問題，來讓我們思考解決方法。在這一章中，我們要接著探討如何測試解決方案（設計原型）。而在開始進行測試前，我們首先需要了解設計驗證的概念。
什麼是「設計驗證」？
設計驗證就是「設計者對於設計物與外在*之間，會產生什麼樣的關係的假設」
＊外在
包含目標對象（用戶、寵物……等）、使用情境、自然環境、社會環境……等因素換句話說就是在確認設計師創造的產品和使用者、情境之間的關係，像是使用者在使用 App 時，對頁面架構的認知、預期的操作方式、對設計的接受度、喜好度等
而實際做出一個原型丟進生活去做評估，了解該產品有沒有滿足對象、情境、價值 — — 三個影響設計的關鍵因素，就是測試的一種。
如何提出「設計假設」？
首先需要釐清「假說」跟「問題」不一樣
- 問題（Questions）：任何加上問號的句子，都可以是問題。
- 假說（Hypothesis）：對世界運作方式的某種猜想，可能來自各種了解、經驗、直
覺，是一個直述句。
「假說」通常會暗示要搜集哪些資料來做驗證。例如：
- 貓咪不吃飼料是因為新買的飼料很難吃
- 用戶不願意來論壇發文，可能是因為網站的介面設計不好用
常見且完整的設計假設通常會長的像是：
幫「誰（Who）」在「什麼情況下（Content）」用「什麼方式（How）」*解決或滿足「問題或需求（What）」
＊解決或滿足「問題或需求（What）」
這部分也會顯示出問題解決後所帶來的價值（Value），建議在設計時可以多思考「用戶為什麼要用？要買？」若是針對在使用者介面設計中的設計假設，可以試著往以下的幾個方向思考：
- 在什麼使用情境下，什麼樣的設計（資訊呈現、頁面佈局、互動元件等）可以讓使用者完成什麼任務
- 在什麼使用情境下，什麼樣的設計（資訊呈現、頁面佈局、互動元件等）可以讓使用者知道該如何使用它、接受介面中的引導繼續使用
- 在什麼使用情境下，什麼樣的設計（資訊呈現、頁面佈局、互動元件等）可以讓使用者獲得什麼，進而促發什麼行為、 感受
什麼樣的使用者，在擁有什麼意圖時，會需要什麼、想做什麼（對於用戶需求的假設）
這邊勇偉老師也有特別補充關於適合用於「設計驗證」的原型保真度
其實不管是低保真度（紙張繪畫）還是高保真度（可互動數位原型）都可以，並沒有規定一定要做到特定程度的原型才能拿去做測試評估，一切取決於設計者想要驗證什麼。因此，建議可以先確認要驗證什麼，再來思考需要什麼樣的原型。
回到目錄二、概念測試 & 易用性測試
用戶研究的方式可以分為：
- 「探索型研究」：探索「問題」的研究
- 「驗證型研究」：驗證「解法」的研究（也是本篇文章談論的重點）
這裡將著重討論兩個常見的驗證型研究：概念測試（Concept Testing）和易用性測試（Usability Testing）
概念測試（Concept Testing）
- 通常應用於產品設計初期。
- 目的是要確保設計的價值主張、核心假設，與目標對象的需求脈絡之間的適配性
- 這不是真的要讓用戶操作原型，而是先介紹概念給用戶了解，讓用戶自行去想像後，來告訴研究員有沒有問題
易用性測試（Usability Testing）
- 通常應用於產品設計後期。
- 目的是要確保在特定使用情境中，系統、產品或服務能夠被特定使用者有效率且滿意地使用，以達到特定目標的程度。
- 這部分則真的讓用戶去操作原型，以探討用戶是不是真的能夠順利地使用原型來達到預期的目標（因此這是數位產品最常使用的測試方式）
易用性可以分成不同的解釋面向，下圖是兩種常見的分法：
這裡介紹 Whitney Quesenberry 提出的五大易用性面向：
- 有效性（Effective）：產品、系統能夠幫助用戶達到他們的目標，並成功完成所需的任務
- 效率（Efficient）：用戶能夠最輕鬆、最快地完成任務，且系統應能夠支援高效率的工作流程
- 引人入勝（Engaging）：產品或系統應該能夠吸引用戶的注意力，提供愉悅和有趣的使用體驗
- 容錯性（Error tolerant）：系統應該能夠防範、容忍用戶出錯，並提供明確的錯誤處理和回饋，使用戶可以輕鬆地從錯誤中恢復
- 易於學習（Easy to learn）：新用戶能夠迅速學習如何使用產品或系統，並能夠在短時間內掌握基本操作
如何進行概念測試？
常用的原型形式有概念板、分鏡腳本、影片、線框稿、甚至是展場等等，只要選擇能夠讓受訪者清楚了解設計概念、完整內涵的原型即可。
概念測試的步驟：
- 事前訪談：了解受訪者在目標情境中的過往經驗，以及對於設計物相關的其他背景知識掌握程度。
- 展示設計概念與討論：清楚地向受訪者呈現構想，包含使用場景、預想的互動情形、 設計所能達到的預期效果（注意要是中性的描述），讓受訪者自由表達他的感受
- 徵求整體評價以及評價的原因：蒐集回饋來當作迭代的依據
如何進行易用性測試？
進行易用性測試的評估方式有兩種：
- 經驗法則評估法（Heuristic evaluation）：邀請 3–5 位具有易用性專業知識的專家，直接判斷產品介面是否符合易用性經驗法則。此方法的完成速度快，但難以探索真實用戶使用的心得
- 認知推演評估法（Cognitive Walkthrough）：隨意邀請受訪者（很可能不是真實用戶），因此需要提供受訪者一個角色背景、當前情景及任務。研究員需要先假設自己就是對產品完全不了解的初次使用者，模擬他人初次操作的情況，來列出合適的腳本。為此，可以透過行動的七個階段來做推演（如下圖）
回到目錄三、測試專案流程
這邊著重討論認知推演評估法，因為這通常是較為方便執行的方法。
專案流程大致上分為前置作業、測試過程、測試後的學習：
「測試中」的詳細步驟為：
- 邀請受訪者操作測試原型
- 透過主持人引導，為受訪者設定測試情境，讓受訪者自由地操作介面來完成測試任務
- 要求受訪者在操作的同時，說出每個在頭腦中出現的想法
- 研究者觀察受訪者與介面之間的互動行為，同時傾聽受訪者操作過程中產生的想法與回饋，並適時提問了解想法、行為背後的原因，專注於了解產品能否幫助使用者達成目標？
回到目錄四、受試者招募
首先要釐清「誰是我們產品的 TA」，再來要分別制定出主要、分組、平衡條件：
- 「主要條件」：全體受訪者都需要符合的條件。
- 「分組條件」：根據有可能會影響到測試結果的變項設置為條件。
- 「平衡條件」：盡可能追求人數均衡，以免讓測試結果有所偏頗。例如：性別、年齡
要測試多少人才夠？
雖然測試所需人數同時取決於 Prototype 複雜度、任務複雜度、問題可發現性……等因素，但通常在測試人數為 5 人的情況下，就能發現到大多數產品存在的易用性問題。
回到目錄五、測試訪談腳本
測試腳本是易用性測試中，用於與受訪者簡介研究、 引導測試任務進行的文件。通常包含：
- 訪談目的
- 訪談流程介紹
- 前訪暖身用訪綱
- 放聲思考指引*
- 測試任務
＊放聲思考法
受訪者在操作指定任務的同時，將心中的想法講出來，包含他們看到了什麼、想到了什麼、感覺如何......等，因為在測試中，研究人員仰賴受訪者主動回報，來判斷是否遇到阻礙或困難。設計任務腳本前，要先確認研究範疇（包括哪些流程頁面）以及這些範疇中有哪些研究問題。
設計任務腳本時，需要模擬一段「自然」的使用旅程，來讓受訪者執行有助於我們了解研究問題的操作。舉個例子，假設我們將目標設為「完成應徵一份工作」，那任務的使用旅程可能就會是
- 尋找符合求職考量的職缺（是否會使用篩選器）
- 比較相似職缺
- 將決定應徵的工作先儲存起來（是否可注意到且理解「儲存」按鈕的意思）
- 針對職缺完成履歷調整
- 完成職缺應徵（應徵送出的流程中是否會出現斷點）
- 確認應徵狀態（是否可找到「查看應徵紀錄」的入口）
也要記得檢查所有研究問題都可以被這些測試任務所涵蓋。
最後，在為任務設定使用情境時，要注意好的情境需要避免直接提示操作方式與功能、貼近真實情境、讓任務有可操作性。
回到目錄