編輯導語：隨著科技的發展，車載技術也在不斷地更新發展。本篇文章作者分享了車載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. 設計任務

前面提到定量研究測試，是請多名使用者來參與對我車載系統的一個體驗，我們將原先設定好的任務對使用者進行說明，然後我們在車內觀察使用者使用我們產品的一個狀況。可用性的評估是基於任務的，所以接下來我們講一下任務的五個原則：鎖定主要任務、明確任務起點與目標、給任務設定約束條件、任務不應過於簡單、避擴音供線索和描述操作步驟。

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協議。