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

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

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

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

一、認(rèn)識場景自助測試

1. 起源

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

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

2. 概念

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

3. 價值

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

4. 原則

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

5. 優(yōu)勢

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

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

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

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

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

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

三、實施步驟與注意事項

1. 實施步驟簡述

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

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

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

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

1）為什么要搞？

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

然后場景自助測試本身是關(guān)注的某些特定場景下，用戶是否能夠順暢地自助完成一系列相關(guān)聯(lián)的操作任務(wù)，所以要考慮這些任務(wù)的測試優(yōu)化，是不是能夠?qū)χ苯佑绊懞诵臉I(yè)務(wù)流程或是能減少企業(yè)對人力等資源的投入。

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

2）搞那些？

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

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

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

1. 進(jìn)入個人賬戶中心、

2. 找到注銷入口、

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

4. 提交注銷信息、

5. 確認(rèn)和退出賬戶。

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

3）找誰搞？

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

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

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

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

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

4）搞咋樣？

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

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

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

關(guān)于是否要對測試者的卡點進(jìn)行干涉，你需要明確以下幾點；

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

記錄問題，在測試過程中，用戶遇到問題或卡住相應(yīng)的在任務(wù)列表中進(jìn)行記錄，并將測試者的反饋簡要備注。

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

5）哪沒搞好？

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

然后就是磕磕絆絆的問題，即用戶花費了些時間精力才勉強(qiáng)完成的任務(wù)，這些問題說明了布局結(jié)構(gòu)、文案信息、交互方式等方面還存在著明顯的提升空間，當(dāng)然因為技術(shù)原因?qū)е碌目D、緩慢也不容忽視。

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

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

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

6）怎么搞好？

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

四、應(yīng)用案例

1. 背景簡述

內(nèi)部項目不方便公開，這里引入一個類似的研發(fā)效能產(chǎn)品進(jìn)行講解學(xué)習(xí)。

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

2. 測試目標(biāo)

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

3. 任務(wù)范圍

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

4. 邀測對象

此處的要求需要根據(jù)不同平臺產(chǎn)品的特征來做調(diào)整，以下是針對本次測試案例的測試者要求情況；

5. 邀請方法

內(nèi)部邀請

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

外部招募

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

招募渠道

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

參與獎品

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

日程安排

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

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

測試材料準(zhǔn)備

任務(wù)書

記錄表

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

訪談問題

訪談問題是針對場景自助測試之外的一些補(bǔ)充問題，或整體感受評估，一般由一些特定的產(chǎn)品體驗問題或是SUS系統(tǒng)可用性問卷構(gòu)成。

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

場景自助測試腳本

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

測試設(shè)備準(zhǔn)備

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

進(jìn)行測試

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

場景通過率

通過率計算

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

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

問題分布統(tǒng)計

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

問題整理歸檔

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

任務(wù)記錄表歸檔

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

訪談問題歸檔

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

附件材料

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

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

分析總結(jié)

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

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

結(jié)語

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

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

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