在產(chǎn)品的日常工作中有一塊是在對接用研，在工作中對可用性測試、A/B測試、主觀體驗的一些想法零零散散記錄在印象筆記里，這次稍微整理下對可用性測試的零散記錄，算是給自己做個階段性的備份。
可用性測試是什么###
就個人理解，可用性測試就是把最小成本制作出來的原型，給目標用戶在模擬的真實場景中去完成測試任務(wù)，然后通過觀察發(fā)現(xiàn)目標用戶在使用場景中遇到的問題，或者驗證預期的假設(shè)問題。
可用性測試的優(yōu)點###
可用性測試操作便捷、成本低，不用進入產(chǎn)品的開發(fā)測試階段，通過簡單的原型就可以驗證產(chǎn)品設(shè)計。如果產(chǎn)品都開發(fā)成型，那明顯是灰度上線、A/B測試、數(shù)據(jù)分析等方法更符合要求。（摔~~~(╯°Д°)╯︵ ┻━┻ 這特么明明是所有用研方法的優(yōu)點嘛！）
什么時候用可用性測試###
可用性測試一定是在產(chǎn)品功能上線前所用的測試方法，一般而言可用性測試主要應用在以下三種情況中：
- 某功能設(shè)計之前沒有經(jīng)驗，交互與產(chǎn)品都拿不準，并且也沒有現(xiàn)成的相似產(chǎn)品做參考，不清楚真實使用中會有什么深坑；
- 功能的幾種設(shè)計方案均有明顯的弊端，無法評判哪種更優(yōu)；
- 團隊出現(xiàn)歧義，用所謂客觀的測試結(jié)果說服團隊成員接受該設(shè)計；
前兩點是可用性測試的主力場景，如果設(shè)計囿于前兩種情況，那還有什么可猶豫的？
第三點看起來明顯是最扯淡的，但在很多團隊中卻恰恰是出現(xiàn)最多的?，F(xiàn)在可用性測試越來越被重視，也可以說是越來越被濫用。就是因為可用性測試、A/B 測試、數(shù)據(jù)分析……這類所謂客觀的方法論是最好的說服工具，團隊成員更愿意相信這些，而不是某個人的言辭。
而在我看來，產(chǎn)品及交互最重要的價值體現(xiàn)就是利用自己的經(jīng)驗去做需求及設(shè)計方案的決斷。所以在個人對這個設(shè)計權(quán)衡利弊考慮的非常清楚的時候，一定要主動應戰(zhàn)，PK掉這些來自團隊的質(zhì)疑。個人的說服能力與在團隊的影響力本身就是很重要的一項能力，有這種機會一定要通過言辭的解釋讓大家信服。
若團隊中有成員勉強接受你的設(shè)計，在上線后一定要將該設(shè)計的數(shù)據(jù)表現(xiàn)及時同步給大家，無論你的設(shè)計是否達到最初的預期，這都是對彼此的尊重，后續(xù)的協(xié)作會得到更多的信任。
可用性測試注意事項###
1. 測試任務(wù)的目標唯一性#####
每次可用性測試任務(wù)確保有且只有一個目標，千萬不能因為甲測試任務(wù)流程中可以再順帶添加乙任務(wù)，而在設(shè)計甲任務(wù)的時候把乙任務(wù)參雜在中。如果二者均有需要，一定要拆分成兩個任務(wù)去測試，而不要期望一個任務(wù)流程去達成兩個目標。
因為就經(jīng)驗而言，如果測試任務(wù)的目標不唯一，經(jīng)常會受到其他因素的干擾而影響到測試的結(jié)果。并且對于測試人員來說，記錄掌握用戶的反饋也不方便。
2. 測試任務(wù)的描述要委婉#####
測試任務(wù)的描述盡量婉轉(zhuǎn)、場景化，也就是要讓用戶對你的任務(wù)描述有自己大腦的轉(zhuǎn)意過程，而不是依照字面所述去機械操作。
比如測試輸入法的顏文字表情自定義功能，測試任務(wù)描述不能描述成“復制對話框的顏文字表情，找到顏文字自定義按鈕進行粘貼添加”，而是應該盡量描述成“和閨密聊天，她發(fā)來一個萌死的顏文字，你非常非常喜歡，但是發(fā)現(xiàn)你的輸入法中還沒有這個顏文字，你該如何添加到你的輸入法顏文字表情中呢？”
3. 用戶及場地的選擇#####
用戶選擇上貴在精而不在于多。情愿找少量的真正目標用戶，而不必追求用戶數(shù)量。如果僅僅只是追求數(shù)量，反而給測試帶來大量不真實的信息，影響最后的結(jié)論輸出。
而測試場地的選擇一定要與產(chǎn)品使用的真實場景相同，比如測試輸入法的單手模式功能，一定不能僅僅是在辦公室里強迫自己單手使用大屏手機進行測試，而是需要進到真實場景中，比如：站在擁擠的公交車上，一手扶著把手，一手拿著手機完成測試任務(wù)。
4. 注意測試中的溝通細節(jié)#####
用戶在進行測試的過程中，一定會和測試人員進行溝通。在測試開始前，測試人員可以與測試者閑扯，調(diào)和下測試氣氛，便于測試者卸下防御機制，更利于其進入真實使用狀態(tài)。
而在測試過程中，測試人員應該盡量扮演NPC的角色，按部就班推進測試過程，默默的在旁邊觀察、記錄用戶的使用細節(jié)，少談?wù)撘恍┮龑缘钠脝栴}。
比如諸如此類的言辭“你為什么不點擊這個按鈕，是因為顏色不顯眼嗎？”、“如果這個功能入口放在前面，你是不是就容易找到了”……在測試過程中是一定不要出現(xiàn)的。如果有必要問，一定要在測試任務(wù)完成后，一并向用戶咨詢或者通過事先準備的問卷去了解。
同時用戶在任務(wù)測試過程中，若遇到了操作困難，可以多安慰鼓勵用戶，而不要直接給予用戶指向性的引導。這些舉動會干擾到測試的真實結(jié)果。
5. 多注意用戶的操作反饋#####
在測試過程中，多注意留意用戶真實的操作反饋，而不是聽用戶在說什么。由于用戶心理保護機制作祟，造成他說的話是不可靠的。而他的操作行為與操作時的下意識反饋，是無法掩飾作假的。在測試過程中主要就是觀察用戶的操作反饋，而不要被他言語所迷惑。
如果有條件，測試的整個過程可以進行多機位的視頻錄制。比如手機端的app測試就可以有兩個機位，一個機位記錄用戶手部操作屏幕，一個機位記錄用戶正面的肢體及表情反饋，這樣更便于后期分析。
6. 不要拘于形式#####
可用性測試沒必要每次都那么正式，拘于形式流程。有時候在沒有指定目標用戶時候，順手拿競品與自身產(chǎn)品某一項設(shè)計上有差別的小功能，在公交上問下鄰座哥們、在聚會上問下朋友，這樣也可以達到測試目的。
可用性測試的形式是靈活的，而結(jié)果的導向性也是明確的。無非也就是讓產(chǎn)品與交互人員不要糾結(jié)于自己固有的思維圈子中，更多的要關(guān)注真實用戶的使用反饋。
所以經(jīng)常經(jīng)過可用性測試發(fā)現(xiàn)團隊成員糾結(jié)來糾結(jié)去的地方，真實用戶是根本不在意，或者根本沒留意到。這算不算是種諷刺，23333333
