人們認為設計師是表面工作——設計師拿著盒子說‘它看起來好！’這不是我認為好的設計。設計可不只是看起來或者摸起來的樣子，設計考慮的是用它的感覺。 ——Steve Jobs 2003年11月30日《紐約時報》

在日常的 B 端產品調研支持過程中，我們研究員經常會遇到這樣的場景：

“你們幫我看看，產品方案滿不滿足用戶需求？功能符不符合用戶預期？”

“（研發問）功能上線的 ROI 是多少？用戶對這類功能是否有需求？解決了用戶什么問題？”

“你們多找一些用戶驗證一下 demo 方案行不行…”

無論是產品同學，還是設計同學，相信大家或多或少都會在需求文檔、設計文檔評審時被業務方、研發問到方案可行性和落地價值等方面的“靈魂拷問”，而這些疑惑同時也在拷問我們研究員。那么作為研究員，我們是如何從用戶的角度去輔助產品同學和設計同學進行敏捷的方案驗證呢？

首先，我們先來了解什么是產品可用性測試？

可用性（Usability），被定義為一種用來衡量界面好用程度的屬性。好用程度的高低一般取決于以下五個要素：

1. 可學習性（Learnability）：初次接觸這個設計時，用戶完成基本任務的難易程度。
2. 效率（Efficiency）：用戶能多快完成任務。
3. 可記憶性（Memorability）：當用戶一段時間沒有使用產品后，是否能馬上回到以前的熟練程度。
4. 出錯（Errors）：用戶能否從錯誤中恢復。
5. 滿意度（Satisfaction）：用戶對產品的主觀滿意度。

可用性測試主要用于驗證產品的可用性，該方法能夠幫助產品同學和設計同學了解在實際使用情境中該設計方案（概念或創意）的質量（評估是否可用/是否有效/用戶是否滿意），并在測試結果的基礎上進行改進。

換句話說，可用性測試是觀察有代表性的用戶，讓用戶完成產品中的各項任務，了解用戶如何使用產品，界定出可用性問題并解決這些問題，讓業務、產品、設計、研發等上下游角色盡快對產品方案達成共識并積極優化產品體驗。

通過可用性測試，我們可以：

1. 了解用戶如何與產品進行交互；
2. 了解用戶是否能夠完成指定任務；
3. 了解用戶需要多久才能完成指定任務；
4. 了解用戶對本品和競品的滿意度；
5. 明確產品存在哪些需要優化的可用性問題；
6. 明確產品可用性情況及是否符合上線目標；
7. 讓產設研團隊在開發上線前發現問題并解決。

那么，什么情況下可以做可用性測試？

在實際項目執行中，我們通常會在幾個特定階段去進行產品可用性測試，不同階段采取的調研方式也有所不同，所關注的內容亦隨之變化。

（1）設計初始階段，我們通常會進行前期用戶需求挖掘或相似產品使用情況分析，并基于需求概念設計出來的草圖方案進行探索性可用性測試，來確定方案內容和功能的范圍是否符合用戶預期方向和使用需求，以此初步評估草圖方案的有效性和可用性。因此，在該階段，我們常以紙張原型測試+定性深訪為主，先從認知上與用戶保持一致，理解了用戶，做出來的產品方案更能貼近用戶訴求。

（2）灰度上線前，我們一般對 demo 終稿進行評估性可用性測試，向目標用戶介紹新設計，同時盡可能保證 demo 稿是用戶能夠直觀測試使用的，以此來確定 demo 在功能滿足、信息布局、流程交互，甚至是視覺樣式上是否能夠提供良好的用戶體驗。所以，在該階段我們更多會進行面對面測試+可用性測試量表（SUS 量表），一般在會議室等固定安靜的環境中進行，并要求用戶按既定任務測試操作，任務測試過程中不打斷用戶并觀察記錄用戶在關鍵流程環節使用中遇到的問題，測試完成后向用戶提出問題或進一步探究原因。

（3）灰度上線或全量上線后，我們通常會對上線后的新方案進行對比性可用性測試，通過灰度方式在同一時間維度下比較新方案和原方案的可用性反饋和用戶滿意度，確保方案在全量上線之前修復任何潛在問題。因此，在該階段我們以 A/B 測試+場景化調研問卷（如下圖所示）為主，通過用戶體驗數據和業務數據來評估出最優版本。

實際執行中，我們怎么做可用性測試？主要實施步驟有：

STEP1：設計任務

可用性測試的基礎是任務，任務測試內容的好壞是能夠對測試結果的準確性有直接影響的。因此在招募用戶之前，需要對測試的產品方案進行任務設計。比如，測試商家在 B 端營銷系統報名營銷活動流程方案的任務可以是：報名一場雙 11 大促活動。

在設計比較合適的測試任務時需要注意以下幾點：

1. 選擇最核心的功能或操作流程作為任務。產品最核心的功能和操作流往往是最頻繁被用戶使用的地方，假設最常用最核心的地方還存在可用性問題，那么就算優化了其他邊緣部分的可用性問題，依舊是對產品整體體驗于事無補。比如在商家報名大促活動流程中，最核心的環節是查找活動→選擇商品報名→跟蹤報名進度，那么就需要重點將這部分作為測試任務。
2. 任務應符合常規操作流程。在實際業務中，產品線的職責分工會比較細化，比如 A 產品會負責 A 模塊，B 產品負責 B 模塊…單一功能模塊的測試任務較多的情況下，如果各任務之間操作流無法串聯甚至是存在沖突的話，用戶測試的操作流就是不合常規的，也容易給參與測試的用戶帶來困擾。因此，我們研究員需要根據用戶操作習慣來進行評估測試任務并設計串聯流程。
3. 為任務創建一個應用場景。簡單的場景描述會對用戶執行任務有幫助。比如：任務是“報名一場雙 11 大促活動”，我們可以創建這樣一個場景：你關注的雙 11 大促活動報名時間開始了，你想上商家后臺去報名雙 11 大促，請登錄商家后臺來完成大促活動報名。
4. 明確任務的起點和終點。用戶是否完成了任務的評估依據是：用戶是否從起點（頁面 A）到達了終點（頁面 B）。因此要明確起點和終點的定義，哪個頁面是起點？哪個是終點？比如：任務是“報名一場雙 11 大促活動”，起點頁面就是商家后臺首頁，終點頁面就是提交報名素材成功的頁面。另外在評估是否到達終點頁面之外，還需要關注用戶在任務過程中的操作動線、是否有效填答信息，若沒有，我們需要搞清楚背后原因是什么。
5. 任務不應過于簡單。若想測試用戶是否能夠找到某功能，不要用類似“找到 XX 功能按鈕”這類表述，我們應該給用戶提供一個要處理的實際場景任務，比如不是“找到換品功能按鈕”而是“報名完成后想要重新換品”。
6. 避免提供線索和描述操作步驟。任務只需要給出具體目標即可，不需要給到測試用戶具體的操作步驟，不然會容易錯過用戶在執行任務過程中到某一環節可能存在的“意外問題”，而這些“意外”恰恰是我們需要關注的。

STEP2：招募用戶

在招募用戶環節，最重要的是樣本數量的確定。在實際的可用性測試中，我們常常被產品同學或設計同學問到：

“6 個用戶提出的問題能代表全部么？”

“幾個用戶是不是太少了？他們提出的問題是可靠么？”

諸如此類的樣本數量“挑戰”，不勝枚舉。人機交互博士 Jakob Nielsen 曾提出：“有 5 個人參加的用戶測試，即可發現大多數（85%）的產品可用性問題。” Nielsen 這張經典圖表（如下圖）告訴我們答案：一般最嚴重的問題都是前幾名用戶發現的，隨著用戶數量增多，發現問題逐漸減少。

當然在實際執行中也會存在一些局限性，比如只能發現問題數量，但無法確定發現問題的嚴重程度，因此還是需要從實際情況比如測試任務的復雜程度、人力資源的投入程度等等來確定招募樣本數量。

STEP3：前期準備

1. 測試地點與工具準備。比如安靜的會議室、電腦、錄音筆、錄屏軟件（錄制操作全程，便于后續回顧分析）等。
2. 任務相關資料準備。如①數據收集表，如收集任務是否完成、完成時間、關鍵事件中遇到的體驗問題、滿意度；②訪談提綱，包含任務步驟、需要注意深挖的環節問題等。比如，任務是“報名一場雙11大促活動”，訪談驗證sop示例：

STEP4：試點測試

試點前測的目的是針對整個測試流程和提綱進行測試，便于前置發現流程和提綱中存在的問題，及時優化，避免造成真實測試用戶的資源浪費。試點前測需要注意：

1. 訪談提綱的話術表達和任務流程的設計，是否能夠準確讓用戶理解？
2. 提綱內容是否透露了操作步驟，用戶是否很快完成任務？
3. 時間安排是否合理，用戶是否可以在規定時間內完成任務？
4. 任務流程安排是否合理，用戶是否感到疑惑？

STEP5：觀察訪談

在觀察測試中，需要檢查用戶任務目標和心理認知是否可以順利執行下一步操作，以此來發現可用性問題，因此我們要對以下問題做到心中有數：

在事后訪談中，有以下幾點小小訪談 tips：

1. 認知習慣層面：首先了解用戶對方案功能的基本理解，比如是否能夠理解？理解的意思是什么？為什么會有這些理解等等，之前在這些環節中用戶的操作習慣是什么樣的？
2. 需求關注層面：用戶在這些環節關注哪些方面？然后再給用戶解釋每個功能方案的定位作用是什么，方案解決什么問題。同時追問用戶，就目前方案是否解決實際中的問題，哪些問題？以及還有哪些優化的建議等等。盡管大多數人認為不該直接問用戶產品的優化建議，用戶給到的結論也只是基于自身經驗的主觀想法，但是若根據用戶給到的答案繼續深挖“為什么”，可能會知道用戶真正想要達到的效果和預期是什么。
3. 切記不要上來就一通講解方案后就單純問用戶你覺得好不好，應該還要繼續往下追問。因為這樣通過對用戶現有的行為習慣和需求關注的了解，才能夠判斷評估用戶說的話是否邏輯自洽，才能夠驗證方案是否能夠真正滿足用戶的需求，而不是偽需求。

STEP6：分析報告

一般情況下，可用性報告的內容主要包含以下三方面：

1. 研究概述：測試目標、樣本描述、研究方法等。
2. 問題解讀：問題描述、原因解讀、嚴重程度及影響范圍評估、數據結果等。
3. 解決應對：建議的解決方案。

最后的話

好的產品設計應當滿足以下特征：可用性、易用性、好用性且具有吸引力。每個特征都是為了能讓產品站穩腳跟而存在的，倘若想要讓產品功能最終具備這些特征屬性，就離不開產品可用性測試的過程。

而且一個產品設計方案在沒有經過用戶驗證的情況下，容易在實際上線使用后出現一些隱性風險。而前置的設計驗證，在一定程度上可以輔助我們產品功能在上線前發現問題，改進設計。

以上，共勉~希望能對大家有所啟發。

轉載：優設

蘭亭妙微（藍藍設計）m.jjddy.com 是一家專注而深入的界面設計公司，為期望卓越的國內外企業提供卓越的大數據可視化界面設計、B端界面設計、桌面端界面設計、APP界面設計、圖標定制、用戶體驗設計、交互設計、UI咨詢、高端網站設計、平面設計，以及相關的軟件開發服務，咨詢電話：01063334945。