1. 任務設置應該具體一下嗎?
可用性測試是讓一群有代表性的用戶嘗試對產品進行典型操作，所以任務要滿足場景化和路徑化兩個條件，要不用戶不理解任務，或感到迷茫，會產生時間耗費；
場景化：比如“最近玄幻類的書很火，你也想看一下有沒有自己喜歡的作品，想在這個網站上找一下，請操作”。實驗室環境無法真實再現用戶真實使用場景，所以要創建用戶常遇到的場景，讓用戶能更加好的理解任務，聯想平常遇到這樣的情況會怎麼辦，這樣才能呈現用戶特定場景下的行為，不是為了任務而任務；
路徑化： 設定任務之前要想清楚任務的關注點是什麼，怎樣能讓用戶盡可能自然的使用這個功能，而不是“請你找一本書”這樣的模糊路徑，因為用戶會隨便找一本書，而不會用到你希望考察的功能。
2. 針對單個任務的滿意度評分應該什麼時候評呢?
這個跟同事也產生了一些爭議。同事認為應該訪談之後，讓用戶明白的知道網站的問題，明確自己遇到的問題，才能客觀的打出滿意度發分數。
個人認為滿意度應該在任務做完以後就評，這才是用戶自己認為的滿意程度。如果等訪談完成，用戶會在主持人的提問下意識到一些自己之前沒有注意到的困難，影響到自己真實的滿意度打分。
用戶遇到的問題在研究人員中可能會很大，但是在用戶眼中或許並不能稱之為問題，應該客觀的測量用戶自身需求被滿足的程度。
從另一個方面講，用戶打完分以後會順便問一下為什麼打這個分數，問題是什麼，這個流程也會更加合理一些。
3. 強化測試用戶的身份意識
被試有身份識別的時候，為了防止用戶在測試過程中混淆自己的深度，要在測試過程中不斷強化。比如測試某網站時，被試可能同時會有讀者和作者兩種身份，有些用戶在訪談中會不知不覺的忘掉自己作者的身份，會說你們網站的內容可以吸引人一點，等等，這樣得到的意見並不是作為一個作者的真實意見，所以在訪談中要不斷的說“你作為一個作者，會。。。”引導用戶使用正確的身份。
4. 追問
用戶覺得有問題的地方要問清楚為什麼，比如有用戶表示“這個頁面上的信息有點多，只要顯示作品的上傳的時間以及浏覽量就可以了”，當時習慣性的問了一個為什麼這樣覺得，他說讀者不需要知道那麼多信息啊。啊!原來她以為這個頁面上是讀者也可以看到的~~~。其實這個頁面是只有作者自己才能看到的，所以被試不清楚機制，就會覺得有問題等理解性的錯誤。
繼續追問才發現原來她是想要一個類似個人主頁的功能，希望能顯示自己作品的列表等信息，以及更新的狀態就ok。
5. 測試前要記得評估哦
測試研究人員在測試之前一定要進行認知走查，了解產品的功能、後台機制和流程等、遇到的問題，這樣在測試的時候才會心中有數；
6.不需要讓用戶知道是什麼，為什麼?
測試中用戶會經常問“這個是不是需要審核的啊”“這個是不是這樣啊”，這個時候只要問一下“你是怎麼認為的呢”只要能了解用戶的想法就可以，不用告訴用戶我們的產品是這樣這樣的。
7.不要希望用戶來幫你設計
測試用可以問用戶的意見和想法，但是不要把優化的遠不希望都寄托在用戶的意見身上，因為用戶的修改意見也很不靠譜。比如有用戶說我希望星級評分不用登錄，但是從產品的角度上說，不登錄的話重復投票怎麼辦呢?會產生更多的問題。所以不用太指望用戶建議。
8. 有些問題用戶沒有遇到怎麼辦呢?
有些用戶沒有遇到我們所認為的重要問題，在後面的訪談中問一下用戶的看法就好，不要讓用戶在測試任務中一定要操作。
9. 測試中記錄人員不要發問
如果條件允許，記錄人員應該在觀察室，盡量不要在實驗室中，避免給用戶不必要的壓力。記錄人員在測試中不要發問，一般是在測試結束後，可以補充一些發現的問題，問一下用戶的想法之類。