可用性測試是產品經理做調研時非常有用的方法，在B端也非常有效。這篇文章，作者通過一個案例詳細講解了其中的「場景自助測試」，主要解決的正是產品難用、初次體驗不佳或是缺乏引導設計等主要問題。

作為一名ToB的設計師，你是否有遇到過以下這些問題；

• 明明設計都遵循了用戶體驗設計的原則或是業(yè)務背景，但是用戶依舊反饋不好用或不直觀。
• 功能邏輯明明沒問題，結構也不復雜，但是客戶用不明白，跟預期完全不是一回事兒。
• 界面結構跟視覺設計明明看著還不賴，但用戶就是找不準流程線路，跟預期路線不一致。
• 用戶注冊產品后無從下手，無法獨自走通關鍵業(yè)務功能，初體驗不順暢還略帶受挫導致流失。
• 用戶反饋不好用卻又說不清楚哪里有問題，不曉得是性能問題還是特定需求未滿足？

當然了，也不僅限于上面這些問題，但是如果遇到了，或許你可以在此篇文章中找到一些答案。

一、認識場景自助測試

1. 起源

源于“可用性測試”的一個細分延展應用，微型使用性測試也是可用性測試的一種細分延展應用，個人學習和了解可用性測試是在2017年從一本叫做《洞察用戶體驗》的書中習得，就下圖里這本厚厚破破的書里。

在過去的這么多年里，可用性測試不僅我個人在用，在整個行業(yè)里也已經被廣泛接受和應用，其效用價值還是可靠的，而作為細分延展出的場景自助測試，在我投身B端業(yè)務后，也是圍繞產品目標參與發(fā)起很多次了，所以這次結合自身體會給大家安利一下，對了，可能其他團隊或公司對此工具的叫法會不一樣，但這不影響我們學習掌握。

2. 概念

場景自助測試主要是觀測用戶如何根據任務訴求自助應用產品來完成某項工作，這個過程中可以清晰的看到某個業(yè)務場景下產品是否容易上手，以及哪些部分阻礙了用戶或需要進一步引導，當具備多組測試數據時就可以計算出用戶自助完成的概率，那么就可以根據產品情況制定一個目標分，當優(yōu)化后的測試結果滿足目標分以后，產品的自助性與體驗就會再上升一個門檻。

3. 價值

通過用戶來找到產品的問題，驗證設計是否符合用戶預期，指引設計者將復雜產品簡單化，完善產品的自助引導設計，提升用戶自主解決問題的能力，以減少人工支持的開支，同時獲取一定的用戶意見或市場訊息。

4. 原則

所謂的以用戶為中心原則，基本上就是還原真實環(huán)境下以用戶為主導的使用效果，注重數據驅動與場景化分析，同時屬于持續(xù)性迭代測試任務，當測試出一波問題后還需要進行改進后的版本測試回歸，并保證自助通過的概率符合產品難度預期。

5. 優(yōu)勢

• 用戶自主性高：相比傳統可用性測試，場景自助測試有更多的用戶自主性，同樣是基于任務導向，但人為的引導干涉或過于詳細的任務書引導會更少，用戶會更放松，參與度也會更高。
• 廣泛的用戶群：覆蓋的用戶群體可以更廣泛，不用局限在典型或是資深用戶，并且數量上也可以更加靈活，只要有一定的產品業(yè)務認知，且不是對應產品的研發(fā)設計相關人員即可。
• 更低的成本投入：基于限定的場景目標，通常任務體量不會很大，加上對于測試環(huán)境、測試設備、專業(yè)度要求也更低，并且招募群體更廣泛，招募成本以及時間或金錢要求都會相應減少。
• 有效的反饋：與功能測試不同，場景自助測試是要求非產品研發(fā)人員以某些業(yè)務目標展開的測試，可以觀察到通常情況下的用戶自助應用的情況，能夠為我們提供可信且真實有效的反饋。
• 持續(xù)性驗證：一般每一輪的場景自助測試完成后，都會根據收集到的數據來制定一個優(yōu)化目標，并根據測試反饋對產品任務線路進行一輪優(yōu)化過后，還會再次的測試并檢驗優(yōu)化目標是否達標。
• 上手更容易：綜上所述，你會發(fā)現場景自助測試的實施門檻較低，測試用戶也比較好找，投入少見效快靈活高，可以幫助設計師獲取真實的用戶之聲，找到產品難上手不好用的問題根因。

二、ToB+場景自助測試=如虎添翼

B端產品更工具化，通常圍繞特定行業(yè)的業(yè)務流程展開，客戶群體和業(yè)務流程都遵循著某些規(guī)范或標準，這些特性使得場景自助測試會很適用。另外那些已經上線和具備一定用戶量的產品，特別是對于那些高度依賴用戶自助服務的企業(yè)來說，提升自助率不僅可以直接降低客戶服務成本，還能有效增強客戶滿意度，實現雙贏的效果。

同時B端產品具備復雜的功能體系與交互場景，學習門檻往往較高，如果不能提供友好的易用性或引導幫助，那些沒有經過培訓學習的用戶是很難通過產品自助展開工作的，變相的也會形成更多的人工支持成本。

另外當你的產品沒有靠譜的引導設計或是自助完成率不高時，這是一個危險的信號，根據我們的真實經驗，如果你的產品在價格或是售前培訓、技術支持等方面沒有優(yōu)勢的情況下，新客戶流失率或付費開通率也會不理想，其原因在于新客戶初次體驗產品時，不能順暢的走完核心流程而感到受挫甚至質疑產品，這時候客戶大概率會去挑選其他更好用的競品，畢竟對于公司來說，工具的快速上手或減少不必要的培訓學習成本也是很重要的。

那么回到場景自助測試，主要解決的正是產品難用、初次體驗不佳或是缺乏引導設計等主要問題，如此看來“ToB+場景自助測試=如虎添翼”這個公式便通俗易懂了。

三、實施步驟與注意事項

1. 實施步驟簡述

秉持著越簡單越實用的理念，我將整個實施步驟概括為“場景自助測試六連搞”；

1. 為什么要搞？——〉測試目標或指標是什么？
2. 搞那些？——〉圍繞目標的流程范圍是哪些？
3. 找誰搞？——〉測試對象的基本要求與日程邀約？
4. 搞咋樣？——〉記錄和觀察測試的過程
5. 哪沒搞好？——〉結果分析與問題整理
6. 怎么搞好？——〉制定方案與迭代計劃

這里不用糾結更細致的步驟或是模版，你就按照上面的問題把你對應的答案填進去都可以，焦點在于測試的過程與問題復盤規(guī)劃，當然，后面會給出一些案例與模版。

2. 不同步驟里的注意事項

1）為什么要搞？

首先確保產品的特性與發(fā)展階段適合發(fā)起場景自助測試，即產品偏向功能性，有一些復雜或者專業(yè)門檻，有更加定向的流程任務，同時屬于有一定用戶體量的發(fā)展型產品。

然后場景自助測試本身是關注的某些特定場景下，用戶是否能夠順暢地自助完成一系列相關聯的操作任務，所以要考慮這些任務的測試優(yōu)化，是不是能夠對直接影響核心業(yè)務流程或是能減少企業(yè)對人力等資源的投入。

至于發(fā)起的狀態(tài)可以是基于體驗優(yōu)化目標、新功能上線、功能改版、優(yōu)化點洞察、場景自助分檢驗等等。

2）搞那些？

有了目標或是指標后，接著就是制定好對應的流程范圍或者說測試模塊，盡量不要搞得太復雜，并且有多個任務節(jié)點時，要緊靠一條核心線路，任務線路不易過于分散。

制定大致的任務書或測試材料，提供給測試者的任務書不用很細致，給出一個貼合場景任務的目標，并標記出流程中幾個主要的事件階段即可；

例如我們根據政策要求上線了“賬戶注銷”，那么測試目標就可以是因為什么事決定將平臺的賬戶注銷，而事件階段則可以視情況拆分為；

1. 進入個人賬戶中心、

2. 找到注銷入口、

3. 瀏覽和同意注銷知情書、

4. 提交注銷信息、

5. 確認和退出賬戶。

測試材料部分主要是便于我們自己發(fā)起和記錄測試過程的腳本，里面通常會記錄一些話術、測試計劃、任務流程簡圖、對應任務目標的事件階段表格、以及整理問題相關的表單為主，不過不用擔心，后面你會看到案例與簡單易懂的模版。

3）找誰搞？

首先你不用糾結對方是不是典型或是資深用戶，最基礎的是保障行業(yè)對口，起碼要對相應的業(yè)務流程有一定的認知，打個比方我們做一款開發(fā)者流程管理工具，那我們招募的用戶一定不能是一個對產品研發(fā)流程一竅不通的用戶。

接著對應到不同的流程場景，我們可以清晰的知道，一般是一些什么職能的角色會用，這些條件是需要符合的，至于對方是陌生人、同學、同事、朋友就不那么重要了，人數上基本上采用≧5即可，人越多自助通過率數據越精準。

考慮到重點關注的是產品上手與核心功能的自助情況洞察時，你可以關注一下對方是否有用過或了解過我們的產品，以及之前有多久沒有使用過我們的產品了，這次是否能夠測出新的發(fā)現。

最后則是發(fā)起邀約，不論是問卷、線上留言、電話邀約都好，總之確認哪些人可以抽出一些時間參加測試，把測試的時間、地點、參與方式(線上or線下)、獎品信息等記錄好，并如期推進。

在邀約時，一定要簡要說清你是誰？要做什么？有什么回報？以及告知沒有什么難度，也不會占用太久的時間，只是做一下產品體驗官幫助檢驗產品體驗如何，不要讓對方覺得很困難或很麻煩，這很重要。

4）搞咋樣？

到場后先把一些必要工作準備好，比如測試的設備、軟件或是賬號資料、測試環(huán)境、測試記錄的紙質表單跟筆的檢查等，為了更好的跟蹤整個測試的過程以及后續(xù)的復盤整理，所有在電腦或手機上進行的測試，可以提前準備好音視頻錄制軟件，例如常用的視頻會議的錄制功能。

測試前可以先寒暄一下，可以遞上一杯水、聊聊天氣、出行啥的，通過彼此的簡單互動減少緊張的氣氛，然后將測試的目標、任務與材料分發(fā)下去，并宣讀介紹一下此次的測試任務，可以著重說一下此次測試主要是根據任務目標自主進行，如果遇到問題可以放緩節(jié)奏，多看看界面的信息與功能，并根據自己的認知與直覺進行下一步，另外遇到問題時，最好能夠口述出疑問是什么，你準備怎么應付，便于觀測者了解測試者心里的想法。

當確認測試前準備沒有問題后，就可以告知和開啟屏幕錄制并進行測試了，而你要做的就是在一旁安靜的觀察，做對方的傾聽者，并在表單上記錄好測試者在各個任務節(jié)點上的表現與結果，是否在某個節(jié)點上卡住而完全不能進行下去。

關于是否要對測試者的卡點進行干涉，你需要明確以下幾點；

1. 首先是不是已經達到了測試的目的，確認了用戶自主使用時的磕磕絆絆或無法通過了，如果是就可以盡早結束不用干涉了；
2. 如果此次測試的任階段比較豐富或涉及多個模塊，那么你記錄好測試者的卡點情況后，就可以引導至下一個節(jié)點，以完成后續(xù)階段或模塊的卡點洞察。

記錄問題，在測試過程中，用戶遇到問題或卡住相應的在任務列表中進行記錄，并將測試者的反饋簡要備注。

測試結束時，可以根據記錄的問題，與測試者延展性的聊聊感受與預期，查缺補漏一下，通常這時候測試者是很愿意吐槽的，借此機會，你還可以延展一些問題，例如競品偏好、個人習慣、對未來有何建議等，也可以酌情考慮跟可用性測試一樣做任務后評估問卷（ASQ）、系統可用性問卷（SUS）或是用戶滿意度問卷，不過我們一般都是問一些想要了解的問題，不愛做這些測試后問卷調查～

5）哪沒搞好？

重點是那些直接造成卡點的問題，這些問題意味著直接中斷了核心任務的進程，導致用戶無法自助使用產品完成任務，這種時候就很可能造成用戶流失或需要提供技術支持，所以屬于關注重點。

然后就是磕磕絆絆的問題，即用戶花費了些時間精力才勉強完成的任務，這些問題說明了布局結構、文案信息、交互方式等方面還存在著明顯的提升空間，當然因為技術原因導致的卡頓、緩慢也不容忽視。

最后則是測試者的吐槽與建議，如果在測試結束后做了些小訪談，那么對應提問的問題一定會有一些收獲，其次用戶在吐槽哪些功能不好用之余也會給出原因或是建議，都是可以適當聽取的。

問題歸檔，結合測試者的表現與反饋將磕磕絆絆的問題完善到測試任務列表中，并且可以根據視覺、交互、產品邏輯、技術支持、功能滿足等標簽進行標記，以便于后續(xù)的整理歸類。

通過率計算一般分兩個維度，一是單個用戶在整套任務中，能夠自助完成的任務比例。然后就是統計所有測試者中能夠自助完成全套任務的人數比例，后者代表了場景自助的通過率，可以結合任務的復雜程度與技術支持的程度，預設一個更高的通過率作為下次的優(yōu)化目標，如果你期望你的產品擁有更好的用戶自助表現，那么可以給出一個較高的目標分，并根據研發(fā)里程分成多個階段逐步上分。但如果你的產品確實比較復雜或專業(yè)，就沒必要大范圍的追求普遍的高通過率了，還不如多想想怎么提供更多的教程或引導資料。

6）怎么搞好？

• 問題分析：把測試出的問題進行整合去重，把問題的重要性、影響性、優(yōu)先級信息進行初步完善，以及根據問題情況將引起流程卡點或阻礙的原因進行說明，如果有相關的埋點數據或用戶行為報表可以結合起來一起分析，以彌補測試采樣有限的不足。
• 團隊溝通：將洞察的問題進行及時的同步，便于大家清晰的看到產品存在的問題，建立共同目標并強化協作，并借助團隊的集思廣益將問題進行整理完善，其中主要包括了問題的解決方案、優(yōu)先級、責任分工等。
• 分工排期：當問題基本整理完成，就可以根據優(yōu)先級或是重要程度，將問題分批，并拉上主要的PD、開發(fā)、測試相關人員進行一輪初步的排期計劃，并協同分工，例如代碼優(yōu)化跟交互設計優(yōu)化就可以考慮并行開始減少工期，當然也可以將問題逐個擊破。
• 制定下個通過率目標：說句廢話就是“既要體現優(yōu)化的決心，又要確保目標的可行性”，不同產品的復雜性有差異，沒有一個標準答案。在我的認知里，測試者的采樣越多，自助測試的通過率越準確，且越往后優(yōu)化，分值越難提升，個人意見是將當前通過率加上剩下不通過的一半取整后作為下一個目標分，例如當前通過率是60%，則目標分就是60%+(40%的一半)=80%，若整體優(yōu)化難度比較大，則可以將整個目標分期執(zhí)行，第二次的整體的通過率出來后，也可以結合起來對目標通過率進行微調。

四、應用案例

1. 背景簡述

內部項目不方便公開，這里引入一個類似的研發(fā)效能產品進行講解學習。

主要是針對華為云的研發(fā)管理工具的場景自助測試，檢驗作為最基礎且免費的項目需求管理工具自助體驗如何，是否能夠讓用戶快速上手，為后續(xù)的更多云服務開通或嘗試做好鋪墊，其中參與測試的采樣做了縮減以及一些相關信息脫敏處理，不過不影響整體的方法應用學習哈，那么，咱們開始本次的場景自助測試。

2. 測試目標

用戶是否可以根據訴求快速創(chuàng)建一個基礎的項目需求看板，創(chuàng)建后是否可以快速上手需求管理面板，并自主的創(chuàng)建或編輯相關需求，以驗證項目需求管理部分的場景自助率如何？是否能夠滿足用戶的基本訴求以留住用戶，并引導用戶試用和開通更多的其他研發(fā)增效工具。

3. 任務范圍

測試產品：華為云研發(fā)效能工具核心模塊：項目需求管理關聯模塊：登錄注冊、項目管理、需求看板創(chuàng)建、需求屬性配置、項目需求管理任務流程說明：以賬戶登錄為起點，歷經項目創(chuàng)建到需求屬性配置、項目需求創(chuàng)建管理與流程狀態(tài)扭轉為主

4. 邀測對象

此處的要求需要根據不同平臺產品的特征來做調整，以下是針對本次測試案例的測試者要求情況；

5. 邀請方法

內部邀請

內部招募還是比較簡單的，例如跨項目組、跨業(yè)務線、是比較容易招到人的，只要按照測試計劃說明測試的背景跟獎勵信息即可，可以建立合作關系，以后互相協助測試，同時提出是為了公司的整理利益發(fā)展，然后當對方有意愿參與測試后，就可以根據測試的周期與對方約定詳細的測試地點、時間日程等信息了。

外部招募

相比于內部邀請，對外邀請需要準備的工作會更多一些，出了說明我們是誰？需要做什么？有什么回報、占用時長或難度情況以外，還要明確告知符合參與的條件，要準備簡易的知情協議，如果項目還未上線，可能還要準備保密協議相關，至于怎么寫這些協議，在網上找模板套用后打印出來等待用戶簽字即可。

招募渠道

此外招募的方式有兩大類，一類是通過線上用戶的數據層層篩選，然后面向合格用戶進行短信或是電話邀約。第二類則是通過發(fā)布招募信息，等待用戶主動申請，如果是要進行線下測試記得不要遺漏了詳細地址或出行指南。然后發(fā)到產品平臺的論壇、產品的答疑群、一些開放的IT技術交流群、技術型貼吧等都是可以的，以下是一份其他公司所發(fā)布的測試招募海報，信息已脫敏，可以參考以下；

參與獎品

具體看公司的預算來準備禮品即可，例如一些生活用品、平臺周邊、或是現金紅包等等，內部招募的話，甚至是簡單的一次下午茶、一杯奶茶都可以。

日程安排

基本信息就是確認什么人、在什么時間、什么地點、如何參與測試，像測試的會議室或空間等不是一開始就確認好的，那就需要在確認好后及時與測試人進行同步，除此之外還可以將參與者的一些與測試相關的信息進行記錄或備注，后續(xù)可以作為一個簡單的用戶畫像使用；

（注： 以下均為脫敏后的化名）

測試材料準備

任務書

記錄表

記錄表主要是便于我們測試時，記錄核心流程下，每個操作節(jié)點下的用戶反饋或結果，所以會比任務書更詳細一些，這樣我們才能夠記錄下更詳細的測試數據，便于分析整理，通常記錄表由細化的操作節(jié)點、序號、測試結果、反饋記錄等信息構成，以下為本次測試所用的記錄表電子版可供參考，實際測試前，我們會打印出來手動記錄測試信息：

訪談問題

訪談問題是針對場景自助測試之外的一些補充問題，或整體感受評估，一般由一些特定的產品體驗問題或是SUS系統可用性問卷構成。

針對本次的測試任務，我們提出了以下問題來幫助我們獲取更多有用的信息來幫助產品提升場景自助率。

場景自助測試腳本

就是提前做好測試攻略，將測試安排、話術、注意事項提前預備好，方便開展過程隨時參考或是預先彩排用。

測試設備準備

不同平臺產品的測試任務，對測試設備、版本、環(huán)境、賬戶、權限等均有差異，所以在測試前需要提前了解情況或做好相關準備，以減少測試過程的差錯，對此你可以參考以下表格自檢；

進行測試

• 根據約定的日程安排場景自助測試，并按照提前準備的測試腳本或彩排開展起來。
• 【針對本次測試】考慮到任務體量不大，我們預期讓測試人將把全部任務走完，若期間測試人確認卡點了，則引導測試人通過卡點任務繼續(xù)后續(xù)的任務測試，其他情況則基本不做干涉，由用戶自主進行；

場景通過率

通過率計算

※通過率說明：即計算不能自助完成測試人數占所有人數的占比

※場景自助通過率：4/5 = 80% （采樣人數5，自助通過測試人數4，通過率80%）

問題分布統計

主要根據任務流程與操作項標記出所有測試者的任務卡點情況、卡點重災區(qū)節(jié)點、以及通過率或任務完成率情況，這些可以讓我們快速感知要關注的部分，以及全局概況。

問題整理歸檔

主要是把此次測試的過程材料與相關問題進行線上整合，并存儲歸檔。

任務記錄表歸檔

以下為本次的任務記錄表，其中有記錄測試人俞洋反饋的部分問題，整體就是圍繞多個測試人反饋，將問題按照測試的任務流程記錄到表里并進行概括性總結，以下記錄表可做模版參考；

訪談問題歸檔

主要是測試后的訪談問題整理歸檔，結構與以上任務記錄表相似，歸檔后可以將兩個表放在一起，以下訪談記錄歸檔可做模版參考；

附件材料

將此次場景自助測試相關的材料放入對應計劃下的知識庫或文件管理中，例如簽署材料、錄制文件等，你可以將這些信息與前面的問題記錄整合在一個文檔中也可以；

（注： 以下均為脫敏后的化名）

分析總結

根據大致的任務階段與操作步驟，將問題概括性的整理出來，可以對問題類型、解決方案之類的信息進行初步的完善，然后經過與項目成員的溝通探討后，就可以對優(yōu)先級、分工情況、排期計劃等信息進行補充，當然這些也可以由項目經理或是產品經理來接手推進，之后就是產品負責人創(chuàng)建優(yōu)化迭代與需求優(yōu)化推進了。

經過初步整理的問題規(guī)劃表格可以參考如下，并且后續(xù)可以持續(xù)的維護優(yōu)化解決的進度，當然你也可以在此套表格的基礎上去做其他潤色或變化，你覺得怎么好用怎么來吧，例如給重點部分加上色塊標記等；

結語

以上就是我們經常用作B端產品體驗監(jiān)測與改善的洞察工具，從為什么要用，怎么用，應用的案例參考模版基本上都在此篇中交代完了，不論你是項目經理、產品經理、或是設計師，我都建議你嘗試一下這套物美價廉的工具，絕對比憑借著經驗做出來的體驗洞察與優(yōu)化更可靠，另外補充兩點：

1. 不同產品的訴求有差異，以上的案例模版需要自行辨別調整后用到自己的項目上，并且你也不必非的按照上面的模版完全復刻執(zhí)行，有其他更好的記錄方式或是配套工具，你可以靈活調用。
2. 實際作業(yè)時，不同職能的我們關注的信息或是階段流程都有差異，因此以上整套流程僅作參考，那些需要你關注或執(zhí)行，同樣的，你可以靈活操辦。

好了，碼字不易，歡迎點贊收藏，評論區(qū)留言互動。