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