酷播亮新聞
可用性測試一定要做，從原型設計到產品發布，任何階段都可以做，有什麼樣的資源就做到什麼樣的程度。
工作中在遇到大的產品改版，或者對某個設計拿捏不准的時候，經常會使用到可用性測試。 在網上搜索可用性測試相關的文章，大多都描述的非常專業，很容易讓初學者望而生畏，尤其是讓很多初級產品經理或者小型初創公司覺得太專業沒有資源，所以乾脆不做。
而筆者的看法是這樣的：
要做到完全符合流程和標準的可用性測試，確實有一定難度，需要的成本也很大，但是，需要注意的是：我們做可用性測試的目的不是“做可用性測試”，而是“發現用戶真實 使用情況中遇到的問題，來提升產品的可用性”，所以，目的最重要，只要能達到這個目的，流程完全不必如此復雜，有些可以省的步驟當然可以省，只要最重要的核心流程和注意 點我們把握好即可。
另外， 可用性測試一定要做，從原型設計到產品發布，任何階段都可以做，有什麼樣的資源就做到什麼樣的程度 。 可用性測試是一種定性研究方法，有研究稱，只要5個人就可以發現大部分共性問題，而這大部分共性問題，在版本發布前發現並解決掉，是一種非常節省資源，規避風險的 方法，甚至有時候可以救產品一命。 腦補一下，某個產品進行了一次大的改版，產品經理們覺得這次改版非常棒，老闆也覺得很滿意，然後釋放給用戶，用戶反饋和數據都非常糟糕，那麼這個時候，想要再 補救，需要投入的成本就會非常大，最重要的是，用戶很容易產生暈輪效應，使得產品其他優秀的點也會被牽連，這對於導入期和成長期的產品來說非常不利，很 可能會導致用戶的流失。 原因很簡單，產品經理往往對自己的產品太熟悉了，就會發生太多的想當然。
怎麼做
下面，筆者將會走一遍標準的可用性測試流程，闡述一下那些必須做到的點，和那些大可不必較真的流程。
第一步：資源準備
資源準備包括測試環境和工具，包括辦公室、觀察間、網絡、測試設備（手機、電腦等）、麥克風、錄屏軟件、屏幕共享軟件、攝像機、眼動儀等。
這些資源里：辦公室可以用會議室代替；測試人員和用戶可以坐在一起，所以觀察間可以不要；只要測試的功能不牽扯到網絡使用，網絡可以沒有；屏幕共享軟件和麥克風主要用於測試人員 在觀察室進行觀察，也可以不要；眼動儀主要用於跟踪眼球運動，可以省略；錄屏軟件用於將屏幕記錄下來，也可以省略，但是免費的錄屏軟件非常多，建議還是安裝一個 。 那麼剩下的，就是測試設備，測試設備當然是不能省略的了，因為這是測試的基礎，用戶總得有可操作的東西才可以進行測試。
可以看到，資源準備的時候，在最簡陋的情況下，我們只要準備測試設備，和一個會議室就可以了，當然，測試人員需要準備紙筆做好記錄。
第二步：任務設計
任務設計就是準備你要用戶去做的事情，這一步當然是不可避免，而且必須去做好準備的，這樣才能將每一次測試的收益最大化。
準備任務的時候，產品經理首先要明確一個問題： 此次測試的目的是什麼？ 是測試整個改版後的產品？ 還是測試某個功能的可用性？ 或者只是測試某個功能的視覺效果？
目的很重要，目的不同，我們設計任務的時候，問題的維度和場景就會有區別。
接下來根據我們的目的，來設計測試任務，這裡有幾個需要注意的點：
（1）一定要站在真實的用戶場景來描述問題
比如：使用下XX產品的錄音功能，這樣可能看起來沒什麼問題，但是筆者在以前做可用性測試的時候，發現這種問題會使得用戶操作起來沒有明確的目的性，那麼他們面對這種問題的 時候，大部分用戶都是瞎點擊，隨便點點就返回。 如果我們這麼問：假設你想用XX錄音軟件，錄製一段歌聲給你的男/女朋友表白；假設之前開會的時候，你通過錄音機記錄了會議過程，你現在想找到它並聽會議內容。 這兩個問題就是有明確的用戶場景，那麼用戶在操作的時候，我們觀察到的也就是用戶在真實生活中的實際可能的操作步驟，發現的問題也就是用戶實實在在會遇到的問題 。
（2）在問題描述的時候，千萬不能有任何引導性語言
比如剛才這個尋找錄音文件的例子，如果我們這樣提問：假設之前開會的時候，你通過錄音機記錄了會議過程，請你現在進入錄音列表，通過快速滾動條滑動找到它，然後點擊聽會議內容。 這個問題就明確地引導用戶怎麼去操作，但是用戶真實使用中，一定會這麼做嗎？ 也許用戶根本不會用到快速滾動條？ 如果這麼描述的目的是為了看用戶使用快速滾動條的情況，那麼最應該的做法是，不告訴用戶滾動條的事情，讓用戶自己操作，看用戶是否會發現快速滾動條，發現後是怎麼操作 。 筆直之前做的一個可用性測試即是想看到用戶對快速滾動條的使用情況，結果非常吃驚，大部分用戶沒有發現這個滾動條的存在，而發現的用戶居然不會使用，或者不知道是快速 滾動條。 我想如果在測試前告訴了用戶滾動條的事情，那麼也就無法發現這些問題了。
第三步：用戶招募
一般情況下，需要尋找產品的目標用戶做可用性測試，我們可能需要在網上公開招募，或者通過公司的資料庫聯繫用戶等方法來尋找測試用戶，但是很多情況下，我們無法快速尋找到合適的測試 用戶，這個時候其實不用那麼死板，可以稍微轉下腦筋，就近考慮，是不是前台小妹或者樓下保安也可以做為測試用戶呢？ 再簡單一點，隔壁產品組裡，對我們產品不怎麼了解的工程師是不是也可以呢？ 用戶招募只是其中一環，我看到有些同事為了招募用戶耽誤了大量的時間，其實是得不償失的，盡快進行測試的重要性更高，因為項目排期和交付日期可不會因為用戶招募需要時間就 延遲的，而如果因為用戶招募導致沒來得及做可用性測試，那真的是非常可惜了。
有數據稱一般情況下，只需要五個用戶即可發現大部分共性問題，但是如果找不到，根據經驗三個用戶也是可以發現大部分的嚴重問題，所以在用戶招募方面，不要太嚴格和 死板很重要。
第四步：測試執行
執行測試過程的時候，有觀察室、錄像機、屏幕共享軟件等完備的測試環境當然最好，不過這裡只描述最簡單的情況：不需要主持人，產品經理做測試人員，一個會議室和一個測試 設備。
首先，我們要向用戶說清楚此次測試的目的，並記錄下用戶的基本情況，盡量以聊天的方式進行，讓用戶盡量放鬆，不要感到壓力。 如果用戶很緊張，那麼測試結果可能會大打折扣。 另外，不要用太專業的術語和用戶溝通。 接下來我們就可以讓用戶按照之前準備好的測試任務進行操作，這個時候，測試人員需要在一旁用紙筆做好記錄。
測試過程中，有一些點是測試人員一定要嚴格注意的：
（1）測試過程中，不要去打擾用戶，也不要給用戶任何提示，所有的問題都等到測試結束再進行詢問和溝通
有時候在測試的時候，測試人員看見用戶遇到了障礙便去進行提醒或者提問，這是不可取的方式，因為真實用戶場景中，不會有人去提醒用戶，而測試中所做的任何提示， 都有可能導致問題無法暴露，這個時候應該做的事情是用紙筆記錄下來，並在測試完成後，和用戶進行溝通，詢問用戶當時在這裡出現障礙是遇到了什麼問題，當時自己是怎麼想 的。 另外還存在一種情況，就是用戶遇到問題的時候，會主動問測試人員，這個時候筆者給的建議是，直接回答用戶：我也不知道。 當然有一種極端的情況，用戶實在是操作不下去了，那這個時候就必須給用戶一點提示了，否則也許測試過程沒法繼續進行了，這個度需要測試人員自己做好權衡。
（2）測試人員要隨時觀察用戶的表情
一般情況下，測試人員只會注意到用戶操作過程中的操作手法，而不怎麼注意用戶表情。 而很多情況下，用戶可能遇到一些小的問題後，直接放棄操作去做其他事情，這個時候如果只看用戶操作，可能會忽略掉這種問題，但是如果觀察用戶表情，可能會發現用戶出現 皺眉或者微笑等一些明顯的表情變化，這個時候將用戶表情和當時在進行的操作進行聯繫，測試完成後和用戶進行詢問溝通，往往可以發現一些問題或者一些驚喜。
（3）要求用戶進行測試的時候，使用“發聲思維”
很多時候，用戶說的和做的是不一樣的，而且在測試完成後，和用戶再進行溝通，用戶可能已經忘記了，那麼他們這個時候的描述和當時的操作可能就會存在差異。 而“發聲思維”可以很大程度解決這個問題，即用戶在操作的時候，讓用戶同時說出來，說出自己的思考過程，比如：自己要做什麼事，先做什麼，再做什麼，為什麼 要這麼做等。 這個時候，一旁的測試人員只需要做好記錄和觀察即可。
第五步：報告呈現
報告盡量簡短，形式不重要，重要的是內容和可讀性，一般要包括測試對象的基本信息、測試的任務清單和測試結果、用戶反饋以及問題整理整理和改進建議。
另外，筆者建議測試報告盡量包括測試過程的簡單描述，對以後回顧問題的時候會有比較大的幫助，當然這部分可以不放到測試測試報告的正文裡，如果用xls整理報告，可以在其他 表單裡記錄。
最後一步：問題解決
這一步才是可用性測試最終實現它價值的地方。 經過前面四步，我們已經得到了測試的結果，那麼接下來就需要產品經理將這些問題進行歸類，並進行需求分析和優先級評估，確定出需要修改的問題，進行排期，這就是產品 經理的日常工作了。
最後的最後：其他需要注意的點
（1）針對某次發版的可用性測試一般建議不能做太晚，如果等到產品快上線了，才做可用性測試，並且發現了很嚴重的問題，那麼這個時候就有點於事無補了。 所以，在做可用性測試的時候，有產品就用產品測，有Demo就用Demo測，有原型就用原型測，什麼都沒有，也可用用競品做測試，這樣避免我們去踩競品的 坑。
（2）可用性測試什麼時候都可以做，要貫穿到整個產品的設計過程中，作為產品經理的一項基礎日常工作，想想看，如果我們可以用上述的“簡版”可用性測試方法，性價比 還是很高的，比如筆者曾經做過一個可用性測試，用戶招募就是簡單的從公司裡找了一些小白，測試的功能是通過帶有時間的快速滾動條來快速定位圖片（測試之前，快速滾動 條的樣式是半黑透明，上下端是兩個小箭頭，點擊該滾動條出現時間，用戶可以開始滑動，停止點擊幾秒後，時間消失）但是通過下面的測試結果看到，如果沒有這次 的可用性測試，那麼這個功能釋放給用戶後的結果將是：無人使用。
而這整個測試過程，當時只花費了2個小時。 所以“簡版”的可用性測試的性價比真的非常的高。
（3）針對來測試的用戶，在測試完成後，給用戶一些實際的獎勵，比如可以準備一些獎品或者紀念品給用戶，也可以獎勵用戶一些產品的虛擬貨幣或者積分、虛擬寵物之類的，並且 和用戶進行友好的溝通，詢問用戶是否願意接受以後的測試。 這些都會更方便以後做可用性測試招募用戶。
總結
如標題，可用性測試真的很難嗎？ 我想看過這篇文章後，讀者會有自己的見解。 筆者在這裡只需要強調一次前面已經說過的話： 可用性測試一定要做，從原型設計到產品發布，任何階段都可以做，有什麼樣的資源就做到什麼樣的程度 。
本文由 @Monica 原創發佈於人人都是產品經理。 未經許可，禁止轉載。
題圖來自 Unsplash，基於 CC0 協議