編輯導(dǎo)語：可用性測試，能夠讓產(chǎn)品經(jīng)理借助用戶，更加客觀理性地理解產(chǎn)品功能以及交互，并結(jié)合測試結(jié)果予以改進(jìn)。每個產(chǎn)品的迭代都需要進(jìn)行可用性測試，可以說“可用性測試”是交互設(shè)計中進(jìn)行驗證必不可少的環(huán)節(jié)。本篇文章分享了一些不一樣的“可用性測試”技巧，希望對你有所幫助。

之前群里的設(shè)計師提起了可用性測試，說面試的過程中被問到了，其實它的流程跟方法并不難，網(wǎng)上的教程資源也不少，很多參與過或了解過的人即使沒有主導(dǎo)過卻也能說個一二。

哪這門蘊含科學(xué)的測試研究方法真就這么簡單? 借著這個機會結(jié)合個人的一點小心得，來聊一點不一樣的“可用性測試”技巧。

一、可用性測試的應(yīng)用場景與作用

可用性測試(Usability Test)的應(yīng)用場景是沒有行業(yè)的明確界定的，它一般發(fā)生在產(chǎn)品研發(fā)上線的前中期，在功能或交互流程有待商榷之時，通過可用性測試可以獲得更加真實的反饋來幫助決策或改進(jìn)。

當(dāng)然已上線的產(chǎn)品，同樣可以使用可用性測試為下個版本優(yōu)化迭代做投資。

其中探索式跟驗證式是常見的兩個可用性測試類型，探索式適合企業(yè)對產(chǎn)品進(jìn)行創(chuàng)新設(shè)計以迎合新時代發(fā)展的步伐與商業(yè)競爭力，驗證式適合企業(yè)追求精益運營或增長設(shè)計。

對于可用性測試的概念，這里我用一段類比的情景來揭示出其中奧妙。

做好一個飯館，而菜品必定是館子的核心競爭力之一，菜不好吃，那就很難形成競爭力或留住客人，所以開發(fā)新的菜品或改進(jìn)就很重要。

當(dāng)廚師開發(fā)了新的菜品后，首先肯定是廚師們互相品嘗，并不會直接上菜譜開售，這就像是內(nèi)測過程，當(dāng)廚師們覺得還可以時，就會找食客們進(jìn)行免費試吃，通常這個時候廚師們需要食客們給出反饋或一定意見，如果食客們大多表示這個菜不錯，下次還愿意吃，那么就是表示這個新菜品的可行性很高，用戶滿意度不錯，就可以考慮對菜品優(yōu)化上菜譜了。

而這個過程就像可用性測試一樣，它為新菜品上菜譜降低了風(fēng)險，為菜品對菜館整體體驗提升了保障，其中“菜館的食客”就像是測試的目標(biāo)用戶，請求他們嘗試新的菜品并給出意見，這便是招募用戶和測試階段，詢問食客是否還會再點這個菜品，覺得這個菜品在什么價位區(qū)間，就算是對用戶滿意度或可行性衡量了。

相比專業(yè)可用性測試，只是少了更多的測試流程、測試技巧與科學(xué)嚴(yán)謹(jǐn)?shù)姆治鰠R報，但是基本概念是一致的。

但值得注意的是針對單個菜品的研究并不是面向整個菜館的，可用性測試很少用于研究用戶對產(chǎn)品或服務(wù)的整體體驗。

所以可用性測試的本質(zhì)就很好理解了，以互聯(lián)網(wǎng)產(chǎn)品為例，其實就是服務(wù)數(shù)字化后的功能與流程含有不確定性，而決定找到目標(biāo)用戶還原使用場景進(jìn)行測試驗證，以評測設(shè)計是否行得通、哪里需要改進(jìn)，為功能上線減少風(fēng)險加強容錯，減少試錯的成本。

二、高保真原型與測試場景還原

要測試就得有測試內(nèi)容，所以測試對象是必不可少的內(nèi)容，這個過程是我們還原真實用戶在特定場景下進(jìn)行產(chǎn)品體驗的一系列問題反饋，那么為了盡可能的還原“真實”，肯定不能只是在用戶的真實性上下功夫，接近真實的高保真原型就顯得尤為重要。

以互聯(lián)網(wǎng)產(chǎn)品來講，還原一個可交互的高保真原型并不難，成本也不會很高，可能就是信息內(nèi)容設(shè)計與素材準(zhǔn)備會相對麻煩點，對于交互動效，基本可用就行，不必過分追求。

并且實現(xiàn)的工具也很豐富，對于大型框架原型可以使用“墨刀、MasterGo、AxureRP”等制作，小型精致的原型可以使用“Principle、Hype3、Flinto、Sketch、Keynote”等制作。

反而是工業(yè)產(chǎn)品設(shè)計的原型會比較麻煩，有的可能要出3D打印甚至開發(fā)測試樣品，盡管這些工作會花費一定的時間與成本，但是從產(chǎn)品穩(wěn)健發(fā)展的戰(zhàn)略來看，這些投資是值得的，也是老板們可以接受的。

在大多數(shù)的可用性測試文章或教程中，用戶都是在一個相對降噪的會議室或?qū)嶒炇疫M(jìn)行的，其目的是為了更好的布置設(shè)備用于過程的觀察與記錄，同時為用戶測試減少干擾與評估難度（其實也省錢），但事實上還原產(chǎn)品服務(wù)的真實場景是很有必要的，并且一些產(chǎn)品服務(wù)自身就會含有一定的場景屬性，所以你的測試環(huán)境就應(yīng)該考慮接近真實場景的布置，甚至考慮跳出會議室、實驗室。

這樣的目的也是為了更加真實的還原使用場景，以取得更嚴(yán)謹(jǐn)科學(xué)的有效信息來賦能設(shè)計，這也是為什么大多數(shù)產(chǎn)品需要上前線測試的原因，就像藥品誕生于實驗室，上架于臨床一樣，例如出行、運動相關(guān)產(chǎn)品，如果依舊停留在寫字樓里測試實驗，那就是閉門造車。

三、任務(wù)與指標(biāo)定制化設(shè)計

產(chǎn)品的本質(zhì)是為用戶提供服務(wù)，用戶會為了達(dá)成自己的某個目標(biāo)或需求而花費時間使用產(chǎn)品，而我們需要用戶測試一系列功能來評測是否能夠協(xié)助完成目標(biāo)任務(wù)。

所以我們在設(shè)定不同任務(wù)的時候應(yīng)該以某個用戶需求或目標(biāo)為導(dǎo)向來驅(qū)動用戶使用產(chǎn)品功能，而不是系統(tǒng)的指出完成那些操作任務(wù)，那樣沒辦法深入挖掘真實有效的信息。

所以在向用戶頒布測試任務(wù)的時候，我們應(yīng)該為用戶建立一些任務(wù)背景，并且盡可能看起來真實可靠，容易接受和共情，甚至你可以在測試前的暖場環(huán)節(jié)，根據(jù)此次的功能作用推導(dǎo)一些使用場景和需求，并與用戶進(jìn)行簡單交涉，看看那些需求很有可能發(fā)生在用戶身上，并以此需求目標(biāo)來調(diào)整任務(wù)的話術(shù)來驅(qū)動用戶完成測試。

值得注意的是如果測試的部分比較明確，那么你的任務(wù)目標(biāo)也應(yīng)該盡可能的聚焦或明確下來。

好了，為了方便理解我要說人話了。

（1）重點補充

因為在整個測試的過程中，參與測試的用戶不止一個，所以在了解用戶情況后，可以綜合一下共同的特征再去提煉優(yōu)化任務(wù)目標(biāo)，以保證在多個參與者中維持評估的一致性。

并且任務(wù)目標(biāo)應(yīng)該盡可能的準(zhǔn)確有效，我們是要測試新的拍攝識別功能，那我們就應(yīng)該要求出來，而不是說看完書后使用APP的筆記并嘗試各種功能支持，產(chǎn)品或功能所沒有的就不要提。不保證有效性，最后也只能讓用戶感到困惑而已。

通常完成測試任務(wù)的過程中，會涉及到多個功能之間的交互，所以任務(wù)目標(biāo)涉及的多個階段應(yīng)該貼合實際的操作順序或流程規(guī)范，另外盡可能的避免專業(yè)術(shù)語的出現(xiàn)，務(wù)必考慮“適老化”一下。

（2）關(guān)于指標(biāo)定制化

通常在可用性測試中，是否可用的指標(biāo)被劃分成了三大面：有效性、任務(wù)效率、滿意度，對于這三方面我們可以繼續(xù)細(xì)化成若干個二級指標(biāo)用于界定產(chǎn)品可用性。

至于你家的產(chǎn)品是什么行業(yè)、什么階段、什么用途、有何特性，應(yīng)該滿足哪些指標(biāo)為可用，我就不深入了，相信大家心里都有數(shù)。

簡言之核心就是考慮產(chǎn)品的特性與階段，靈活的配置可用性的指標(biāo)，這里整理了些常見的指標(biāo)與說明用于參考。

四、用戶測試中常見的問題

盡管我們有測試腳本甚至測試排練，已經(jīng)盡可能的保障了可用性測試的穩(wěn)定可靠，但實際上在用戶測試的階段還是會出現(xiàn)各種問題，用戶像一個熟睡的嬰兒，何時醒來何時哭泣不可預(yù)見，所以這就要求測試的主持人能夠靈活變通，同時在技巧上符合可用性測試的科學(xué)嚴(yán)謹(jǐn)。

可用性測試過程中的科學(xué)嚴(yán)謹(jǐn)一方面體現(xiàn)在方案的合理性、測試主持的技巧上、及評估分析量化的方法上，這些大多可用性測試的文章或教程中都會提到，這里就不展開啰嗦了。

常見問題舉例：

1. 他似乎在想些什么但是沒有說出來？

你在想什么可以分享一下嗎？

2. 用戶好像卡住了或遇到bug了。

這沒事兒，是我們產(chǎn)品設(shè)計的問題，你可以考慮跳過這一步好了。

3. 就是這個，它怎么就那啥了？表述不清。

你剛剛打算做些什么，如果是你，你準(zhǔn)備怎么去設(shè)計？有沒有一些參考。

4. 然后我要怎么做呢？

對于用戶提問說明遇到了障礙，嘗試反問你平時會怎么做？

5. 用戶反饋了一些趨勢或點子，看起來很有價值。

嘗試深挖，順著點子或趨勢向用戶多問一點，但是不要直接問“為什么”，可以嘗試問好在哪里或者哪里不好，讓問題更有頭緒一點。

以上不難看出，即使有了腳本，但是用戶依舊是一個變量因素，所以腳本依舊需要不斷調(diào)整，也只有去調(diào)整才能更好的保障測試結(jié)果的有效性，同時主持者也需要隨時準(zhǔn)備靈活的應(yīng)對各種幺蛾子。

五、創(chuàng)新與顛覆性設(shè)計如何測試

可用性測試被很多人視為評估體驗的制勝法寶，但實際上很多產(chǎn)品在行業(yè)中已經(jīng)逐步成熟，并有大企業(yè)花費大量資源進(jìn)行研究摸索，讓生態(tài)系統(tǒng)更進(jìn)一步，所以說要是你的產(chǎn)品沒有特殊的創(chuàng)新或瓶頸，而是傳統(tǒng)的功能研發(fā)，其實并不一定要花費成本去做可用性測試，直接按照行業(yè)標(biāo)桿也是沒問題的。

那么你的產(chǎn)品就是有創(chuàng)新或顛覆性設(shè)計怎么辦？

通常這個時候就會面臨一個問題，打破傳統(tǒng)或者顛覆用戶的常識。類似這種顛覆式或創(chuàng)新技術(shù)其實非常多，例如按鍵手機一下到了觸屏?xí)r代、智能駕駛、語言助手的誕生、刷臉支付等，這對企業(yè)是機會也是風(fēng)險，所以在進(jìn)行可用性測試的時候也會有些不大一樣的地方。

我們悉知在可用性測試的三大指標(biāo)中就有一項是“效率”，對此也會有一些完成任務(wù)的時間作為指標(biāo)，這些指標(biāo)通常是根據(jù)內(nèi)部人士或?qū)＜彝瓿扇蝿?wù)的時間乘上2倍或者更多倍做為一個評測指標(biāo)。

但是對于顛覆性的變化，我們需要給用戶首次測試留出更多的時間去學(xué)習(xí)去適應(yīng)，在此之后，可以讓用戶再進(jìn)行1～2次的測試，并且比較多次任務(wù)完成的時間變化，如果時間能夠大幅度縮減且完成任務(wù)，那就表示可用，而這樣做也是為了保障測試的科學(xué)嚴(yán)謹(jǐn)性，以避免學(xué)習(xí)門檻對創(chuàng)新性的評測影響。

六、多版本Battle你需要小型可用性測試

可用性測試需要招募用戶進(jìn)行測試，預(yù)算時間精力可謂一項都不能少，但是大多公司的窘境卻是公司小資源又有限，又不給預(yù)算招募，可用性測試做不起來？內(nèi)部產(chǎn)出版本過多，不知何去何從？別擔(dān)心，小型可用性測試了解一下！

1. 什么是小型可用性測試(Small Usability Test)？

小型可用性測試就是在標(biāo)準(zhǔn)的可用性測試的基礎(chǔ)上減少了一些流程與要求，這就像是大公司與小公司之間會有各自的研發(fā)流程一樣，兩者各有千秋，對應(yīng)公司規(guī)模與背景對癥下藥。

在小型可用性測試中，也有腳本、簡易的暖場、用戶定義、測試目標(biāo)、測試任務(wù)、測試原型、測試參與者、測試觀察、思考總結(jié)，更多的也是發(fā)生在功能上線之前的推敲階段，它比較適合設(shè)計師在自測階段后的驗證以及多版本Battle，幫助你Pick一套更加合適的方案。

但是整個過程相對正式可用性測試會更加簡單易行，其中價值觀念與目的都是一致的，都是以用戶價值與用戶目標(biāo)來驅(qū)動（使用動機）使用產(chǎn)品，并且觀察用戶的使用過程以獲取有效的反饋來改進(jìn)或決策。

不過呢，腳本會更加簡易一些，原型材料也不用那樣精細(xì)，主要能表達(dá)功能作用與信息流程為主，其中測試者更多的是尋求那些關(guān)心我們產(chǎn)品或有需求的用戶，另外也不會準(zhǔn)備那些知情書、協(xié)議、錄制設(shè)備、測試指標(biāo)啥的，更多的是尋求熟人或哪些有意向的用戶快速進(jìn)行測試并觀察，這樣不僅時間成本都節(jié)省了，難度降低了，也能拿到一定的有效測評結(jié)果。

基本上主要的實踐步驟就這五點，還有一些布置會穿插在其中，后面代入案例講解一下。

2. 案例代入講解

便于直觀的了解和感受小型可用性測試，這里代入一個老案例講解一下，關(guān)于案例背景這里簡單交代一下。

（1）背景

平臺服務(wù)于游戲相關(guān)的訂單交易、互動娛樂，本次測試的內(nèi)容是新的游戲訂單定制服務(wù)，通過推出一批專供用戶定制游戲服務(wù)的客服來完成溝通與定制下單，其價值在于幫助用戶快速了解平臺游戲服務(wù)以及快速定制服務(wù)并完成下單轉(zhuǎn)化，以溝通的方式減少用戶下單的操作流程與門檻。

（2）任務(wù)流程

設(shè)計服務(wù)入口與流量分發(fā)->用戶選擇心儀的小魚（專供客服的代稱）->進(jìn)入小魚的會話界面->溝通需求目標(biāo)->小魚制定用戶專屬服務(wù)訂單->用戶支付確認(rèn)->轉(zhuǎn)到訂單流程

為了加快講解和體現(xiàn)測試的價值與方法，這里就不跑全套流程了，就以小魚入口的設(shè)計與流量分發(fā)來代入講解，測試前提是聊天會話界面中已經(jīng)集成了“小魚”所受理的主要游戲業(yè)務(wù)介紹，以及快速下單的入口。

當(dāng)然一般都是在用戶向“小魚”傾述目標(biāo)需求后，由“小魚”進(jìn)行服務(wù)定制，并向用戶發(fā)起訂單等待用戶確認(rèn)支付，之后便是等待訂單完成到驗收評價，平臺轉(zhuǎn)交傭金。

（3）首先定義用戶與目標(biāo)

在這個測試任務(wù)開展前一定要知道開展目的是什么，然后就是這個過程中你的功能或產(chǎn)品是為什么樣的人服務(wù)，能為他們帶來什么樣的價值，也就是前面一直提到的價值與目標(biāo)驅(qū)動用戶的概念。

為此你可以建立一個簡易的用戶原型來定義用戶的特征屬性，使得目標(biāo)群體再具體一些。

然后將小魚的服務(wù)價值寫出來，讓參與者能夠快速知道小魚功能有什么用：

（4）創(chuàng)建適用于目標(biāo)的測試任務(wù)

對于測試任務(wù)的創(chuàng)建，應(yīng)該是圍繞目標(biāo)的。

根據(jù)流程的多少或復(fù)雜程度，可以劃分為多個階段，這樣具有階段性會更好控制測試節(jié)奏或分段進(jìn)行，然后就是將多個任務(wù)按照流程順序或是操作難度排序，目的是使得任務(wù)流程正確或是用戶接受起來更容易。

當(dāng)你把任務(wù)清單羅列出來后還不算完，這套清單你可以放在腳本里，但是當(dāng)你描述給用戶時，你應(yīng)該代入對方視角去描述并且?guī)в心繕?biāo)性，所以還需要進(jìn)行一次調(diào)整后應(yīng)用：

（5）找到合適的測試參與者

關(guān)于參與者我們會參考第一步中所設(shè)定的用戶原型，不需要全部中標(biāo)，但至少這些人要看起來會用得上你的產(chǎn)品才行，通常這些人建議通過熟人關(guān)系去尋找，甚至可以是你的同事，只要他們對產(chǎn)品沒有額外的偏見，且不是相關(guān)設(shè)計者、營銷運營者或技術(shù)研發(fā)人員，因為這些人對該領(lǐng)域的知識掌握甚多，有失真實性。

當(dāng)你找到這五六個接近真實用戶的參與者后，你只需要將起初寫下的“功能價值闡述”告訴他們，讓他們知道要做一個怎樣的服務(wù)測試，然后預(yù)約他們在不同的時間節(jié)點上花費半個小時來做一個簡單的功能測試即可。

（6）觀察參與者如何執(zhí)行任務(wù)

在這個階段，你需要保證已經(jīng)準(zhǔn)備好了測試原型，以及一份腳本，腳本中會規(guī)范以上的功能價值、測試任務(wù)、一些簡易的指標(biāo)、關(guān)注要點、暖場介紹、流程順序等。

然后你要找一個相對安靜低調(diào)的測試場地，不一定是會議室，不用很大空間，一個桌子兩個椅子和一些必備的材料即可，但不要有一些產(chǎn)品相關(guān)或商業(yè)的痕跡，會形成干擾。

在測試開始前你需要將測試原型初始化，以確保每個參與者測試的一致性。

在暖場和任務(wù)布置完成后，就是測試者的Show Time了，主持者可以拿好自己的小本本或者錄音筆，認(rèn)真的觀察測試者的操作或口述反饋，當(dāng)測試者遇到一些問題不知所措時，也不用著急指導(dǎo)，告訴測試者先按照自己的認(rèn)知或想法去做就好。

如果測試者在一個地方卡了好幾分鐘，沒有一點頭緒甚至感到受挫那就讓測試者先跳過障礙，避免整個測試節(jié)奏失控。另外記得提醒測試者口述反饋，這很重要。

當(dāng)在計劃的時間段完成測試后，就為測試者送上準(zhǔn)備的獎品，寒暄幾句后送測試者去休息或離開，然后對材料或記錄進(jìn)行簡單整理后，準(zhǔn)備下一場測試。

（7）思考與總結(jié)

在完成一輪簡單的小型可用性測試后，通常一定會拿到一些有用的反饋，可能有些零散還需要進(jìn)一步的整理，但這不影響最后的分析結(jié)果，為了方便驗證和整理，我們會提前把一些重要的問題點羅列出來，然后根據(jù)測試者的反饋進(jìn)行記錄歸檔。

最終當(dāng)你完成了這些測試及反饋信息收集以后，產(chǎn)品方案中究竟哪里出了問題應(yīng)該就了解的差不多了，一些比較明顯的問題甚至?xí)粶y試者多次提及，或許是頁面信息不被理解、交互難懂、提供的內(nèi)容不受測試者喜愛，亦或是測試者都認(rèn)可、設(shè)計亮點被用戶親睞。

盡管會發(fā)現(xiàn)一些跟我們預(yù)期不大一樣的結(jié)果，但都是正常的，值得注意的是，我們應(yīng)該結(jié)合這些數(shù)據(jù)進(jìn)一步的反思，究竟這些反饋有何含義有何價值，哪里還能優(yōu)化，基于不用的產(chǎn)品服務(wù)或受眾，反思點可能會有些不同，這里我泛舉一些；

最終呢，我們也是通過測試取得一些有效的反饋，并根據(jù)反饋深思了更好的設(shè)計方案，我們對小魚卡片的信息進(jìn)行了豐富以保證可比較性，將每批三個小魚卡片擴展到了8個，用戶可以通過橫向滑動查看更多，同時為了方便用戶更好的換到下一批，在最末尾給予了滑動換批次的交互，使得用戶可以一指滑動到底完成查看與換批次的交互銜接，在之后的驗證測試中也是獲得了測試者的認(rèn)可與看好。

相信說到這里，怎么做好一輪小型可用性測試已經(jīng)了解了，當(dāng)你完成了這些測試任務(wù)，一定記得不要忘了后續(xù)的反思與優(yōu)化迭代，甚至制定后續(xù)的研究計劃。

七、多版本方案如何可用性測試

有時候設(shè)計產(chǎn)生多個版本也是在所難免的，那么對于多方案是應(yīng)該將內(nèi)部推薦的拿出來測試，還是應(yīng)該直接兩個版本一起拿出來，兩個一起會不會因為采集量過少不準(zhǔn)確呢？

這里我們再說說有多個版本怎么做好測試計劃與分配，當(dāng)有多個版本準(zhǔn)備可用性測試時，如何制定測試計劃還要看版本數(shù)量、版本差異化這兩大維度，力爭做好有效且不費力。

如果說在設(shè)計過程中產(chǎn)生的多個版本差異不大，那么都進(jìn)行測試的必要性我認(rèn)為不大，通過在商業(yè)價值與用戶體驗間做衡量，選擇一個更加符合產(chǎn)品階段的方案進(jìn)行可用性測試即可。

但是如果多個版本差異較大，難以決策且不確定性較大，那么第一件事就是經(jīng)過一輪決策將版本減少到兩個左右，然后再進(jìn)行可用性測試，對于此類情況基本上有兩種方法進(jìn)行分配測試；

1. 將版本分為兩組進(jìn)行測試

如果說直接分成兩組進(jìn)行可用性測試，那么需要數(shù)據(jù)樣本會更大，數(shù)據(jù)采集量過少確實會有不準(zhǔn)確的可能，因此直接分成倆組進(jìn)行測試的話，會需要招募更多測試者和測試準(zhǔn)備，但同時可能會有意外的驚喜。

往往我們以為的，可能會在測試者那里收獲意料之外的反饋，這將允許我們以真實用戶的視角去挖掘價值或決策，避免內(nèi)部短視而埋沒了好的設(shè)計。

2. 一組人員測試兩個版本

相比分多組測試，一組人員測試兩個版本在成本上會更有優(yōu)勢，但同時會面臨兩個版本測試的前后順序影響，要知道第一個版本會對用戶形成更多印象，甚至產(chǎn)生一些偏好，所以為減小測試結(jié)果的偏差，我們會將測試者分為數(shù)量相同的兩組，并安排兩組不同的先后順序進(jìn)行測試來打破僵局。

八、測試結(jié)果的量化或匯報技巧

測試結(jié)果量化的目的在于更好的衡量可用性在怎樣的一個水準(zhǔn)線上，同時便于整理復(fù)盤整個測試過程，并將結(jié)果更加直觀的展現(xiàn)出來，便于同事們了解。對于測試結(jié)果量化有兩個方面；

一方面是將整個測試過程中收集到的各種問題反饋進(jìn)行分類整理，并用數(shù)據(jù)圖表現(xiàn)出來，這樣能夠很直觀的展現(xiàn)問題缺陷與突破口，同時能夠快速體現(xiàn)測試價值，或者說你進(jìn)行可用性測試為業(yè)務(wù)帶來的價值。

另一方面則是通過面向用戶的問卷調(diào)查獲取可用性測試量表，最常見的標(biāo)配問卷即ASQ(任務(wù)后評估問卷)與SUS(系統(tǒng)可用性問卷)。

除此之外還有專門面向網(wǎng)站產(chǎn)品的WAMMI(網(wǎng)站分析和測量表)、SUPR-Q(標(biāo)準(zhǔn)通用的百分等級量表，但是獲取有效的百分比數(shù)據(jù)需要購買服務(wù)，所以不額外介紹了，有興趣的自己百度下)，以及面向APP使用體驗的SUPR-Qm(APP用戶體驗量表)，在說明這些量化表怎么使用和定義前，我需要額外說明一些量化表的概念，這很重要！

1. 可用性測試量表標(biāo)準(zhǔn)

作為一個合格的標(biāo)準(zhǔn)化量表至少需要保障以下幾點：

（1）可信度

對同一對象測量得到的結(jié)果是否一致，這將直接決定問卷獲取的結(jié)果是否能可靠，可以通過重復(fù)測量信度和分半信度測量， 測量出的信度會在0～1之間，越是接近1的可信度越高，因為量化結(jié)果會被直接引用，所以信度至少高于0.7才比較有意義，不然一個半信半疑的結(jié)果真的充滿風(fēng)險。

同時以上我提到ASQ、SUS、WAMMI、SUPR-Qm這四個量化問卷也都是經(jīng)過業(yè)內(nèi)長期試驗與驗證后信度較高的靠譜問卷模式。

（2）有效度

主要理念在于是否密切關(guān)注到了你所在意的問題點，以及問卷問題是否與驗證系統(tǒng)有關(guān)聯(lián)性，對于效度也有效標(biāo)效度（皮爾遜相關(guān)系數(shù)）和內(nèi)容效度（因子分析） 兩種評估方法，不過并不一定要有很高的系數(shù)來證明很有效。

（3）靈敏度

指達(dá)到統(tǒng)計顯著性所需的最小樣本量，例如一個水果偏好二選一問卷，你問兩個人可能是答案A，但是你問完10個人后卻是B，當(dāng)采量過小沒能達(dá)到統(tǒng)計顯著性所需最小樣本量時，可能會獲得不夠準(zhǔn)確的答案。

（4）客觀性

一份問卷應(yīng)該保持客觀性，不能攜帶編輯者的個人偏好或主觀意愿影響，這會讓問卷有失統(tǒng)一性。

（5）重復(fù)性

盡可能的使問卷框架結(jié)構(gòu)能夠復(fù)用，一方面便于更多人可以研究驗證，另一方面可以使得問卷本身價值最大化。

（6）可量化

對于問題的答復(fù)最好進(jìn)行量化處理，而不是單純的是或否，目的在于可使用高效的統(tǒng)計學(xué)方法來理解結(jié)果，或進(jìn)行對比，亦或是數(shù)據(jù)可視化體現(xiàn)更加精密的差異。

所以說開發(fā)或調(diào)整一套標(biāo)準(zhǔn)可用的度量問卷也是一門富有學(xué)問的技術(shù)活，并非簡單問幾個問題這么簡單。

2. 任務(wù)后評估問卷(ASQ)

也叫場景后問卷，一般在可用性測試完畢后進(jìn)行，它可以直觀的在任務(wù)難度、完成效率和幫助信息上獲取到測試者的直接反饋，主要就固定三道題目，答案采用5分制或7分制，所得分除以總分即可得到一個均分，該分值至少要大于0.6才能合格，要獲得大部分人滿意或認(rèn)可，則要高于0.7。

3. 系統(tǒng)可用性問卷(SUS)

SUS總共10題，奇數(shù)項是正面描述題，偶數(shù)項是反面描述題，答題采用奇數(shù)的5分制。SUS益于它正反向問題結(jié)合，以及具有泛應(yīng)用的可用性與易用性題型，在業(yè)內(nèi)具有大量應(yīng)用數(shù)據(jù)為基礎(chǔ)，不論是客觀性、靈敏度、可量化還是信度都具有較高的水準(zhǔn)，這也是SUS能夠成為可用性測試后問卷最主流的原因。

（1）SUS量化分?jǐn)?shù)計算

在SUS的相關(guān)創(chuàng)建者經(jīng)過對大批數(shù)據(jù)的研究，其中可用性部分量表信度為0.91，易學(xué)性部分可行度為0.7，為使得整體量表得分兼容在0～100的范圍，最終需要對可用性量表總分乘以3.125，易學(xué)性量表總分乘以12.5。而經(jīng)過長期的應(yīng)用迭代，最終分?jǐn)?shù)的計算方式進(jìn)行了定格：

1. 步驟一：所有奇數(shù)編號題目得分減一后相加；
2. 步驟二：所有偶數(shù)編號題目得分由五減去后相加；
3. 步驟三：將奇數(shù)項最終得分+偶數(shù)項最終得分后 乘以2.5 即最終SUS得分。

（2）分?jǐn)?shù)值概念

在經(jīng)過創(chuàng)建者的研究與沉淀，最終構(gòu)成了5層不同級別的評級，A即最優(yōu)評價，并且對應(yīng)0～100分，有趣的是5個評級并非是將100分平分，為了解釋評級與得分的強關(guān)聯(lián)性，創(chuàng)建者新增了第11題進(jìn)行整體而言的數(shù)據(jù)收集與分析，最終得到了以下圖中所對應(yīng)的關(guān)系。

如果說結(jié)果是“Good(C)”，那么對應(yīng)的平均分值則是“71.4”，如果說你的得分高于85.5分，那你的評級則處于“Excellent(B)”，這可能已經(jīng)意味著你的產(chǎn)品優(yōu)于絕大部分產(chǎn)品了。

4. 網(wǎng)站分析和測量表(WAMMI)

WAMMI的建立是為了專門量化網(wǎng)站產(chǎn)品的，該問卷一共20道問題，采用5分制回答，整體信度高于0.9，但是吸引力、可控性、效率、幫助性、易學(xué)性多個因子測試信度只在0.63～0.74，因此該問卷對測試樣本要求不少于30個。

若該產(chǎn)品屬于學(xué)術(shù)或?qū)I(yè)性較強類型，則樣本量不少于100個，平均分值為50分，總分100分，但是也受樣本量影響，WAMMI很難在可用性測試場景后使用，不過它的問題可以在小型可用性測試中進(jìn)行應(yīng)用或自檢。

WAMMI官網(wǎng)：http://www.wammi.com/index.html

5. APP用戶體驗量表(SUPR-Qm)

作為一個APP用戶體驗量表，涵蓋了更多的體驗度量面，而不僅僅是衡量了可用性（比如SUS），并且可以在可用性測試期間或可用性測試之外進(jìn)行，也可以與其他問題混合使用以便于測量某些特殊產(chǎn)品(如游戲)的用戶體驗，同時它的信度也高達(dá)0.94，SUPR-Qm一共16道問題，采用傳統(tǒng)的5分制李克特反應(yīng)選項。

SUPR-Qm的16道題原本來至23個其他相關(guān)文獻(xiàn)中的題目和4個開放性的問題，經(jīng)過不斷測試驗證和減少冗余后，留下的16個具有單維的、可靠的、有效的、兼容強的問題。

SUPR-Qm原博客說明：https://uxpajournal.org/supr-qm-measure-mobile-ux/

6. 關(guān)于測試結(jié)果匯報

有些同學(xué)一直不清楚可用性測試報告要寫些什么，有無固定格式，其實報告沒有什么特別的地方，簡言之就是將測試的目的、測試過程、測試結(jié)果進(jìn)行整理匯報并反饋優(yōu)化意見而已。

其中大部分內(nèi)容沒有硬性的格式要求，看起清晰易懂是重點，你可以是文檔匯報也可以是PPT匯報，另外記得測試匯報講究真實性，可以把測試過程中的照片或截圖等放進(jìn)去用于佐證。

另外就是測試結(jié)果的歸檔，我們通常會借助表格的形式來呈現(xiàn)，這樣能夠更好的將信息整合。

但是考慮報告輸出，不是一味的反饋負(fù)面問題或解決方案，同樣也可以反饋被用戶認(rèn)可的設(shè)計，這也是測試的一種價值作用，能夠為后續(xù)的優(yōu)化設(shè)計提供一定的方向指引與團(tuán)隊信心，所以我們將常見的測試結(jié)論歸檔表進(jìn)行了一些輕微的調(diào)整，補充了反饋的正負(fù)趨向，最終呈現(xiàn)如下：

九、關(guān)于用戶反饋的思考

用戶反饋本身就是用戶在使用產(chǎn)品的過程中遇到了問題，然后通過找客服或反饋入口所給予的反饋。

如果一個應(yīng)用的用戶忠誠度不高，即使你在應(yīng)用內(nèi)發(fā)布問卷收集反饋，用戶的參與也會很有限，反而是因為一些問題讓用戶受阻了才會產(chǎn)生一些寶貴的反饋，而讓用戶準(zhǔn)備和提交截圖憑證更是困難。

所以這個時候讓用戶反饋的入口更好找，對問題類型提供細(xì)分選項，甚至對截圖等動作做出一些預(yù)判都是不錯的選擇。

以支付寶的使用場景為例，我們有時候截完圖是不是就馬上會收到彈窗提示是否遇到什么問題了？

這便是對用戶反饋的一種重視，如果你確實要準(zhǔn)備進(jìn)行反饋，那么你后續(xù)的操作步驟會少很多，使你更容易達(dá)成而不會因為繁瑣的步驟而產(chǎn)生放棄的念頭，并且截圖時詢問的窗口也是極力克制不會產(chǎn)生過分的干擾。

這么說來你是否對用戶反饋這個功能有了新的看法，并有了給自家產(chǎn)品優(yōu)化一下的想法呢？

寫著寫著就又沒剎住車，又成了所謂的萬字干貨了。

不管你是從事什么職位，都希望你能夠有所收獲，即使你腦子里一靈光有了新的想法或不同意見都?xì)g迎來找我交流。

最后也感謝那些不厭其煩與我交流的用研大佬們，下次有想法了還來煩你們哈哈。都看了這么久了，點個贊收藏一下吧～

本文由 @泡泡 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議