設計師可用性測試計劃編撰

　　最近在進行面向設計師的可用性測試介紹，在涉及到測試計劃這一部分時，布置了一個簡單的作業：為TB新版收藏夾設計一個原型測試計劃。從回收的結果看來，發現了一些比較典型的問題。在這裡簡單介紹一下方法和自己總結的幾個注意點。

　　這是面向意欲執行可用性測試的設計師的簡單方案，所以選擇了比較精簡易懂的介紹。

　　制定測試計劃可以簡單歸納為三步：

　　確定用戶最關鍵的一點是明確產品的商業目標，它很大程度(盡管並不總是)決定了後續的特征提取。特征通常包括使用行為以及人口特征數據兩個方面。未必總是需要考慮人口特征，取決於產品。實際上有多少互聯網產品能夠在人口特征方面明顯差異化呢?

　　一個標准的可用性測試當然需要根據定義好的特征去找對應用戶，但是對於設計師來說，這樣操作的成本較高，很多產品實際上並不需要十分嚴格地選取用戶也能得到有效反饋。

　　為了幫助設計師明晰用戶群，我在課堂上設計了一個簡單的3C練習讓大家分組討論然後互相參看答案並點評。這種方式對於激發討論(要輔以時間控制)還是蠻有效果的，從Gamestorming這個網站得到的啟發。

　　確定了用戶群體後，可以根據上一個練習得出的用戶挑戰以及結合產品本身待檢驗的設計決策等，轉化成訪談問題、測試任務和觀察要點。

　　測試任務，或情景任務(俗稱指導語)是比較關鍵的一部分。不同的說法可能引導不同的行為，關鍵還是看任務本身的測試點是什麼。上圖所舉例的四句話，沒有絕對好壞對錯之分，取決於你想通過任務發現什麼問題。

　　後續通過回收設計師們的作業(描述收藏夾測試用戶的特征;以及為其中一個用戶群設計兩個測試任務/訪談問題/觀察點)，發現了一些共同的問題，所以總結了幾個點。每個點輔以一些反例。

　　數據可操作性是指，需要考慮數據是否可以通過BI取到。

　　熱身訪談和回溯問題是不一樣的，回溯問題主要針對任務完成情況的提問。而熱身訪談則用於了解現狀、習慣等，這對於輔助分析用戶為何作出某些行為有重要的參考意義。

　　其實，設計任務以及指導語可以說是最具挑戰的環節。

　　任務本身必須具有邏輯性，比如上圖舉例為什麼是反例?因為用戶大可以不走我們希望TA走的行為路徑來完成這個任務，這就達不到檢驗問題點的目的了。

　　另外，任務還需要考慮情景是否充分，過於干巴巴的指導語很難讓用戶進入狀況。同時，還要考慮用戶的性別等。如果是女性用戶，讓其購買足球就未必合適了。

　　再次，任務還需要考慮原型制作成本。比如一個邏輯性和情境性都很強的任務，卻需要設計師花很大功夫做出相應的原型，也是不可取的。

　　對於剛剛接觸可用性測試的人來說，事前在計劃書裡把觀察點羅列仔細會更好哦。作為觀察點，自然是能夠被觀察到的才算。所以盡量避免一些需要主觀判斷的內容，比如是否喜歡、是否意識/察覺/到……

　　最後，關於探詢問題(訪談時/回溯時)，也有一些需要注意的點。常見問題包括問一些有偏向性的問題，或者非要要求用戶在方案甲乙之間作出選擇。當然，我們可以去問“你更喜歡哪個版本?”，但其實更應關注的是為什麼喜歡/不喜歡而不是最終的選擇。

　　此外，那些預測性的提問，比如“你覺得你會用嗎?”“你覺得你會買嗎?”，對於用戶的回答要持謹慎態度。

　　作者：Helicopter

　　文章來源：piglili.blogbus.com/logs/127376255.html