如何快速搞定一場小型可用性測試？來看實戰案例！

設計師心中的用戶和實際情況中的用戶之間存在著很大的鴻溝，我們需要利用用戶研究來解決這個問題。有時候設計師自認為比較好的方案，到了評審會上，會被各種似懂非懂的人提出各種問題。為什么說似懂非懂，因為評審人里面有產品、研發、業務方等，這些人在自己專業領域都很優秀，但大多數并不太了解交互（設計心理學、交互原則、設計系統等）是什么，都是憑自己的感覺去說，這個時候很多設計師就沒招了，只能聽著各種“我感覺”來給你提意見，為什么會這樣？因為他們知道你也是“我感覺”，你能感覺，為什么他們不能感覺。

設計師覺得自己像個改圖的機器，應該就是這么來的。感覺這個東西是不確定的，也許下次評審他們感覺又變了...

解決這個問題的方法之一就是去做用戶研究，要知道是誰在使用你的產品。確定用戶，了解他們的期望，調查他們的需求，這些都是設計任何一個產品的起點。

因為你的用戶不是你，他們的思考方式和你不一樣，做事情的方式不像你，也沒有你有的期望和假設。如果他們和你一樣，他們就不是你的用戶，而是你的競爭對手。

這個時候做 B 端的小伙伴就要問了，我們都接觸不到真實用戶。確實，B 端相對 C 端比較難，但也不是不行，要看你所屬行業。比如像釘釘（面向制造業），順豐（倉儲物流）這種 B 端產品還是相對比較容易的，只要公司支持，可以去企業工廠或者倉庫看終端用戶是怎么工作的。B 端重業務和提效，去實地考察就可以觸達這兩塊。

不過也要看領導層對設計（用戶體驗）這個部門的認可度，如果領導層覺得設計就是美工，基本就真的只能這樣了，這也是很多大佬說的環境和領導很重要的原因。

進入正題...

更多可用性測試干貨：

一、用戶研究的好處

基礎的用戶研究簡單、快速而且高效，對任何產品都能進行實施，關鍵是你是否愿意動手去做。通過觀看、聆聽、記錄，你就能更好地了解你的用戶（客戶），更清楚產品哪些地方不好用。

二、小型可用性測試

可用性測試能說明受眾是否能使用產品。它有助于確定人們在使用產品時存在的問題，暴露出不好用的界面和容易混淆的語言。可用性測試通常作為大型研究系列的一部分，涉及準備和分析工作。

但從快速展示產品和經濟的角度而言，邀請朋友、同事、家人進行小型可用性測試（以下簡稱：可用性測試）最合適。這樣做，可以用最小預算獲得產品的直接反饋。

如果你是第一次進行用戶研究，還是先給自己一點時間準備一下。可用性測試過程可以分為四個主要步驟：

定義受眾及其目標；創建達成目標的任務；尋找合適的人選；觀察用戶執行任務的過程。

1. 定義受眾及其目標

評估總是始于“為什么要有這個東西?”---華盛頓大學 出于某種原因，你正在設計某個產品。你覺得你的想法能讓世界上部分人過得更好。也許能幫他們買到更便宜的東西。也許能幫他們獲得其他途徑得不到的信息，也許能幫他們聯系到其他人，也許能讓他們感到開心。 不管什么原因，你都在設計自己覺得會給特定人群帶來價值的東西。要能獲得這些價值，他們必須做點事情。

因此，對于可用性測試，首先要搞清楚產品的使用對象。對于你預期的、使用產品最多的用戶，如何描述他們？他們和其他人有什么區別？區別在于他們的年齡、興趣和問題嗎？實際可能包含前面所有情況，可能還有更多情況。

但這不夠具體，年紀大的老人也會購買餐具，但不會從網上購買。所以受眾定義范圍要稍微廣泛一點。目標用戶受眾如下:

接下來，要找出關鍵產品功能特性，把產品內容寫下來。為什么人們要使用它？為什么它對用戶有價值？

2. 創建達成目標的任務

現在把網站五個最重要功能寫下來。在購物網站上，人們顯然要能買東西。但不管是否準確清楚自己要買什么，他們都應該能買到東西。此外，也許他們還要能發現促銷商品和超值商品。列份清單，用一兩句話描述一下每個功能。

從使用者角度出發，用兩三句話描述一下用戶使用某項功能的情況，即所謂任務。如果“通過風格找到特定刀叉”屬于功能之一，其任務描述如下:

最后，根據難易程度，按照從最簡單到最困難的順序排列任務。從執行簡單任務入手，人們會對產品和任務過程有好感。

3. 尋找合適的人選

現在，找一些符合步驟 1 所創建的特征的人。

找五六個人，這些人要與你預期對產品有興趣的人相似，像這樣快速運用可用性測試，就可以更充分地認識真實用戶使用產品時發生的問題和誤解。從身邊的人中物色合適人選是最快的方法。如果身處大公司，可以從與產品沒有任何關系的部門找些同事。如果是在小公司，可以找朋友、家人以及同事的朋友和家人；可以找在辦公室的人；可以找街頭的行人。還可以找一些不熟悉產品的人、無論喜歡者或不喜歡，對產品都沒有偏見的人，只要這些人和你期望訪問網站的人有點相似就行。除非產品專為開發人員而設計，否則就不要找靠開發網站謀生的人，因為他們懂的東西太多。

4. 觀察人們執行任務的過程

首先，寫一個劇本（測試任務），受邀的用戶會根據劇本進行。

例如：用戶現在需要通過主數據產品，新建一條主數據編碼規則，需要帶上審批流程。 你也可以在測試任務上介紹一下產品是做什么的，讓所有參與測試的人都知道這是一個什么產品。

接下來找一臺電腦，一個安靜的房間。一般情況下，找個小會議室即可。確保房間里沒有任何與產品有關的東西，以免分散用戶的注意力。

測試前需要告知用戶，他們受邀到此，是為了幫助你了解產品哪些地方有用，哪些地方讓他們感到困惑。

雖然稱為測試，但不是要對他們進行測試，而是邀請他們來評估產品，談談他們對產品的看法，所以他們怎樣做都沒有對錯。

要強調一點：如果不能完成任務，也不是他們的錯；如果他們說出對產品的負面看法，也不會傷害到任何人。他們要大聲說出所有想法，這一點很重要。建議他們詳細敘述在做什么，以及為什么這么做。

你會留在同一房間里，一邊傾聽他們發言，一邊做筆記。這個過程不要打擾到用戶，要讓用戶專心執行任務和詳細敘述。

如果測試過程中他們被問題卡住了，不要告訴他們應該單擊哪里或者看什么。不管什么情況，都不要告訴他們應該怎么做。如果他們看上去特別沮喪，就告訴他們有些事情無法完成不是他們的錯，請他們執行下一任務即可。

如果所有任務都完成了，或者半小時時間已到，就可以請他們停止。請用戶向自己談談他們的總體印象，他們是否會“在現實生活中”使用該網站。 然后送份禮物謝謝他們為測試所花的時間（吉祥物、小禮品、餐飲券…只要適合受眾就行）向他們表示謝意，并送他們離開。

最后，重啟電腦（恢復初始狀態），清除緩存和瀏覽歷史，為下一位用戶測試做好準備。

三、你學到了什么

可用性測試一結束，馬上問自己下面幾個問題。

1. 哪些功能起作用了?
2. 有沒有用戶總是誤解的東西? 如果有，是什么?
3. 有沒有錯誤總是發生?如果有，是什么錯誤?
4. 他們有沒有按照你期望的方式執行任務？如果沒有,他們又是怎么做的?
5. 他們執行的順序是否與你期望的一樣？如果不一樣，又是什么順序？
6. 你期望他們會發現有趣（創意點）的東西，但事與愿違，他們并不覺得有趣。
7. 他們完成了多少任務？哪些任務困難最大？
8. 他們在什么時候感到受挫？當時他們在做什么？
9. 產品符合用戶的期望嗎？如果沒有，哪些地方讓他們感到失望？

到這里，你應該知道產品哪些地方存在問題。

你可能看到有幾件事情一而再，再而三地發生。也許用戶并不理解你為某項功能指定的名稱。也許他們沒看到關鍵功能。也許他們對所提供的功能不感興趣。也許，他們喜歡這個產品，它能滿足他們想要的一切。知道所有這些情況是好事，因為能揭示問題出在哪里，而且同樣重要的是能說明哪些地方沒有問題。

四、實操案例

這里的案例是一個面向制造業的產品，解決制造業多系統中數據的統一、維護、共享。

1. 定義受眾

產品面向的受眾人群主要是業務與技術人員，對數據庫等知識有一定的了解。

2. 設定典型任務

任務：現在需要通過主數據產品，新建一條主數據編碼規則，需要帶上審批流程。

3. 尋找合適人選

Nielsen 提出的一個法則：有 5 人參加的用戶可用性測試，即可發現 85% 的產品可用性問題，而且通常最嚴重的問題都是前幾名用戶發現的，隨著用戶數量的增多， 發現的問題逐漸減少，被發現問題的數量與測試用戶數量的關系如下圖所示。

這次測試參與人員共 6 人，普通用戶 3 名，技術人員 1 名，產品經理 1 名，項目經理 1 名，都是公司內部人員。

4. 觀察執行任務過程

從執行任務可以發現，普通用戶問題是最多的，但這個產品定位是技術人員，所以我們可以先不關注普通用戶訴求，后面三類用戶雖然都懂技術，還是存在很多使用上的問題。

原型如下：

5. 根據反饋進行優化

例如：第一條不知道新建規則流程，設計的人會認為大家和他一樣會使用，其它并不是，上面的產品經理不負責這個產品，所以他也不知道怎么使用，這也是 b 端產品的特點，c 端玩玩就會了，但 b 端你不懂業務就真的無從下手。 基于這一點我們可以給一個功能引導頁面，如下：

剩下問題的這里就不舉例了，只想說明用戶分析很重要。

謝謝大家觀看！