很多人都有過這樣的經歷：一個產品拿到手，不知道怎么用，只好找來說明書，結果發現說明書寫得比產品很難懂；走到一扇門前使勁一推，只聽咣的一聲—這扇門只能往里拉，不能向外推；某次打開洗手間的冷水水龍頭，冷不丁被燙了一下。

　　每當遇到這種情況，我們都會忍不住吐槽：這種東西是什么人設計出來的？這哪能用啊！

　　“這哪能用啊”就是對產品“可用性”的聲討。可用性不是品質，而是指產品好不好用、易不易用。所以，我能有時也把可用性稱作易用性。

　　互聯網時代，雖然人們常說“小步快跑，快速迭代，”但是，如果有誰膽敢拿出一個連基本可用性都沒有的產品給用戶，直接說“我要開始跑了，”用戶會把他“踩死”在起跑線上。

　　所以，“可用性測試”非常重要。可用性測試，就是通過觀察有代表性的用戶完成產品典型任務，從而界定出可用性問題并解決，讓產品使用起來更方便。它是在正式發布產品、用戶大規模使用之前，最后一道驗證需求的防線。

　　下面萬商云集小編就給大家來介紹下什么是可用性測試，希望下面的內容能對你有所幫助

　　第一步，找到有代表性的用戶。

　　假設你想對大幅改版的音樂播放App做可用性測試，你的“代表性用戶”是誰？他們是用過上一版本App超過3個月，并下載過歌曲的用戶。

　　用戶是18歲還是30歲，這個問題重要嗎？年齡之類的人口統計學特征其實沒那么重要，因為對可用性產品更大作用是“用戶行為特征。”比如，他們如何使用你的App？用了多久？做過哪些事情？這些信息更重要。

　　那么，要選幾個用戶才有代表性呢？需要100個嗎？并不需要。一般來說，用過5個用戶就可以發現明顯的可用性問題，因此5～8個用戶就足夠了。如果調查的用戶量超過8個，可獲取的新的信息量就很小了。

　　第二步，設計“典型任務”

　　“你聽到一首打動你的歌，分享到朋友圈，”或者“你想聽某首歌的高清版，需要注冊為會員，請完成注冊”，又或者“請找到華晨宇的《齊天大圣》”。

　　這些都是典型任務。設計典型任務時要注意：任務不能太多，它們必須是重要的、新版本中容易出現問題的地方；任務必須是用戶會遇到的場景，而不是設計師想象中的步驟。

　　第三步，界定出“可用性問題”

　　用戶開始做測試時，你就是一個記錄員。請記住，不要試圖教用戶如何使用產品，也不要向用戶推銷產品，更不要說“請給我們的產品提提意見”。你只需要說：“請體驗一下我們的產品”。然后仔細觀察和記錄用戶的使用行為。如果條件允許，可以安裝兩個攝像頭：一個用來記錄手機上的操作，另一個用來記錄用戶的表情。

　　對于手機上的操作，你需要觀察用戶看了哪里，點了哪里，接著又到了哪里，是不是你預期的路徑。

　　對于用戶的表情，你需要重點觀察用戶“思考、皺眉、猶豫、驚訝”等表情。當用戶不停皺眉、做出思考狀，猶豫著要不要點的時候，說明他對這個操作沒有信心。當用戶瞪大眼睛，表現得很驚訝時，說明App的反饋讓他感到意外。

　　不要著急，不要指導，你只需要忠實地記錄。

　　第四步，解決這些問題。

　　可用性測試的最后一步，就是趁著記憶深刻，趕快把測試結果整理出來。

　　“下一步”按鈕藏在了屏幕下方，用戶不知道要往下劃，于是困在這里走不下去了——這是嚴重問題，必須立即修復。用戶習慣在左邊找按鈕，一開始沒找到，后來在右邊找到了——這是一般問題，需要盡快修復。用戶下載了很多音樂，存儲空間滿了，但他找不到清除本地音樂的地方——這種情況比較少見，是次要問題，可以延后修復。

　　可用性測試對個人而言也很有啟發。可用性測試的底層邏輯是“我會錯”的思維。我會錯，但是如果能讓用戶證明我錯了，這件事就非常可貴。可用性測試就是用最快、最便宜的方式，證明“我錯了”，然后立刻就改。用最便宜、最快的方式糾正錯誤，是每個自信的人都應該擁有的反向思維。

上面就是關于可用性測試的相關內容，希望上面的內容能幫助到大家理解這個問題。

本文關鍵詞：

可用性測試