【設計思考|測試】設計驗證基礎概念與實務(上)
講師:黃勇偉
本週很榮幸邀請到在 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 人的情況下,就能發現到大多數產品存在的易用性問題。
回到目錄
五、測試訪談腳本
測試腳本是易用性測試中,用於與受訪者簡介研究、 引導測試任務進行的文件。通常包含:
- 訪談目的
- 訪談流程介紹
- 前訪暖身用訪綱
- 放聲思考指引*
- 測試任務
*放聲思考法
受訪者在操作指定任務的同時,將心中的想法講出來,包含他們看到了什麼、想到了什麼、感覺如何......等,因為在測試中,研究人員仰賴受訪者主動回報,來判斷是否遇到阻礙或困難。
設計任務腳本前,要先確認研究範疇(包括哪些流程頁面)以及這些範疇中有哪些研究問題。
設計任務腳本時,需要模擬一段「自然」的使用旅程,來讓受訪者執行有助於我們了解研究問題的操作。舉個例子,假設我們將目標設為「完成應徵一份工作」,那任務的使用旅程可能就會是
- 尋找符合求職考量的職缺(是否會使用篩選器)
- 比較相似職缺
- 將決定應徵的工作先儲存起來(是否可注意到且理解「儲存」按鈕的意思)
- 針對職缺完成履歷調整
- 完成職缺應徵(應徵送出的流程中是否會出現斷點)
- 確認應徵狀態(是否可找到「查看應徵紀錄」的入口)
也要記得檢查所有研究問題都可以被這些測試任務所涵蓋。
最後,在為任務設定使用情境時,要注意好的情境需要避免直接提示操作方式與功能、貼近真實情境、讓任務有可操作性。
回到目錄