在不發瘋的情況下將可用性測試數據轉化為行動
已發表: 2022-03-11收集、分類和理解在用戶研究和可用性測試期間收集的數據正在成為 UX 從業者中越來越普遍的任務——事實上,它正在成為一項關鍵的 UX 技能。
可用性測試將告訴您目標用戶是否可以使用您的產品。 它有助於識別人們對特定 UI 的問題,並揭示難以完成的任務和令人困惑的語言。 通常,可用性測試涉及大量的準備和分析,被認為是最有價值的研究技術之一。 它能夠提供定量和定性數據,幫助指導產品團隊找到更好的解決方案。
然而,這不是在公園裡散步。 為了發現可用性問題,用戶體驗研究人員和設計師經常不得不處理大量不完整、不准確和令人困惑的數據。 有五到十名參與者的常規可用性測試很容易產生超過六十個問題。 在等待可怕的分析癱瘓者抬起醜陋的腦袋時,感覺就像“從消防水管裡喝水”。
當試圖解決可用性問題時,一個相當大的風險是走上錯誤的軌道,試圖提出不能真正解決手頭問題的解決方案。 風險在於發現的問題和確定的解決方案之間可能存在脫節。 這些可能是由許多不同的因素引起的,包括決策疲勞和許多類型的認知偏差。
如何將可用性測試數據轉化為可行的解決方案
為了克服上述障礙,我們需要有效的方法來處理我們的測試數據,同時確保我們為發現的問題選擇最有效的解決方案。
讓我們從創作過程中藉鑑一些想法開始。 其中最強大的是英國設計委員會的雙菱形,它反過來使用發散-收斂思維。 這是一個設計過程,具有明確定義和集成的問題和解決方案階段。
雙菱形正是我們需要構建一個框架來處理可用性問題並找到解決它們的方法。
使上述模型適應結果的可用性測試是一個四步過程:
- 數據採集
- 問題優先級
- 解決方案生成
- 解決方案優先級
讓我們詳細了解每個步驟,包括如何將其付諸實踐。
注意:我們需要使用一些基本的數學。 不用擔心,這並不算多,在本文的最後,您會發現一個電子表格可以自動完成整個過程。 如果它仍然不適合您,還有一種可視化方法,您可以在其中使用便利貼和白板。
第 1 步:可用性研究數據收集
從你的研究問題開始,第一步是收集可用性測試產生的數據。 需要設置它以便在流程後期輕鬆產生想法和洞察力——關鍵是清晰地構建和組織數據以避免混亂。 在大多數情況下,足以:
- 擁有問題識別(ID) 系統
- 注意它發生的位置(屏幕、模塊、UI 小部件、流程等)
- 了解用戶正在從事的任務
- 提供問題的簡明描述
Lewis 和 Sauro 在Quantifying the User Experience一書中使用的一種組織可用性問題的常用方法是如下表所示繪製數據,行中顯示問題,最後幾列中顯示參與者。
在上面的示例中,由三個參與者進行的虛構可用性測試產生了兩個問題:
- 參與者一(P1)的第一次經歷
- 第二個由其他參與者(P2 和 P3)
第 2 步:問題優先級
由於資源有限,有必要以優化分析的方式優先考慮可用性問題。 通常,每個可用性問題都有一個嚴重性等級,受以下因素影響:
- 任務關鍵性:根據任務未完成對業務或用戶的影響進行評級。
- 問題頻率:不同參與者發生問題的次數。
- 問題影響:它對嘗試完成任務的用戶的影響有多大。
要確定優先級,我們需要執行以下步驟:
設置測試中執行的每個任務的重要性分數。 簡而言之,通過為其設置數值來定義任務對業務或用戶的重要性。 這些值可能來自一個簡單的線性序列(例如,1、2、3、4 等)或更複雜的東西,如 Fibonacci 序列(1、2、3、5、8 等),與敏捷方法,例如計劃撲克。
- 通過為該量表中的項目分配一個值(與上述相同)來設置每個問題的影響分數:
- 5:(阻止程序)問題阻止用戶完成任務
- 3:(主要)它會導致挫敗感和/或延遲
- 2:(次要)對任務績效的影響較小
- 1:(建議)這是參與者的建議
通過將出現次數除以參與者總數來找到問題的問題頻率(%)。 這是一個基本的百分比計算。
- 最後,通過將上述三個變量相乘來計算每個問題的嚴重性。
讓我們看看它在電子表格中是如何工作的(當然我們想要自動化,對吧?)。 我們更新後的表格如下所示:
在上面的示例中,我們有以下場景:
- 三個參與者(p1、p2 和 p3)經歷的三個可用性問題;
- 任務“創建帖子”出現了兩次,關鍵是 5,不太關鍵的任務(社交登錄)分配了 3;
- 鑑於其影響,每個問題都被分配了一個值:5(阻礙者)、3(主要)和 2(對任務性能的輕微影響);
- 每個問題的頻率(例如,問題 2 出現兩次,三個參與者,因此 2/3 = 0.67);
- 最後,嚴重程度是由其他因素相乘產生的(例如,3 x 5 x 0.33 = 4.95)。
現在就是這樣。 我們按以下順序發現了最重要的可用性問題: 3、2和1 。 在這個階段,我們對可用性問題的前景也有很好的看法——幫助團隊構建高層次問題並在接下來的步驟中進行優化的大圖。
第 3 步:解決方案生成
通常,如果沒有建議(通用建議)和解決方案(具體說明)列表,可用性測試在結束時是不完整的。 有時解決方案很明顯——比如更正 UI 組件的位置。 對於那些具有不明顯或許多可能解決方案的問題,情況變得更加棘手。 哪種解決方案更好? 哪一個更可行? 進行實驗以找出答案的成本/收益是什麼? 在這裡,傳統的定期推薦方法是不夠的。
為了降低做出錯誤設計決策的風險,我們需要:a) 多種解決方案可供選擇,以及 b) 有效的選擇過程。 我們將使用與前一階段中用於處理數據收集和問題優先級步驟的相同的發散-收斂方法。 步驟是:

對於每個問題,產生多個解決方案——解決問題的可能方法是什麼? 在這裡,我們有很好的機會與團隊的其他成員(開發人員、設計師、產品經理等)進行協作。
重新組織解決方案,使其保持具體——根據需要,合併或拆分解決方案以避免冗餘和過多抽象。 同樣,要具體,以便更容易評估想法。 例如,與其只是“避免使用漢堡菜單”,不如說明具體的解決方案,例如“使用水平導航和垂直樹形菜單”。
標記解決方案可能解決的其他問題——在實踐中,一個好的解決方案可以解決多個問題。 好的解決方案是多才多藝的!
按照上述步驟,結果表如下所示:
在此示例中,我們有頭腦風暴解決方案列表(行),以及每個解決方案解決的問題(列,表示在前面的步驟中發現的問題)。
接下來,讓我們看看如何改進這個列表,並找出哪些解決方案是實施的最佳候選者,以及執行的順序。
第 4 步:解決方案優先級
與問題優先級相似,我們需要根據一些參數對解決方案進行優先級排序。 在敏捷團隊中,這個主題被非常認真地對待,通常使用業務價值和復雜性,這讓我們可以計算投資回報率 (ROI)。 借用這個邏輯,我們有以下步驟:
計算每個解決方案的有效性。
解決的問題越嚴重,解決方案就越好。 這可以粗略地與敏捷方法中的業務價值進行比較。 將解決方案解決的所有問題的嚴重性加起來。Effectiveness = Sum of issue severities
- 磨練解決方案的複雜性。
- 開發此解決方案需要哪些資源?
- 所涉及的技術有多標準?
- 業務/用戶需求有多清晰?
換句話說,努力和不確定性越大,解決方案就越複雜。 只需將其轉換為可量化的值,例如斐波那契數列(1、2、3、5、8 等)。 如果你作為一個團隊來做這件事,那麼規劃撲克非常適合。
計算解決方案的投資回報率。 這是成本收益關係,通過將解決方案的有效性除以其複雜性計算得出。 投資回報率越高越好。
ROI = Effectiveness / Complexity
讓我們回到我們的電子表格,現在看起來像這樣:
在上面的例子中,我們有:
- 解決方案列表(行)
- 問題(i1 到 i3)及其嚴重性(4.95、6.7 和 10.05)
- 每當解決方案匹配(解決)問題時,指示符為 1
- 每個解決方案的有效性(4.95、4.95 和 16.75)
- 團隊估計的每個解決方案(1、3 和 5)的複雜性
- 每個解決方案的投資回報率(4.95、1.65、3.35)
根據這個例子,我們應該按照以下順序(從高到低 ROI)優先考慮解決方案的開發:解決方案 1,然後是解決方案 3 和 2。
總結一下這些步驟:我們從收集數據開始,然後根據具體參數對問題進行優先級排序。 之後,我們為這些問題提出了解決方案,並最終確定了它們的優先級。
使用電子表格
上述方法涉及重複多次的一些(基本)計算,因此最好使用電子表格。
如果你想遵循這種方法,這裡有一個模板(谷歌表格):https://goo.gl/RR4hEd。 它是可下載的,您可以根據自己的需要自由定制它。
我討厭電子表格! 更直觀的東西呢?
幾乎我認識的每個人(當然包括我)都喜歡使用便籤紙和白板,不僅因為它通常更快、更有趣,而且還因為它促進了協作。 如果你是敏捷或設計思維的實踐者,你就會明白我的意思。 我們如何應用諸如便簽之類的可視化工具來使用本文中展示的方法? 好吧,這可能值得一整篇博客文章,但讓我們試著從表面上看。
一種方法是為問題(影響 x 頻率)創建一個矩陣,並將其放在另一個矩陣旁邊以獲得解決方案(有效性 x 複雜性)。 每個矩陣分為四個像限,表示優先級。
以下是步驟:
通過根據影響和頻率將便簽放置在適當的象限中來創建問題矩陣。 為了簡化這種方法,我們不得不省略一個參數。 在這種情況下,任務關鍵性。
通過根據每個解決方案的有效性和復雜性組織便籤來創建解決方案矩陣:
從問題矩陣第 1 象限中的問題(具有較高嚴重性的問題)開始,為每個問題集思廣益。
將這些解決方案放入解決方案矩陣中,從象限 1(左上角)開始。 問題越嚴重,解決的效果就越有效。
通過在水平軸上移動每個解決方案來調整其複雜性(越複雜,越靠右)。
對其餘問題重複上述步驟(按此順序,象限 2、3 和 4)。
在練習結束時,象限 1 中的解決方案是具有最佳 ROI(更有效且更簡單)的解決方案,表示優先級最高。 結果如下圖所示:
包括我們遺漏了一個參數(任務關鍵性)這一事實,這裡的缺點是您必須依賴視覺準確性而不是電子表格中的計算。 從積極的方面來說,我們有一種促進協作的方法——這有時對於獲得團隊的支持至關重要。
通過“快速而骯髒”的視覺分析以可能的準確性為代價促進協作是一種潛在的權衡。 哪種方法更好? 簡短的回答:最適合您的情況並最符合您的目標的答案。
可用性測試數據分析的最終要點
使用這些方法得到了在各種項目中使用它的團隊的以下觀察結果:
尤其是在處理更大規模的研究時,問題優先級讓團隊專注於真正重要的事情,通過減少不必要的認知挑戰(如信息過載、分析癱瘓和決策疲勞)來節省時間和資源;
連接的端到端工作流程使解決方案與可用性測試輸出更加一致(因為問題和解決方案是配對的),從而降低了實施不太理想的解決方案的風險;
我們可以使用在線工具輕鬆地協作(部分或整體)應用此方法。
了解這種方法的局限性很重要。 例如,在優先級排序階段,不包括在測試中觀察到的用戶的積極態度和行為。 重點是可用性問題。 一個建議是單獨記錄此類數據,並在此過程中根據需要使用它來補充和平衡調查結果。
最後,除了可用性測試之外,這種方法還可以擴展到其他用戶體驗研究技術。 應用“雙菱形”方法(發散/收斂問題和解決方案),我們可以混合各種用戶研究數據並在任何其他項目中使用上述方法。 你的想像力是極限!
• • •
進一步閱讀 Toptal 設計博客:
- 電子商務用戶體驗——最佳實踐概述(附信息圖)
- 以人為本的設計在產品設計中的重要性
- 最佳 UX 設計師作品集——鼓舞人心的案例研究和示例
- 移動界面的啟發式原則
- 預期設計:如何創造神奇的用戶體驗