前言

這篇文章針對車載行業的可用性測試，我們做一下深入探討，前面幾篇跟下來的讀者也都知道我寫作的節奏，前面會深入講解該主題的基礎內容，并結合一些我工作中實際案例給予大家去了解，后半部分以實踐案例為主，將前面基礎知識融入進來，結合案例進行剖析可用性測試，這次文章大綱分為三大內容：可用性基礎知識、HMI可用性測試實際工作內容、HMI可用性測試評估維度體系，最后一點是重頭戲。

往期回顧：

我們在文章前夕先談談可用性測試與用戶訪談，可能后期也會針對 #HMI 用戶訪談# 這塊內容會再輸出一篇文章。可用性測試和用戶訪談的區別→ 可用性測試更偏向于觀察用戶的操作行為，而用戶訪談是更好的挖掘用戶的需求。可用性測試是為了找出產品的問題而測試，通過這種測試找出產品中存在的問題，加以解決，最后目的也是為了讓產品用起來體驗更加。

大家也發現了，關于 HMI 設計類文章很多平臺上很少有，還有設計師工作中用到的設計方法論，如何運用到 HMI 車載領域當中，確實都很難找到，并且專業領域的內容車廠也不愿意拿出來分享，我一開始寫文章的初衷就是想打破這個格局，雖然一個人力量很小，但我還是堅持做下去了，希望通過我的分享能夠讓更多的人能進入這個賽道，并且也能輸出自己的經驗傳遞下去，成為光，并散發光。

進入我們今天的正題吧。

可用性基礎知識

ISO9241 中對“可用性”的定義是：特定用戶在特定的使用場景中，為了達到特定目標而使用某產品時，所感受到的有效性、效率和滿意度。

1. 可用性原則

有效性（Effectiveness）：用戶完成特定任務的情況。比如：設定一個調節空調風量的任務，讓用戶操作，記錄員在旁邊記錄用戶的一個完成度的情況，成功完成、求助后完成、未完成的狀態。

效率性（Efficiency）：用戶完成特定目標的效率，任務完成時間和完成的一個路徑。在記錄過程中如果在一個正常時間范圍內無需關注，主要還是要記錄在某些功能上面花費較多時間完成的任務。在操作路徑上也要觀察，是否符合我們設定的操作路線，是否存在偏差或者是猶豫不決的地方。

滿意度（Satisfaction）：用戶使用該車機系統主觀滿意度，當然我們也要提前做好一些標準，比如任務完成的難易度進行評價，任務完成的滿意度測評等，

總結一下

一個好的可用性必須能夠滿足這三個維度，這三個維度也會有一個重要程度之分，有效性 > 效率 > 滿意度。

需要最后補充一下：

在評估一個任務可用性以外，還要需要注意該功能的價值，尤其是 OTA 升級發布新的功能，功能價值分為兩類：用戶價值和商業價值，作為設計師的我，覺得用戶的體驗應該是放在第一位的，有了好的體驗才能夠更好的去談商業價值，不然就是在扯蛋。例如→ 我們在優化負一屏中的體驗，將調節音量新增了可以調節四種音量大小，多媒體、電話、導航、語音，舊版本的音量調節，用戶經常會吐槽，因為當時功能設定負一屏音量調節是整個的一個系統調節，你在音樂調節很大音量的時候，如果有一個電話接入進來，對方說話聲音就很大，會嚇到用戶，這個在駕駛過程中會很危險的，因此在OTA升級后，我們做了優化。

2. 可用性測試類型

其實可用性測試方法和類型很多，會在不同情況下使用，選取的方式也是需要看團隊設定的目標、在什么階段、最終的預算能有多少錢，真的，沒錢很難辦事情。

探索性測試：

產品在不同階段，可根據不同的測試類型做可用性測試，在產品初期可使用探索性測試方法，利用產品的原型圖展示給用戶，探索性的測試目的是，用戶是否對這款產品有所了解，如果在某些方面有所疑惑需要記錄，根據多組測試，重疊性較高的功能就需要 UX 去優化，在產品初期需要不斷的試錯。

比較性測試

我們先說一下比較性測試，我們在做設計時會出幾個不同的方案，需要在這個幾個方案中做出選擇，如果公司非常重視測試數據的話，會將設計方案同時上機進行路測，最終結合數據，讓體驗專家評判方案之間的優缺點，最終決策出符合用戶體驗的方案；另外一種比較是選擇兩種或者更多的產品，去研究他們優缺點，確定哪個設計方案能夠提供給用戶帶來良好的操作體驗；這兩種方案取決于項目的時間長短，如果像服務形的乙方需要快速的出方案，則更多的采用的是第二種，甲方有著自己設計研究部門可以給到部門有試錯的時間成本，那么他們更會傾向于兩者相結合的方案，我們只能提供可行性的方案，最終還是需要領導層進行拍板實施。

評估性測試

當產品進入后半段，在發布版本前后，上機進行測試，HMI 上機測試分為在室內臺架上測試，另外一種是裝機在道路上測試，不同場景的路測，在這個階段的可用的測試方法是評估性測試。評估性的可用性測試目的是確保這個產品在發布之前將潛在的問題進行修復；在版本發布之后本公司或者一些測評機構會根據自己的評測標準進行對這款產品進行評估測試，對照自己的評判標準進行打分，方便后續 OTA 升級，版本優化迭代功能。

3. 可用性測試方法

相信大家對于定性和定量這兩個詞并不陌生，在可用性測試中承擔著重要的組成部分。

定性 / 定量研究

定性研究是指參與本次車載系統的體驗者對于可用性的一個直接評估，從而產生結果，并且發現哪些功能在操縱的時候會出問題，有哪些體驗是覺得不錯的，哪些功能的體驗需要進行優化，聽完這些內容是不是覺得和車載系統的專業測評人差不多了吧，當然，在做這個定性測試的時候需要找不同的人群進行測試，需要做到完整性。

定量研究也是我們常用到的一個測試方法，定量研究出的數據對于可用性啟到了間接評估，通過參與本次車載系統體驗的用戶，觀察他們在操作事先列舉好任務上的表現狀況，這些狀況包含了本次任務完成消耗的時間、完成的成功率、錯誤點擊等；定量研究的結果是一些簡單的數據，這些數據需要有一個參考的依據，一個已知的標準，要么就是競品體驗的一個對比數據，還有一個是自己車載系統前后版本的一個對比看看改進多少（專業術語：ROI），一個詞需要找到 “參照物” 。

例如：在多少秒內操作是一個安全的范圍值？

單次交互操作動作不能超過 2 秒（1 秒內為最佳）如果一個在行駛過程中需要交互操作的動作 用時 2-3 秒就已經是一個危險狀況，所以我們參考這個依據，可以進行對我們車載系統做一個判定。

定量的數據是有了，參考標準也有了，有的功能方案是不 OK 的需要去優化，但是這些數據沒有告訴我們如何去優化它，需要在設計方案中何如去優化？定量分析研究只是記錄了一個過程中得到的數據，也沒辦法得到用戶在什么項目中遇到什么困難，比如車輛設置中的調節 ADAS 的某一個設置選項，用戶不知道在哪里尋找，我們只能記錄這項任務失敗。所以在為了更好的做可用性測試，我們通常會使用定性研究來增加進行補充缺失的部分。

如何運用定性和定量研究

前面有提到他們之間的區別，那我們在日常的工作中該如何的運用呢？在什么階段用什么研究？

在發布車載系統 1.0 版本和后續迭代版本優化 1.x 版本，可以使用定量、定性、兩者組合性來評估，如果這次評估的目的是數據方面，在這個功能點上我們優化多少，提升了多少用戶使用了這個功能，那么就需要采用定量分析，因為只有定量研究才能得出每一個版本對比上一個版本到底優化了、提高了多少。

需要針對車載系統重新設計內容時候，要通過定性的研究方法去完成，在這個過程中用戶的角色是承擔為設計提供可行性方案的人，他會覺得在哪方面可以進行優化，到得這些用戶數據和意見之后，也便于設計師們做出選擇性的優化，創建出一個新的體驗感，所以這個階段使用定性研究方式更為適合。

舉個例子：

用戶在體驗過程覺得在操作調節音量的交互感覺不好，抓住關鍵詞“調節音量體驗不好”，那么就要詢問清楚，問到用戶：“是在下拉出現的負一屏中 調節體驗感覺不好，還是在進入設置項中的去調節音量體驗感覺不好呢？因為在做定性的研究的時候不會設定怎么進入，因此會出現通過多種方式去操作系統某一個功能，所以需要針對這個問題詢問清楚，才可以正確的優化這個體驗流程。后面還需要跟進這個問題，是操作步驟過多，需要優化路徑？還是在滑動的體驗感需要加強？等這類問題，當然也可以讓體驗者去敘述他自己的點。如果同樣的去發現這類的問題，你去使用定量那么會增加很多工作成本不說，預算成本也會增加。

可用性測試實際工作內容

由于我們項目的保密性，不能透露過多內容，我將這次案例換成了其余車載系統，這次可用性測試的目的是系統評分數據

1. 設計任務

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

主要任務

用戶在使用車載系統目的有很多種類，需要聽音樂、電臺、看視頻、導航到目的地、接/打電話、調節空調/溫度等等，可能會有上百個功能點需要去操作，但一場測試不可能全功能進行測試，我們只有挑選出最重要的任務來進行測試，或者是剛上線的車載系統，需要測試一下基礎功能評測，如果遇到產品 OTA 升級或者是改動很大的版本點，會改變用戶的操作步驟，更或者是新增加的功能，都可以優先測試。

再舉個例子：

任務：調節空調的溫度

我們需要觀察的是，他是如何調節空調溫度的（我們設計師自己肯定知道全部的調節方案）

第一種方案：可以點擊導航欄下方的溫度，點擊可以進行前后拖動來改變溫度

第二種方案：按下方按鍵，呼出語音 “溫度調節到 21 度”

明確任務起點與目標

在可用性測試中最重要的就是用戶能否可以完成任務項，所以需要明確目標，如果沒有的話，就無法判斷用戶是否完成任務，我們最初設定一個目標。

例如 “在音樂界面中將播放模式調成單曲循環模式”這是我們這個任務的最終目標，只要最終用戶在音樂界面中將播放模式改為“單曲循環”即為此項任務成功完成。

給任務設置約束條件

在設定任務的時候，會出現可以多種方式去完成，上訴案例空調調節溫度，就可以使用兩種方法去完成，因此如果本次全程操作不允許用語音操作（這是作為一個約束的條件）本次的全部測試項目是關于在中控測試評估的，語音會有他自己的一套測試任務，這些都需要在任務開始前設定好的。

任務不應過于簡單

如果你想測試用戶是否找到這個功能，請不要用“找到一個 xxx 暫停按鈕”，我們需要給用戶提供一個處理現實場景中的任務，而不只是去找這個按鈕的位置，例如：“找到音樂暫停按鈕” 改為“在酷我音樂界面暫停一首歌曲”這樣會有一個明確的場景，這個場景是可以運用到現實駕駛中出現的任務，如果變成“找到音樂暫停按鈕”就屬于一個不 OK 的任務。

避免提供線索和描述操作步驟

設計任務的時候應該給出具體的目標，而不是列舉好的整個操作步驟去教用戶去完成，這個跟說明書沒兩樣。

例如：“購買酷我音樂的季度會員”。進入酷我音樂界面、點擊酷我音樂中我的、然后點擊會員中心、再點擊續費、出現彈框選擇季度充值、最后掃碼付款。用戶在接受到這些信息后，就知道先進入音樂應用、找我的、尋找充值入口、最后再進行支付。

引導性過強的話會失去任務測試的意義，這樣做會錯失用戶在操作過程中發現的一些問題，觀察員也將錯失記錄的機會，如果沒有這提前事先布置好的步驟，可能會出現一些操作讓他感覺有異議，不知道自己是否操作成功或者是是不是點錯了等等狀況。在用戶使用產品的時候，我們應該考慮使用的目標，不是考慮具體的操作步驟。我們在設計任務的時候一定要避免提供線索和描述操作步驟給到體驗者。

總結一下

針對用戶來看的話，車載系統對他們只是一個工具，達到他們想要的操作目的“比如聽音樂、導航”這些功能目的，所以在可用性測試中，我們需要把測試車載系統某個功能目的作為重點。

2. 招募人選

在招募人選問題之前，需要根據這次測試的目的和需求，確認是定性研究還是定量研究或者是組合性的研究測試方式，這次的目的是對于新系統的一個評分，這次研究方向確定好是做定量研究測試。

定量研究可用性測試是基于（30+以上人 體驗者），但也有時候定量研究也會少于 30 人，因為預算的問題，或者其他的原因無法請到這么多人，因為招募車載系統的一個體驗用戶，相對于招募去體驗 APP、網頁端產品、還是 B 端的產品，都會難很多，因為條件的限制，所處的環境也變化了，因為是有駕駛的一個狀態，還需要去操作提前布置的任務，所以在招聘人員的時候確實相對其他平臺要難。數據就會存在一些偏差。定量研究通過任務的完成率、完成時間、滿意度進行評分。這些總結性的評估數據，通常都是用于車載系統的迭代過程的跟蹤，在下一個版本中數據是否得到提高，從而達到優化的目的。

另外給大家補充一下定性研究人員選擇

定性研究用戶可以 5 人參加這場測試，就可以發現大多數（85%）的產品可用性問題，隨著用戶的增加，會發現的問題會逐漸減少，因此最終定性研究分析選定的人數需要我們去考量。

在后面的實際案例中，我們采用的是定量研究，會針對整個定量研究全案做一個詳細的解說，也會增加一些定性的來作為補充說明。

總結一下：

我們要根據實際情況來確定我們招募的用戶數量，對比每一次的測試結果于后續 OTA 升級后的效果，是否需要增加投入的預算來做可用性測試。

3. 準備工作

在做可用性測試之前需要規劃好準備的工作事宜，先是測試地點和工具的準備，后續是相關資料的準備，后面需要簽署保密協議，最后就是整個的可用性測試劇本準備。

測試地點和環境

HMI 車載系統測試場景相對于其他端的測試場景要多，這些不同測試地點和環境主要目的就是針對影響用戶操作的因素來做多方考量。

車載系統測試的地點：

路測（大馬路上，封閉路段、正常道路）、地下車庫、路面停車場、隧道等

車載系統測試的環境：

晴天、雨天、陰天、下雪天、霧霾、沙塵暴等

對于硬件的測試還會增加在不同溫度/濕度下的測試：

極寒地區、干旱地區、常年潮濕雨水多地區等等（這類測試跟設計關系不大，想普及一下）

準備的工具?

需要在測試車內裝機好需要測試的系統；安裝眼動儀來記錄用戶的觀看軌跡，便于后續優化界面設計和交互設計；還需要后排記錄人員跟拍操作錄像資料，便于后期的分析操作細節。

相關資料

首先就是準備整套測試中的任務卡片，便于用戶查看；還有要為自己準備一張表格，記錄用戶操作中出現狀態的數據，如任務是否完成、完成時間等狀態；還有一些記錄關鍵事件和測試中觀察用戶體驗的表格，比如設計中可能會出現的問題，方便結束后進行總結，加入到后面迭代版本點中。

簽署協議

在測試期間需要簽署保密協議等，因為用戶測試的是未上線的產品，為了確保項目安全起見，需要讓參與測試的用戶簽署保密協議。

劇本準備

HMI 可用性的劇本準備和其他基本類似沒有過多的出入，這個過程是：接觸用戶 →開場白 → 開始測試 → 事后訪談 →給予獎勵并送走用戶的整個過程，這些相同的劇本準備、還緊跟后面的觀察、訪談這些內容，大家都可以自行搜索，因為下面還有更重要的內容需要細講。

最后一步就是分析前面所得的數據，但需要一個標準去評估衡量，下面進入我們本篇文章最核心的部分吧。

HMI 可用性測試評估維度體系

對于 HMI 車機系統可用性測評有很多的標準，我們對 Thoughtworks 的度量標準進行了分析學習，根據前面的可用性測試原則，最終得出評估的三個維度：視覺行為表現（Visual Behaviors）、HMI 軟件任務表現（HMI Task Performance）、主觀感受（Subjective Feelings），這測試的體系主要針對的是動態測試下的 HMI 車機系統可用性測試的標準，靜態測試（注：靜止狀態下、車輛未啟動狀態下的操作）任務還會有另外一套測量體系的標準。

1. 視覺行為表現（Visual Behaviors）

視覺行為表現的二級維度是視線離開路面的時間，因為這個維度是針對→完成任務是否是在安全時間內的一個評估標準，這一項是至關重要的，HMI系統在設計方面一定要遵循安全的設計原則。

評估它的指標是用戶在車機單次掃視時長，車機總掃視時長，為什么會增加這一個評估指標呢，因為有些任務不是單次掃視就能完成操作的，比如在中控上面調節音量大小，我們項目中有一個定義是在絕大數頁面當中，在空白區域左右滑動就可以改變音量的大小，所以這項任務測試數據中交互手勢是表現相對較好的。當然還有其他方式→第一步：下拉交互手勢，將負一屏滑動下來；第二步：找到調節音量大小的滑塊進行調整音量大小。這個交互方式和其余的車載系統是基本相似的，所以在整體考量方面，在中控調節音量大小是一個比較危險的操作，因為總時長較長，甚至單次掃視的時間也有過長的一個情況。

2. HMI 軟件任務表現（HMI Task Performance）

HMI 軟件任務表現的二級維度是有效性和效率，這方面測試用戶的一個任務完成度情況。

有效性的評估指標是任務的完成率和人均錯誤次數 ，這兩個數據是指測試的任務是否成功完成了，在操作這個任務的時候用戶犯了幾次錯誤最終才完成的任務。設定一個任務：完成“搜索找周圍加油站”，操作狀態：靜止狀態下（非駕駛狀態），操作限制：中控屏幕內操作。通過這些條件得到不同的數據。類似這種任務，我們可以做多種不做任何限制狀況。

得出的結論是：

語音操控下最優，完成率和人均錯誤次數較低，錯誤的就是有些地方的方言無法識別，其余都可以正常完成；在中控屏幕中操作，只有在非駕駛中可以完成任務，在中控屏幕操作中需要很多步驟，1.首先進入導航頁面，2.進入導航頁面后，有不同的操作路徑可以進行搜索加油站，第一個直接在輸入框中搜索加油站，第二個就是在下方有加油站的 icon，可以直接查找，在第一次使用我們產品的用戶，絕大多數都是進行第一種方案。

最后數據比較非駕駛中完成任務率和人均錯誤次數遠低于駕駛狀態，因為駕駛狀態下完成這類任務時間會增多，并且駕駛中不可能長時間定于屏幕。其實現實場景中，在駕駛中搜索加油站的場景會偏少，所以更推薦用戶多運用語言進行搜索完成任務，如果不習慣語言交互，那么請在非駕駛狀態下進行操作中控屏幕。

效率的評估指標是完成時長 ，通過上面的案例我們也可以直觀的看出語音交互搜索加油站完成的時長是最短的，因此他在效率上也是最高的，語音交互也分為駕駛狀態和非駕駛狀態，效率也是不一樣的，非駕駛狀態效率要高于駕駛狀態，因為駕駛狀態下去掃描屏幕信息難度要高于非駕駛狀態下的。其次就是靜止狀態下的操作中控屏幕效率也要高于駕駛狀態下操作。排個序不同場景在不同的交互方式，非駕駛狀態語音交互 > 駕駛狀態語音交互> 非駕駛狀態中控操作 > 駕駛狀態中控操作。

3. 主觀感受（Subjective Feelings）

主觀感受的二級維度是綜合感知負荷 ，事物通過感官在人腦中的直接反應，感官這一個詞大家也許會感覺還是有些陌生，HMI 車載系統交互中從視覺、聽覺、嗅覺、觸覺以及味覺等方面的感官交互，也就是通過眼睛、耳朵、鼻子、嘴巴以及皮膚觸摸實現，圍繞這些感官進行設計的，這些對用戶直觀的感受都需要記錄下來，作為對于后續優化系統作為研究內容。

綜合感知負荷的評估指標是感知腦力負荷，這個詞想必大家也沒咋聽說過，我簡單介紹一下，從任務和個體兩方面出發，腦力負荷中的任務和執行任務的個體均相關。在同一任務中，不同的用戶所感受到的腦力負荷仍可能不同，用戶自身的情緒、動機、策略及個人能力都可能影響到腦力負荷。從信息處理能力的角度出發，將腦力負荷定義為: 用戶在執行某項任務時對所應用的“信息處理能力”的大小，可以通過測量其“信息處理能力”來直接度量其腦力負荷的大小。一共有兩個因素來決定，一個方面是“時間占有率”，時間占有率是指完成某項車載任務過程中用戶的最低處理時間。“時間占有率”越低，則腦力負荷越低，“時間占有率”越高，則腦力負荷越高；另一個方面是“信息處理強度”，信息處理強度是指在單位時間內需要處理的信息量或者處理信息的復雜程度，“信息處理強度”越高，則腦力負荷越高，反之則相反，有點難理解的話還是多看幾遍吧。

腦力負荷的測評方法主要包括: 主觀測評方法、作業績效測評方法、生理測評方法以及綜合測評方法，關于這些維度的后續我們在詳細探討。

4. 給大家開一個小灶

本想這個留著后面慢慢講的，但是已經談到這個專業領域的知識，我又沒收住，就簡單的給大家提一嘴，后期還會單獨針對這一塊做深入的探討。上面談到腦力負荷，那我們設計 HMI 車載系統的時候，該如何降低腦力負荷呢？

從視覺、認知、操作三個角度出發減少腦力負荷

視覺：

是指 HMI 車載系統的界面信息視覺復雜程度，減少視覺負荷，需要做到信息功能更加精煉、主次分明等要求。根據調查：人對產品的第一印象是在 0.5s 秒形成的，有一點要知道：為了降低視覺負擔，不是設計的很簡單就完事了，駕車環境和其他產品不一樣，對于視覺要求較高，因為用戶每盯屏幕多 1s 鐘，就會多一分危險，所以在設計的時候不能將其他端的設計照搬硬套，減少用戶閱讀的信息，簡化信息內容等。

認知：

是指用戶對于 HMI 系統界面的理解、思考的腦力消耗，交互設計中有一條原則：不要讓用戶做過多的思考，不要增加用戶的認知負荷。在設計 HMI 車載系統的時候，視覺設計和交互設計要保持全局的一致性，HMI 車載系統的設計和其他端也不一樣，APP 端要將這個行業的框架結構要一樣，所以大家看到淘寶、京東、網易嚴選、蘇寧易購等購物平臺 APP 首頁的框架都是一樣的，從而降低用戶認知成本，這個是行業的一致性。

但是大家可以看到車載系統，每家的定義都有差異化、也有相同點。比如小鵬、蔚來、特斯拉都是以導航為首頁，理想 ONE、五菱星辰首頁的設計方式是以卡片為主，所以在于車載系統中的一致性是在自己本產品中體現，視覺、交互的一致性，不能做過多、過于復雜的交互方式。

視覺的一致性就體現在的通用顏色，比如導航模塊中的交通擁堵的顏色，深紅色為極度擁堵路段、紅色代表堵車、黃色代表緩行路段、綠色代表暢通路段，這個只能在一個顏色系列下微調，不能做大幅度改動，但這個還需要按照每一個國家的定義來，有一些國家對于顏色定義有著自己的要求，所以在做海外導航的小伙伴們要時刻注意下。

操作：

是指用戶移動頭部、手臂、手指來點擊觸碰 HMI 車載系統，如何做到減少操作負荷。下面從軟件層面和硬件層面來講講：

針對軟件方面的優化：

交互內容面積越大越容易操作；交互的內容應該偏向于主駕駛便于操作的區域，距離主駕駛越近越好；與其他交互手勢、方向避免沖突；點擊的交互方式易用性強于長按和雙擊，但車載系統有的地方還是需要用到這些其他交互方式，全局做到盡量少用，放大地圖之類也需要延續雙指交互手勢等；單指交互優于多指交互。

針對硬件方面的優化：

對于硬件操作的優化，沃爾沃汽車將主駕駛屏幕做了傾斜，對于主駕駛是方便操作，唯一的缺點就是不可以挪動，他是完全鑲嵌進去的，如果副駕駛需要鏈接手機藍牙到車上面，對于副駕駛的觀感就不太友好了。這一點新款的特斯拉 S/X 系列做的很到位，他可以將屏幕左右的傾斜，在設置項中可以選擇屏幕的調整，針對操作這一點優化相當不錯的，我在其他平臺看到有的車主在特斯拉 model 3 改裝了屏幕，將固定的屏幕改裝成左右上下都可以移動的屏幕，動手能力超強，給車主點個贊。

總結

本篇文章是HMI車載領域的可用性測試，但其他領域的設計師們也可以有學習的內容。