編輯導讀：Think aloud 是可用性測試中常用的一種方法，它是由IBM公司Clayton Lewis在1982年在 《以任務為中心的界面設計》書中被闡述，同時引進到了可用性領域。Think aloud適合在產品設計的任何階段使用，并且適用于各種形式的產品原型，對于用戶路徑，界面信息構架，誤操評估等有快速有效的校驗作用。本文對Think aloud的具體使用方法進行了詳細的分析說明，與大家分享。

Think aloud在中文翻譯中是為出聲思考。Think aloud有很多的優(yōu)點，可以在產品設計的任何階段中使用，它可以看到用戶與產品真實交互的過程，讓我們更好的理解用戶的心智模型。最重要的是，它作為一個靈魂之窗，讓你發(fā)現用戶對你設計的真實想法。特別是，你會聽到他們的誤解，這些誤解通常會變成可行的重新設計建議。

一、Think aloud

在可用性測試中，要求被測用戶敘述他們的想法。當被測用戶與測試產品進行交互和語言表達同時發(fā)生。這使測試者更好地了解被測用戶參與的測試內容、他們在想什么、是否出現問題和被測用戶的感受。

Think aloud方法非常適合于識別可用性問題，而且它還節(jié)省了時間，因為它是在被測用戶完成測試任務時應用的。

Think aloud也有一些弊端：經實際應用，由于思想同時進行口頭表達，測試任務的完成有時會花費更長的時間。

Think aloud可以告訴我們什么？

• 用戶可以理解界面的什么部分
• 用戶不能理解界面的什么部分
• 用戶為什么不能理解
• 我們設計的界面按照用戶設想的那樣運作了嗎
• 用戶對什么發(fā)生的事情感到驚訝嗎
• 用戶有什么誤解嗎

二、Think aloud 的好處

1. 經濟性。不需要特別的設備，只要需要坐在用戶身邊，在他講話時記錄筆記（或錄音）。
2. 可靠性。除非你特意誤導被測用戶，不然測試結果都是真實可靠的。
3. 靈活性。可以在產品的任何設計階段使用，哪怕是項目剛開始時，我們在白板上都可以進行。
4. 真實性。根據用戶實際操作的反饋結果
5. 易學性。團隊中的任何一名都可以組織Think aloud。
6. 融合性。Think aloud 可以和很多的用研方法一起使用

三、Think aloud 的缺點

Think aloud的最大優(yōu)點就是維持了用戶的自然真實的使用狀態(tài)，這是其他用戶研究法不能替代的。

然而就是這種自然使用的狀態(tài)會帶來一些特殊的情況：

1. 被測用戶的因為緊張（或者某些意外情況）所傳遞出來不準性的答案
2. 對于一些高級不常用的功能無法收集到針對性的信息了
3. 用戶容易會一直說，變得不好把控流程
4. 用戶容易將問題進行“優(yōu)化描述”
5. 環(huán)境所導致的時效不好把控

解決方案

我們在招募用戶時，一定需要使用相關平臺的經驗。在介紹自己，介紹任務的時候，一定要親和，可以在任務剛開始的時候，聊一些放松的話題。請嚴格制定你的使用腳本。并交代用戶將問題直接描述出來，獲取用戶的原始想法非常重要。如果被測用戶不會使用出聲思考時，你需要演示一下，幫助用戶快速了解和認知。

四、Think aloud 使用中應注意的問題

1. 角色定義

根據言語交流理論 ,測試前對被測用戶(系統(tǒng)、界面等) 、進行明確界定。

• 被測的產品是測試的對象 ,目的在于發(fā)現被測系統(tǒng)是否適合人的使用，這點要向被試強調
• 被測用戶也應當視為專家，是主要的言語表達者，這有利于被測用戶給予測試任務更多的注意力
• 在測試過程中測試者應作為學習者和傾聽者而存在。

所有角色的定義、包括測試環(huán)境和時間的安排都需要在測試前確定并在測試過程中貫徹下來。

2. 如何使被測用戶更好地進行口語表述

無論是傳統(tǒng)口語報告法還是言語交流指導下的Think aloud都強調要盡可能地保證數據的自然性、無干擾性，測試者應盡可能少地干擾被測用戶的操作 。應答詞的選擇及其使用的頻率受很多因素的影響 ,很難確定，但要力求使整個測試過程更為自然。當被測用戶忘記對操作進行報告時，我們應當及時提醒與鼓勵，我們應該遵循以下幾點：

（1）測試者應該盡可能避免介入

（2）如果實在需要介入時，有用的表達是：

1. 你剛剛點了什么？
2. 你正在做什么？
3. 你現在在做什么任務？

（3）不要對用戶有偏見

（4）不要問有引導性的問題

如，你看起來對于…有問題，是嗎？

（5）不要表達你的評價和觀點

如，你點了瀏覽器的“后退鍵”而不是網頁上的“后退鍵”

（6）不要提供指示和幫助

而是要提示他們如何去自己解決問題。比如，如果你在工作環(huán)境中的話你會怎么做呢？

3. 如何處理測試中的“突發(fā)事件”

可用性測試中意外事故或“非預期事件”較多，采用處理的方式應具有針對性：

1. 如系統(tǒng)崩潰、程序中嚴重的BUG或原型不完整而導致的“意外事故”時，要向被測用戶強調故障是由被測系統(tǒng)本身所引起的，而不是由于操作不當所致，故障處理后盡快確定繼續(xù)測試的開始階段。
2. 在被測用戶提前終止了測試，我們應當及時跟用戶說，“只有完成了創(chuàng)建，這個任務才算完成”。
3. 及時的終止無關的話題。

五、Think aloud 的具體使用方法

1. 記錄被測用戶的出聲思考的內容

2. 創(chuàng)建問題并分類

3. 將問題的編號套入文本內

為了避免圖片過長，就不寫完整了。

六、數據收集及度量

假如有9位用戶，將遇到同類型的問題用Excel表格記錄下來。

（表4-1為了方便計算，3列數據都一樣了）

眼花繚亂的數據？不知道該以哪個數據為準？那么該如何準確的去定義問題的樣本數據呢。

最常見的三種集中趨勢的測量是，中位數，眾數和平均數。

界面、交互、內容問題的數據：中位數 6 ，眾數 7 ，平均數 5.56。

對的沒錯，你需要研究對象的樣本是在，用戶4和用戶5中去尋找問題，并優(yōu)化。（中位數6）

為什么不去按照眾數和平均數呢？

原因1：眾數是指一組數據中出現最多的那個數值，在表4-1中出現最多的就是7。在可用性測試的結果中，眾數并不經常被當成報告。尤其在數據連續(xù)的，范圍很廣的時候，眾數就不一定能發(fā)揮作用了。

原因2：在表4-1中，得出的平均數，看起來稍微合理一些。如果，用戶9發(fā)現了20個問題，那么平均數的波動會很大。但是，中位數還是6沒有發(fā)生變化。這樣也就說明了為什么中位數會被經常使用。

作者：交互思維鋪子；公眾號：交互思維鋪子

本文由 @交互思維鋪子 原創(chuàng)發(fā)布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。