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

在日常的 B 端產(chǎn)品調(diào)研支持過程中，我們研究員經(jīng)常會遇到這樣的場景：

“你們幫我看看，產(chǎn)品方案滿不滿足用戶需求？功能符不符合用戶預(yù)期？”

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

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

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

更多干貨：

首先，我們先來了解什么是產(chǎn)品可用性測試？

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

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

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

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

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

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

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

在實際項目執(zhí)行中，我們通常會在幾個特定階段去進行產(chǎn)品可用性測試，不同階段采取的調(diào)研方式也有所不同，所關(guān)注的內(nèi)容亦隨之變化。

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

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

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

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

STEP1：設(shè)計任務(wù)

可用性測試的基礎(chǔ)是任務(wù)，任務(wù)測試內(nèi)容的好壞是能夠?qū)y試結(jié)果的準確性有直接影響的。因此在招募用戶之前，需要對測試的產(chǎn)品方案進行任務(wù)設(shè)計。比如，測試商家在 B 端營銷系統(tǒng)報名營銷活動流程方案的任務(wù)可以是：報名一場雙 11 大促活動。

在設(shè)計比較合適的測試任務(wù)時需要注意以下幾點：

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

STEP2：招募用戶

在招募用戶環(huán)節(jié)，最重要的是樣本數(shù)量的確定。在實際的可用性測試中，我們常常被產(chǎn)品同學(xué)或設(shè)計同學(xué)問到：

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

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

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

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

STEP3：前期準備

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

STEP4：試點測試

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

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

STEP5：觀察訪談

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

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

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

STEP6：分析報告

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

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

最后的話

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

而且一個產(chǎn)品設(shè)計方案在沒有經(jīng)過用戶驗證的情況下，容易在實際上線使用后出現(xiàn)一些隱性風(fēng)險。而前置的設(shè)計驗證，在一定程度上可以輔助我們產(chǎn)品功能在上線前發(fā)現(xiàn)問題，改進設(shè)計。

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

參考文獻

[1]劉津, 李月. 破繭成蝶:用戶體驗設(shè)計師的成長之路[M]. 人民郵電出版社, 2014.

[2]伽略特, 伽略特, 范曉燕. 用戶體驗要素:以用戶為中心的產(chǎn)品設(shè)計[M]. 機械工業(yè)出版社, 2011.

[3]樽本徹也. 用戶體驗與可用性測試[M]. 人民郵電出版社, 2015.

[4]尼爾森. 可用性工程[M]. 機械工業(yè)出版社, 2004.

[5]SteveKrug, 克魯格, 蔣芳. 點石成金:訪客至上的 Web 和移動可用性設(shè)計秘笈[M]. 機械工業(yè)出版社, 2015.

歡迎關(guān)注「JellyDesign」的小程序：