中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

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

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

一、Think aloud

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

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

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

Think aloud可以告訴我們什么？

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

二、Think aloud 的好處

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

三、Think aloud 的缺點

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

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

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

解決方案

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

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

1. 角色定義

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

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

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

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

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

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

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

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

（3）不要對用戶有偏見

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

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

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

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

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

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

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

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

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

五、Think aloud 的具體使用方法

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

2. 創建問題并分類

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

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

六、數據收集及度量

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

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

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

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

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

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

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

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

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

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

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

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