對於可用性測試，業內人士存在一些普遍認可的原則。它們神聖地如同自然科學裡的理論，似乎我們只能對其言聽計從、俯首稱臣才能踐行出“好的可用性測試”。其實，即便是科學，它的一個特征也是“可證偽性”——理論的正確性總是存在前提條件的。真理再向前一步就成為謬誤！
可用性測試中的原則同樣如此，需要根據目的、資源、環境的不同，靈活把握、權衡取捨，而非一味恪守某一個或某幾個原則，也許這才是可用性從業人員經驗重要性的體現。
一．任務設置：精細 VS 寬泛
制定的任務過於精細，一般原則上是反對的。理由很清楚，如果你的任務精細到一步一步“引導”用戶進行操作，那太不符合用戶現實中的使用情境，平時沒有人在旁邊“引導”用戶的每一步操作；而且過於控制用戶的操作步驟，用戶缺乏真實使用時的靈活性。
是不是我們設置的任務只能是寬泛的，不能細化呢？這就必須根據研究的目的來做抉擇。如果產品處在設計的初期，我們需要關注一些宏大的問題（如：網站的整體架構、導航和分類的合理性、頁面的邏輯關系），此時就需要通過寬泛而有彈性的任務，來查找宏觀層面的問題。如果產品的設計已經非常完善，開始進行細節的修改迭代，此時就需要通過設置相對具體的任務來查找特定的細節問題（如：對某個命名的理解、按鈕的使用、鏈接的點擊、表單的填寫）。按照《Don’t make me think》一書的觀點：一般用戶使用互聯網產品時滿足於能用就行，不會尋求最好的使用方法；只掃描網頁，不會仔細閱讀。所以，如果完全寬泛有彈性地設置任務，雖然更吻合實際使用情況，但是很可能用戶直接跳過你想考察的細節。
實際工作中，由於時間和資源的限制，無法做到每個產品從設計初期到上線前後進行多次可用性測試。可能在一次的可用性測試中即需要同時關注宏觀方面和細節上的問題。此時，還是需要和產品經理、交互設計師反復溝通，確認測試的主要目的，同時通過對任務設置精細程度的權衡把握，使次要目的也盡量得以滿足。
不過，即便是想考察細節的任務，也要盡量避免“直接指導操作”式的語言描述方式，這樣能讓任務與真實使用情境不會相距太遠。例如：想考察豆瓣讀書頁面【想要】按鈕是否能被看到、是否具備可點擊感。下面列出兩種表述方式，以作對比：
A.請找到您喜歡的那本書，並在該頁面點擊【想要】。（×）
B.請找到您喜歡的那本書，並在該頁面對其作個標記。（√）
二．任務數量：多VS少
任務數量的多少與可用性測試考察范圍有關，與任務的精細程度也有關。如果對網站全站進行考察和只對其中某個頁面、某個操作流程進行考察，所需的任務數量自然不一樣。在同樣的考察范圍下，如果任務設置得越精細，所需任務數量也就越多。
Lindgaard和Chattratichart（2007）的研究發現任務數量與發現可用性問題比例存在顯著的相關關系（r=0.82，p<0.01）。為了盡可能多地發現可用性問題，我們就盡量多地設置任務給用戶嗎？
此時要考慮任務數量過多可能帶來的弊端：學習效應和疲勞效應，尤其是靠後的任務更可能會受影響。心理學實驗中處理此問題的方法是順序平衡，抵消影響。但是可用性測試中設置的場景和任務存在特定的先後次序，不適合采用順序平衡的方法。基於我們的經驗，還是通過對測試的任務數量進行控制，確保正式測試環節最多不超過1小時，加上前後的歡迎語、訪談、問答等，整個過程不超過1.5小時。
此外，任務數量的多少還會間接影響到測試所需參與者數量的多少。
三．用戶人數：5個足夠VS 5個不夠
Nielsen的研究發現，5個用戶可以發現80%以上的可用性問題。這個結論得到許多人的推崇，因此稱之為“魔法數字5”。這個結論的來源依據是每個用戶平均可以發現30%的可用性問題，且假設所有問題都有同等被發現的概率。不過，當設置的任務數量過多，且任務的精細程度和難度多種多樣時，這個前提有可能不成立。
Lindgaard和Chattratichart（2007）的研究發現測試用戶數量與發現的可用性問題比例並不存在顯著的相關關系。這個結論似乎又支持我們選擇少量用戶進行測試即可。
其實，在用戶招募階段，比用戶數量更需要重視是用戶的代表性的問題。能否招募到有代表性的用戶將直接影響可用性測試的成敗。如測試一個醫療軟件產品，招募到醫護人員和患者作為測試用戶，那5個用戶可能就足夠了；但如果只招募到醫學實習生來測試，就必須超過5個以上的用戶（即便這樣，也未必能推論到整個產品的用戶群）。
由此看來，招募用戶的人數和任務的數量、精細程度、用戶的代表性也是息息相關的。參考Tom Tullis（2009）和本人經驗：當可用性測試范圍限定在一定的范圍（20個任務內、或30個網頁之內），且招募到很強代表性的用戶，那麼5個足夠了。如果存在著差別較大的亞群體，爭取做到每個亞群組有5個左右的代表性的用戶（當然，目標用戶的特征及分類應該是在可用性測試之前的用戶調研階段就解決的問題）；一次測試最多不會超過12個用戶。
四．用戶表現：行為VS言語
在可用性測試中強調對用戶操作行為的關注，是毋庸置疑的。因為：
1.用戶的行為指標更明確、具體、客觀，易觀察和記錄。
2.如果完全把關注點放在用戶的操作行為上，那麼就無需跟用戶進行多余的（指導語之外的）語言交流。類似於心理學研究規范，對實驗或測試中的指導語進行統一，對一切無關變量（包括主試的語言、體態表情）進行控制，以減少對研究過程的干擾。
3.即便你直接詢問用戶某些問題，也極可能得到錯誤的答案。30年前Richard Nisbett和Timothy Wilson的實驗、2年前Peter Johansson在《science》的文章，都證實了某些情況下人們無法解釋清楚自己行為的真正原因。另外，用戶還可能揣摩主試的喜好，回答他們認為主試期望的答案。
因此，有必要強調在可用性測試過程中關注的重點永遠應該是用戶的操作行為，而且盡量減少任何無關變量的干擾。但這個原則被有些人引申到極端，認為只有觀察用戶的操作行為才有意義，其他信息都是無需關注的，甚至輕率地懷疑用戶的話都是不可信的。
可用性測試的主要目的雖然是發現問題，但也需要了解問題背後的原因，而僅僅依靠觀察用戶的操作行為是無法獲悉所有問題背後的原因的，此時，我們就希望用戶能采用“出聲思維法”，出聲思維就是集中於如何與產品進行交互的意識流。如果測試中的氛圍比較平等、自然、融洽，用戶又特別願意表達，那麼用戶就會在進行任務操作同時，表達他們想做什麼、打算如何做、背後的原因是什麼。此時，不僅是操作行為、用戶表達出來的想法和原因、以及語言中透露出的疑惑、失望、不滿、驚訝、猶豫等情緒同樣是需要我們加以關注的。但是，有些用戶比較內向，不善於主動表達自己的想法，此時就需要主試跟他進行簡單的交流，以引導用戶說出背後的原因（注：不是引導用戶說出你期望得到答案）。
所以，在實際的可用性測試，基本應該以關注用戶的行為為主，少量、適時地進行詢問交流也是需要的。但這個度如何把握呢？
1.當用戶出現猶豫、驚訝、任務失敗（過程節點上出現自然而然地稍微中斷/暫停）的時候才進行簡單的詢問。
2.詢問采用一般疑問句的句式，重復用戶剛才的行為表現（要具體客觀）：“你剛才沒有……，是嗎？”——雖然沒有直接問“為什麼”，但暗示了希望聽到他進一步的解釋。
3.如果用戶沒有自己主動說出原因，可以“順便”問一下“為什麼？”或通過身體前傾、目光注視等非語言方式來暗示用戶你希望能聽到更多內容。若用戶很快、堅定地說出原因，則該理由的可信度較高；如果用戶猶豫、或難以說出原因，就不要繼續追問。
除了上述的語言、情緒、行為都需要得到關注，還有一種特殊情況是需要聽懂用戶“沒有說的”語言。例如，我們預計網站的某二級導航標簽和一級導航標簽存在分類邏輯上的不合理；但用戶在測試中，導航相關的操作步驟進行得很流暢，用戶也什麼都沒說。這通常表明用戶認為這些是理所當然的、不影響操作的——此時你需要聽懂用戶“沒有說的”語言。如果你簡單粗暴地打斷用戶並詢問：“你覺得這兩個導航標簽如何？”，則變成了一種誘導性地提問。
總結一下關於此部分內容的實踐應用：
1.用戶的操作行為永遠是可用性測試的重點。
2.鼓勵用戶采用“出聲思維法”。
3.適時、少量地向用戶提問，禁止對同一個問題反復追問“為什麼”。
4.采用真正地“傾聽”技術保持和用戶的交流狀態，而非通過過多的話語。
5.開放、不預設立場地觀察、傾聽用戶“沒有說的”語言。
在可用性測試中考慮需要遵循的原則時，一定要理解它的適用條件，以及它和其它原則之間的互相影響，並結合本次用戶研究的目的、資源、環境綜合考慮，以盡可能形成一個最優方案。由於博文長度所限，先總結這麼多，在下次的文章中會繼續總結其它幾方面的原則。
五．發現問題：真的 VS 假的
判斷發現問題的真假，初看上去似乎不是個困難。多數或全部參與者都遇到的問題毫無疑問是明顯的可用性問題。或許有人會建議，根據參與者中發現該問題的人數比例來判斷：比例高是真問題，比例低是假問題。前半句話可以接受，後半句話則有待商榷。
雖然可用性測試是相對嚴謹的用戶研究方法，但是其對無關變量控制的嚴格程度和真正的心理學實驗還是有一定的差距；並且心理學實驗對每組參與者數量的最低要求是30人，這樣得出的結論（數量比例）才具有推論至一般的意義。而可用性測試一般才8人左右的參與人數（盡管招募的參與者在質的方面非常具有代表性），但卻無法把可用性測試中出現的所有數量比例簡單推論至一般。8個參與者中有1人發現某個問題，不代表現實中出現同樣問題的真實用戶只有12.5%，更不代表這個問題不是真正的/嚴重的可用性問題。
問題的真假除了根據問題出現的次數比例，還有很重要的考慮點是：用戶“錯誤行為”背後的認知/思考方式是否合乎邏輯？
這裡順便借用一下諾曼《設計心理學》裡談到的理論：概念模型——系統表象——心理模型。概念模型可認為是產品設計人員對產品的設計思想；系統表象可認為是產品展現出的交互界面；而心理模型則是用戶按照既往經驗對如何操作該產品的設想。從這個角度來認識，可用性問題則是“概念模型、系統表象、心理模型”三者的不吻合或矛盾。
通過分析用戶行為背後的認知是否符合邏輯，來判斷發現的問題的真假，主要體現在以下幾點：
1.“概念模型、系統表象”的不一致
產品設計人員突然發現，界面的交互形式根本沒有反映出他原先的設計思想！
2.“系統表象、心理模型”的不一致
（1）用戶的思維方式受已有的同類產品的影響，並內化接受，而新產品的“系統表象”和已有同類產品並不一致。
（2）用戶在日常生活經驗中形成了許多並不科學地通俗理解世界的方式（比如通俗物理學、通俗心理學），但產品設計人員沒有意識到用戶在以這樣一種“自認正確”的錯誤方式來理解和使用產品。
如果發現的可用性問題屬於以上情況，那麼即使只有一個參與者碰到，它也非常可能是一個真正的可用性問題。
例如：讓用戶登錄購彩網站，查看自己上次購彩結果。大多數用戶點擊【個人中心】去查看，有2個用戶點擊【開獎公告】去查看，發現只有開獎號碼，沒有任何購彩結果信息後，再去點擊【個人中心】。僅2個人出現了稍微的偏差，而且很快就找到了正確的頁面，這貌似應該不算什麼問題。
但若追究其行為背後的邏輯，並與其他用戶的反饋（“我上次買的號碼沒有直接顯示出來？”“這裡看不到開獎的號碼啊？”）聯系起來，可以判斷用戶的心理模型和產品的系統表象不一致。用戶希望能同時對照著開獎號碼和自己買的號碼很方便地核對，而網站卻割裂兩部分放在不同的頁面，因此需要將這2個用戶碰到的問題當作真正的可用性問題來對待。
六．研究方法：定性 VS 定量
可用性測試，很多時候被認為是一種定性研究方法；但也有人說它是一種定量研究方法。究竟是怎麼回事呢？
個人認為，可用性測試實質上結合了定性和定量兩種方法的特點，到底哪種成分更多，要看你的使用目的以及細節上如何操作。
定量研究的思路是基於對一定數量樣本的測量，以將研究所得的結論推廣至總體。除了強調樣本的代表性，還對樣本的數量有具體的要求，同時會考慮抽樣誤差、置信度、置信區間的度量。並且定量研究過程中非常注重對某些自變量操控、及無關變量的控制。
而定性研究重視對主觀意義的理解（如背後隱藏的原因），采用解釋建構的方法，比如訪談法等。
平時工作中以“形成式可用性”測試為主，即便它稍微偏向於定性研究，但在允許的范圍內，我個人還是盡可能地遵循著定量研究的方法去實施。這樣整個測試過程的嚴謹性能得到保證，結論的客觀程度相對更高（近幾個世紀來，量化研究一直是科學研究的主要范式，也正是這個原因）。具體做法如下：
1.在任務的設置上：因為參與者可能存在差別較大的亞群體，不可能要求完成完全相同的任務。但必定會設置大部分基本的、都需要完成的公共任務，再針對不同亞群體設置少量的特殊任務。在後期統計分析的時候，基本的公共任務則可以進行數量化的統計，並橫向比較。
2.在測試過程中：關注參與者完成任務時的相關行為，用數字來記錄（以0、0.5、1分別表示失敗、幫助/提示下成功、成功）。主試盡量少地言語及體態姿勢的干擾，只在必要時進行適當地言語交流。
3.在報告呈現：對任務完成情況（效率、完成率）統計呈現，對不同任務的完成情況進行比較，對亞群體間的任務完成情況進行比較，對所有可用性問題按數量化指標進行排序等。或者比較迭代前後獨特問題的頻次是否減少，以及嚴重程度高的等級裡面可用性問題數量的變化情況。
4.測試過後，我們通常還會收集用戶自我報告式的數據，作為“感知可用性”的一個總體反映。
（1）推薦使用系統可用性量表（SUS），因為有研究表明SUS在少量樣本時即可產生較為一致的評分結果。
（2）為減少用戶在填寫這些量表時的反應心向，不要求填寫任何個人信息，且主試最好暫時回避。
（3）只統計分析所有參與者SUS量表總分的平均值，切勿再拆分比較亞群體之間的差異，因為即便信效度再高的量表，當樣本量極小時都會變得很不靠譜！
七．問題優先級：單指標 VS 多指標
除了在可用性測試過程中，最終報告也必須體現出量化、客觀地特點。例如，報告發現的可用性問題的列表，我也會以量化的方式排列出問題的優先級別。
這樣做的好處在於：首先，發現的可用性問題肯定有一些比另一些更嚴重；其次，考慮到產品和設計人員的精力和資源總是有限的，必須幫助他們梳理出最亟需整改的問題。站在別人的角度考慮問題，這樣他們才能更“友好地”接受我們的報告。
可用性問題列表的排序，涉及到采用單指標還是多指標、以及指標分為幾級的問題。
先就量化的客觀性而言，“出現頻率”指標是最客觀、最易量化的；而其它三個指標都需分析人員的主觀判斷。
就指標的代表意義而言，“嚴重程度”、“出現頻率”與用戶體驗最相關，與用研人員的職責也最相關。另兩個指標可能更多地是產品人員的職責。
就指標的價值而言，多個指標的綜合顯然比單一指標更有價值。
基於上述考慮，實際工作中我會選擇“嚴重程度”和“出現頻率”兩個指標的綜合，作為可用性問題的優先級指標。“嚴重程度”分為3級，而不是5級（分析人員主觀判斷時，3級指標的誤差率要低於5級指標）；“出現頻率”采用計算的具體數值，而非4級分類。這兩個指標合並時，采用1：1的權重，具體公式為：
問題優先級=嚴重程度的級別+出現頻率的具體值×3
八．報告呈現：優點 VS 問題 VS 建議
當產品設計人員辛辛苦苦做出的產品卻被你報告上羅列的各種問題批評得一無是處時，即便理智上認可你的成果，情感上也很難接受。因此報告中列出哪怕一條最重要的優點，也會讓產品設計人員感到欣慰、感受到你中立的態度，增加對報告的接納程度。列出優點的另一個好處是，在測試中被參與者多次自發提及的優點確實帶給用戶某種驚喜；當你在報告中再次強調時，可以避免在後期迭代開發中丟失掉原本的優點。
問題的列舉肯定是報告中非常重要的部分，但切勿羅列出清單就草草了事，因為：
1.某個（些）問題和另一個（些）問題是有關聯的，但是報告中的問題列表部分卻割裂了這些聯系。
2.產品設計人員無法一直參與旁聽/觀察可用性測試的過程，導致對報告中文字描述的問題缺乏感性認識。
3.只提問題卻不提供解決方案，就不是“建設性地提問”！
因此，我們需要在可用性測試報告的後半部分提出針對重要問題的解決方案。其目標並非是強迫產品設計人員一定要采納我們提出方案，而是：（1）把一些相關問題聯系起來看，（2）加深報告閱讀者對於問題的感性認識和背後原因的理解，（3）使整個報告的思路更清晰、完整，（4）我們還可學到一些交互設計和產品的知識。
總之，可用性測試施行起來既簡單又復雜。簡單是因為不管你如何施行，終究能發現一些問題；復雜則在於發現可用性問題的質量、重要性、對測試的利用效率、對產品設計人員的幫助程度可能相距甚遠。一次成功的可用性測試體現在從前期策劃、測試過程、後期報告等整個過程中是否遵循了這些原則，並在某些難以兩全的原則面前做到合理的權衡取捨。