起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識如何做車載HMI可用性測試，看完你不會可以揍我
編輯導語：隨著科技的發展，車載技術也在不斷地更新發展。本篇文章作者分享了車載HMI可用性測試的具體方法過程，從可用性基礎知識、可用性測試類型、可用性測試方法、實際工作內容等方面出發，感興趣的一起來看看吧，希望對你有幫助。
這篇文章針對車載行業的可用性測試，我們做一下深入探討，前面幾篇跟下來的讀者也都知道我寫作的節奏，前面會深入講解該主題的基礎內容，并結合一些我工作中實際案例給予大家去了解，后半部分以實踐案例為主，將前面基礎知識融入進來，結合案例進行剖析可用性測試。
這次文章大綱分為三大內容可用性基礎知識、HMI可用性測試實際工作內容、HMI可用性測試評估維度體系，最后一點是重頭戲。
我們在文章前夕先談談可用性測試與用戶訪談，可能后期也會針對 #HMI用戶訪談# 這塊內容會再輸出一篇文章。
可用性測試和用戶訪談的區別：可用性測試更偏向于觀察用戶的操作行為，而用戶訪談是更好的挖掘用戶的需求。
可用性測試是為了找出產品的問題而測試，通過這種測試找出產品中存在的問題，加以解決，最后目的也是為了讓產品用起來體驗更加。
大家也發現了，關于HMI設計類文章很多平臺上很少有，還有設計師工作中用到的設計方法論，如何運用到HMI車載領域當中，確實都很難找到，并且專業領域的內容車廠也不愿意拿出來分享.
我一開始寫文章的初衷就是想打破這個格局，雖然一個人力量很小，但我還是堅持做下去了，希望通過我的分享能夠讓更多的人能進入這個賽道，并且也能輸出自己的經驗傳遞下去，成為光，并散發光。
進入我們今天的正題吧。
一、可用性基礎知識
ISO9241中對“可用性”的定義是：特定用戶在特定的使用場景中，為了達到特定目標而使用某產品時，所感受到的有效性、效率和滿意度。
1. 可用性原則
- 有效性（Effectiveness）：用戶完成特定任務的情況。比如：設定一個調節空調風量的任務，讓用戶操作，記錄員在旁邊記錄用戶的一個完成度的情況，成功完成、求助后完成、未完成的狀態。
- 效率性（Efficiency）：用戶完成特定目標的效率，任務完成時間和完成的一個路徑。在記錄過程中如果在一個正常時間范圍內無需關注，主要還是要記錄在某些功能上面花費較多時間完成的任務。在操作路徑上也要觀察，是否符合我們設定的操作路線，是否存在偏差或者是猶豫不決的地方。
- 滿意度（Satisfaction）：用戶使用該車機系統主觀滿意度，當然我們也要提前做好一些標準，比如任務完成的難易度進行評價，任務完成的滿意度測評等。
總結一下：
一個好的可用性必須能夠滿足這三個維度，這三個維度也會有一個重要程度之分，有效性 > 效率 > 滿意度。
需要最后補充一下：
在評估一個任務可用性以外，還要需要注意該功能的價值，尤其是OTA升級發布新的功能，功能價值分為兩類：用戶價值和商業價值，作為設計師的我，覺得用戶的體驗應該是放在第一位的，有了好的體驗才能夠更好的去談商業價值，不然就是在扯蛋。
例如：我們在優化負一屏中的體驗，將調節音量新增了可以調節四種音量大小，多媒體、電話、導航、語音，舊版本的音量調節，用戶經常會吐槽，因為當時功能設定負一屏音量調節是整個的一個系統調節，你在音樂調節很大音量的時候，如果有一個電話接入進來，對方說話聲音就很大，會嚇到用戶，這個在駕駛過程中會很危險的，因此在OTA升級后，我們做了優化。
二、可用性測試類型
其實可用性測試方法和類型很多，會在不同情況下使用，選取的方式也是需要看團隊設定的目標、在什么階段、最終的預算能有多少錢，真的沒錢很難辦事情。
1. 探索性測試
產品在不同階段，可根據不同的測試類型做可用性測試，在產品初期可使用探索性測試方法，利用產品的原型圖展示給用戶，探索性的測試目的是，用戶是否對這款產品有所了解，如果在某些方面有所疑惑需要記錄，根據多組測試，重疊性較高的功能就需要UX去優化，在產品初期需要不斷的試錯。
2. 比較性測試
我們先說一下比較性測試，我們在做設計時會出幾個不同的方案，需要在這個幾個方案中做出選擇，如果公司非常重視測試數據的話，會將設計方案同時上機進行路測，最終結合數據，讓體驗專家評判方案之間的優缺點，最終決策出符合用戶體驗的方案。
另外一種比較是選擇兩種或者更多的產品，去研究他們優缺點，確定哪個設計方案能夠提供給用戶帶來良好的操作體驗。
這兩種方案取決于項目的時間長短，如果像服務形的乙方需要快速的出方案，則更多的采用的是第二種，甲方有著自己設計研究部門可以給到部門有試錯的時間成本，那么他們更會傾向于兩者相結合的方案，我們只能提供可行性的方案，最終還是需要領導層進行拍板實施。
3. 評估性測試
當產品進入后半段，在發布版本前后，上機進行測試，HMI上機測試分為在室內臺架上測試，另外一種是裝機在道路上測試，不同場景的路測，在這個階段的可用的測試方法是評估性測試。
評估性的可用性測試目的是確保這個產品在發布之前將潛在的問題進行修復；在版本發布之后本公司或者一些測評機構會根據自己的評測標準進行對這款產品進行評估測試，對照自己的評判標準進行打分，方便后續OTA升級，版本優化迭代功能。
三、可用性測試方法
相信大家對于定性和定量這兩個詞并不陌生，在可用性測試中承擔著重要的組成部分。
1. 定性 / 定量研究
定性研究是指參與本次車載系統的體驗者對于可用性的一個直接評估，從而產生結果，并且發現哪些功能在操縱的時候會出問題，有哪些體驗是覺得不錯的，哪些功能的體驗需要進行優化，聽完這些內容是不是覺得和車載系統的專業測評人差不多了吧，當然，在做這個定性測試的時候需要找不同的人群進行測試，需要做到完整性。
定量研究也是我們常用到的一個測試方法，定量研究出的數據對于可用性啟到了間接評估，通過參與本次車載系統體驗的用戶，觀察他們在操作事先列舉好任務上的表現狀況，這些狀況包含了本次任務消完成消耗的時間、完成的成功率、錯誤點擊等。
定量研究的結果是一些簡單的數據，這些數據需要有一個參考的依據，一個已知的標準，要么就是競品體驗的一個對比數據，還有一個是自己車載系統前后版本的一個對比看看改進多少（專業術語：ROI），一個詞需要找到 “參照物”。
例如：在多少秒內操作是一個安全的范圍值？
這方面的知識我有在我第二篇交互文章中有提交過，單次交互操作動作不能超過2秒（1秒內為最佳）如果一個在行駛過程中需要交互操作的動作 用時2-3秒就已經是一個危險狀況，所以我們參考這個依據，可以進行對我們車載系統做一個判定。
定量的數據是有了，參考標準也有了，有的功能方案是不OK的需要去優化，但是這些數據沒有告訴我們如何去優化它，需要在設計方案中何如去優化？定量分析研究只是記錄了一個過程中得到的數據，也沒辦法得到用戶在什么項目中遇到什么困難。
比如車輛設置中的調節ADAS的某一個設置選項，用戶不知道在哪里尋找，我們只能記錄這項任務失敗。所以在為了更好的做可用性測試，我們通常會使用定性研究來增加進行補充缺失的部分。
2. 如何運用定性和定量研究
前面有提到他們之間的區別，那我們在日常的工作中該如何的運用呢？在什么階段用什么研究？
在發布車載系統1.0版本和后續迭代版本優化1.x版本，可以使用定量、定性、兩者組合性來評估，如果這次評估的目的是數據方面，在這個功能點上我們優化多少，提升了多少用戶使用了這個功能，那么就需要采用定量分析，因為只有定量研究才能得出每一個版本對比上一個版本到底優化了、提高了多少。
需要針對車載系統重新設計內容時候，需要通過定性的研究方法去完成，在這個過程中用戶的角色是承擔為設計提供可行性方案的人，他會覺得在哪方面可以進行優化，到得這些用戶數據和意見之后，也便于設計師們做出選擇性的優化，創建出一個新的體驗感，所以這個階段使用定性研究方式更為適合。
舉個例子：
用戶在體驗過程覺得在操作調節音量的交互感覺不好，抓住關鍵詞“調節音量體驗不好”，那么就要詢問清楚，問到用戶：“是在下拉出現的負一屏中 調節體驗感覺不好，還是在進入設置項中的去調節音量體驗感覺不好呢？
因為在做定性的研究的時候不會設定怎么進入，因此會出現通過多種方式去操作系統某一個功能，所以需要針對這個問題詢問清楚，才可以正確的優化這個體驗流程。
后面還需要跟進這個問題，是操作步驟過多，需要優化路徑？還是在滑動的體驗感需要加強？等這類問題，當然也可以讓體驗者去敘述他自己的點。如果同樣的去發現這類的問題，你去使用定量那么會增加很多工作成本不說，預算成本也會增加。
四、可用性測試實際工作內容
由于我們項目的保密性，不能透露過多內容，我將這次案列換成了其余車載系統，這次可用性測試的目的是系統評分數據。
1. 設計任務
前面提到定量研究測試，是請多名用戶來參與對我車載系統的一個體驗，我們將原先設定好的任務對用戶進行說明，然后我們在車內觀察用戶使用我們產品的一個狀況?？捎眯缘脑u估是基于任務的，所以接下來我們講一下任務的五個原則：鎖定主要任務、明確任務起點與目標、給任務設置約束條件、任務不應過于簡單、避免提供線索和描述操作步驟。
2. 主要任務
用戶在使用車載系統目的有很多種類，需要聽音樂、電臺、看視頻、導航到目的地、接/打電話、調節空調/溫度等等，可能會有上百個功能點需要去操作。
但一場測試不可能全功能進行測試，我們只有挑選出最重要的任務來進行測試，或者是剛上線的車載系統，需要測試一下基礎功能評測，如果遇到產品OTA升級或者是改動很大的版本點，會改變用戶的操作步驟，更或者是新增加的功能，都可以優先測試。
再舉個例子：
任務：調節空調的溫度
我們需要觀察的是，他是如何調節空調溫度的（我們設計師自己肯定知道全部的調節方案）。
第一種方案：可以點擊導航欄下方的溫度，點擊可以進行前后拖動來改變溫度。
第二種方案：按下方控按鍵，呼出語音 “溫度調節到21度”。
3. 明確任務起點與目標
在可用性測試中最重要的就是用戶能否可以完成任務項，所以需要明確目標，如果沒有的話，就無法判斷用戶是否完成任務，我們最初設定一個目標。
例如 “在音樂界面中將播放模式調成單曲循環模式”這是我們這個任務的最終目標，只要最終用戶在音樂界面中將播放模式改為“單曲循環”即為此項任務成功完成。
4. 給任務設置約束條件
在設定任務的時候，會出現可以多種方式去完成，上訴案例空調調節溫度，就可以使用兩種方法去完成，因此如果本次全程操作不允許用語音操作（這是作為一個約束的條件）本次的全部測試項目是關于在中控測試評估的，語音會有他自己的一套測試任務，這些都需要在任務開始前需要設定好的。
5. 任務不應過于簡單
如果你想測試用戶是否找到這個功能，請不要用“找到一個xxx暫停按鈕”，我們需要給用戶提供一個處理現實場景中的任務，而不只是去找這個按鈕的位置。
例如：“找到音樂暫停按鈕” 改為“在酷我音樂界面暫停一首歌曲”這樣會有一個明確的場景，這個場景是可以運用到現實駕駛中出現的任務，如果變成“找到音樂暫停按鈕”就屬于一個不OK的任務。
6. 避免提供線索和描述操作步驟
設計任務的時候應該給出具體的目標，而不是列舉好的整個操作步驟去教用戶去完成，這個跟說明書沒兩樣。
例如：“購買酷我音樂的季度會員”。進入酷我音樂界面、點擊酷我音樂中我的、然后點擊會員中心、再點擊續費、出現彈框選擇季度充值、最后掃碼付款。用戶在接受到這些信息后，就知道先進入音樂應用、找我的、尋找充值入口、最后再進行支付。
引導性過強的話會失去任務測試的意義，這樣做會錯失用戶在操作過程中發現了一些問題，觀察員也將錯失記錄的機會，如果沒有這提前事先布置好的步驟，可能會出現一些操作讓他感覺有異議，不知道自己是否操作成功或者是是不是點錯了等等狀況。
在用戶使用產品的時候，我們應該考慮使用的目標，不是考慮具體的操作步驟。我們在設計任務的時候一定要避免提供線索和描述操作步驟給到體驗者。
總結一下：
針對用戶來看的話，車載系統對他們只是一個工具，達到他們想要的操作目的“比如聽音樂、導航”這些功能目的，所以在可用性測試中，我們需要把測試車載系統某個功能目的為重點。
五、招募人選
在招募人選問題之前，需要根據這次測試的目的和需求，確認是定性研究還是定量研究或者是組合性的研究測試方式，這次的目的是對于新系統的一個評分，這次研究方向確定好是做定量研究測試。
定量研究可用性測試是基于（30+以上人 體驗者），但也有時候定量研究也會少于30人，因為預算的問題，或者其他的原因無法請到這么多人。
因為招募車載系統的一個體驗用戶，相對于招募去體驗APP、網頁端產品、還是B端的產品，都會難很多，因為條件的限制，處在的環境也變化了，因為是有駕駛的一個狀態，還需要去操作提前布置的任務，所以在招聘人員的時候確實相對其他平臺要難。
數據就會存在一些偏差。定量研究通過任務的完成率、完成時間、滿意度進行評分。這些總結性的評估數據，通常都是用于車載系統的迭代過程的跟蹤，在下一個版本中數據是否得到提高，從而達到優化的目的。
另外給大家補充一下定性研究人員選擇：
定性研究用戶可以5人參加這場測試，就可以發現大多數（85%）的產品可用性問題，隨著用戶的增加，會發現的問題會逐漸減少，因此最終定性研究分析選定的人數需要我們去考量。
在后面的實際案例中，我們采用的是定量研究，會針對整個定量研究全案做一個詳細的解說，也會增加一些定性的來作為補充說明。
總結一下：
我們要根據實際情況來確定我們招募的用戶數量，對比每一次的測試結果于后續OTA升級后的效果，是否需要增加投入的預算來做可用性測試。
六、準備工作
在做可用性測試之前需要規劃好準備的工作事宜，先是測試地點和工具的準備，后續是相關資料的準備，后面需要簽署保密協議，最后就是整個的可用性測試劇本準備。
1. 測試地點和環境
HMI車載系統測試場景相對于其他端的測試場景要多，這些不同測試地點和環境主要目的就是針對影響用戶操作的因素來做多方考量。
- 車載系統測試的地點：路測（大馬路上，封閉路段、正常道路）、地下車庫、路面停車場、隧道等。
- 車載系統測試的環境：晴天、雨天、陰天、下雪天、霧霾、沙塵暴等。
- 對于硬件的測試還會增加在不同溫度/濕度下的測試：極寒地區、干旱地區、常年潮濕雨水多地區等等（這類測試跟設計關系不大，想普及一下）。
2. 準備的工具
需要在測試車內裝機好需要測試的系統；安裝眼動儀來記錄用戶的觀看軌跡，便于后續優化界面設計和交互設計；還需要后排記錄人員跟拍操作錄像資料，便于后期的分析操作細節。
3. 相關資料
首先就是準備整套測試中的任務卡片，便于用戶查看；還有要為自己準備一張表格，記錄用戶操作中出現狀態的數據，如任務是否完成、完成時間等狀態；還有一些記錄關鍵事件和測試中觀察用戶體驗的表格，比如設計中可能會出現的問題，方便結束后進行總結，加入到后面迭代版本點中。
4. 簽署協議
在測試期間需要簽署保密協議等，因為用戶測試的是未上線的產品，為了確保項目安全起見，需要讓參與測試的用戶簽署保密協議。
5. 劇本準備
HMI可用性的劇本準備和其他基本類似沒有過多的出入，這個過程是：接觸用戶 ?? 開場白 ?? 開始測試 ?? 事后訪談 ?? 給予獎勵并送走用戶的整個過程，這些相同的劇本準備、還緊跟后面的觀察、訪談這些內容，大家都可以自行搜索，因為下面還有更重要的內容需要細講。
最后一步就是分析前面所得的數據，但需要一個標準去評估衡量，下一篇就會進入我們最核心的部分 # HMI可用性測試評估維度體系。
文章中如有不足之處，歡迎補充交流，我們下期見。
下期文章預告：HMI可用性測試評估維度體系。
本文由@設計界的影帝 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
很受用，感謝大佬
可用性測試更偏向于觀察用戶的操作行為，而用戶訪談是更好的挖掘用戶的需求。