「可用性測試」高效應用在B端產(chǎn)品的實踐案例
編輯導語:在做B端產(chǎn)品時,是否經(jīng)常會遇到一些困擾,和技術部門、客服等等所持的意見不一致,無法從根本上解決問題。本文作者就分享了在可用性測試的應用實踐經(jīng)驗,一起來看看吧,希望對你有所幫助。
在產(chǎn)品設計和研發(fā)過程中,你會不會時常遇到以下困擾:
- 產(chǎn)品新功能上線后,收集到的用戶反饋意見不一致,比如“有人覺的直接展開操作更方便,有人覺得滑動操作更好用”,“有人覺得頁面藍色風格不好看”,“排版設計吐槽不好看,信息太密集,抓不到重點”…
- 在設計方案的過程中,針對某個功能有多個設計方案,無法判斷哪個方案更優(yōu);
- 產(chǎn)品已經(jīng)開發(fā)完成,想在上線面客前檢驗下是否滿足用戶的使用需求?滿意度如何?
業(yè)務和客服人員往往需要花費大量的時間和精力去收集、處理用戶的投訴反饋。但是因為面對用戶的投訴或者反饋建議五花八門,都有各自的立場,無法明確分析出問題在哪里。
面對這類問題,技術部門通常都是通過版本回退等方式臨時解決用戶的投訴反饋,無法從根本上有效的解決用戶的問題。
那么有沒有其他更科學高效的解決問題的方法呢?
這里為大家分享一下我們在可用性測試的使用上的一些實踐經(jīng)驗,把我們在B端產(chǎn)品上面對這些場景的時候做的一些工作分享給你,期望能給你帶來一些直接的幫助。
目錄:
一、可用性測試基本概念
我們先看看國外體驗設計專家Jeffrey Rubin和Dana Chisnell在《Handbook of Usability Testing》書中關于可用性測試(Usability testing)的定義:
說明:典型用戶即是指真正使?產(chǎn)品的?戶、潛在?戶或者意向?戶等。產(chǎn)品設計開發(fā)出來是給典型用戶使用的,只有通過典型用戶的可用性測試收集到的數(shù)據(jù)和信息才是有意義的。
在ISO 9241-11:2018針對可用性的概念是指:
“特定的用戶在特定的使用場景下,為了達到特定的目的而使用某些產(chǎn)品時,所感受到的有效性、效率及滿意度?!?/strong>因此可用性測試也是通過測試來找出產(chǎn)品在有效性、效率性以及滿意度三方面存在的問題,并針對性進行改善,以此來提高產(chǎn)品的體驗。
二、可用性測試的價值
可用性測試是改善產(chǎn)品的比較科學有效的方法之一。
有時,我們并不是產(chǎn)品的目標用戶,很多需求和設計方案是產(chǎn)品及設計人員自己想出來的。雖然我們在設計時會依據(jù)一些經(jīng)驗與設計法則,但這些都只是未經(jīng)驗證的主觀猜測,無法準確的評估設計方案的優(yōu)劣。
所以為了真正的了解用戶,我們需要找到我們的目標用戶并向他們學習,這樣才能使產(chǎn)品各關聯(lián)方盡快對設計方案達成一致并積極改善產(chǎn)品體驗。
可用性測試的價值可以概括為以下幾方面:
通過可用性測試,我們最終要達到的目的:提升產(chǎn)品用戶體驗和滿意度,助力業(yè)務目標達成。
三、可用性測試的類型
1. 可用性測試適用場景
可用性測試可以在產(chǎn)品的任何階段進行,不同場景下可用性測試的側(cè)重點不同。我們一般在產(chǎn)品上線前側(cè)重方案驗證;在上線后側(cè)重找出問題,進行迭代優(yōu)化;同時也會日常定期開展可用性測試,針對重點或者高頻功能進行體驗跟蹤,持續(xù)優(yōu)化體驗。
2. 可用性測試分類
可用性測試的類型主要分為分析法(偏定性)和實驗法(偏定量),區(qū)別在于是否有用戶參與。以下為兩種測試類型主要對比:
從某種程度而言,分析法和實驗法是一種互補的關系,不同的測試方法適用的場景不一樣,需要根據(jù)測試目標、問題場景、產(chǎn)品所處的階段、經(jīng)費預算、時間周期等因素選擇適合的測試方法,以最優(yōu)的方式來達成可用性測試的目標。
接下來我們通過一個過往的案例,來跟你分享一下我們是怎樣結合目標來選擇測試方法的。
1)案例場景
某產(chǎn)品有兩個入口,分別為產(chǎn)品列表的入口和首頁banner入口。 我們通過用戶點擊數(shù)據(jù)發(fā)現(xiàn)首頁banner點擊率比較低,多數(shù)用戶還是通過產(chǎn)品列表的入口進入。我們希望分析找出banner入口點擊率較低的原因,提升banner入口的點擊率。
2)原因分析
從產(chǎn)品、設計及體驗角度分析:banner樣式、是否有動效、banner的大小、banner的位置、banner顯示的文案等因素都會影響到最終的點擊率。
3)可用性測試方法策略
- 先用專家評審、啟發(fā)式評估的方式分析了現(xiàn)有的問題,針對問題輸出2個不同的方案;
- 采用A/B Test的方式,在小范圍內(nèi)對2個方案進小范圍線上投放,結合投放數(shù)據(jù)選出轉(zhuǎn)化率最高的banner正式上線。
四、如何組織一場更有效的可用性測試
結合我們的實踐經(jīng)驗,我們把可用性測試分成7個階段:
接下來我們會結合在小企業(yè)融資貸款產(chǎn)品領域的可用性測試實踐,來具體分享如何組織一場可用性測試。
背景說明:面向中小微企業(yè)的融資貸款產(chǎn)品,針對企業(yè)主和企業(yè)用戶提供貸款資金進行經(jīng)營周轉(zhuǎn)。申請人可以通過線上進行貸款申請、合同簽署、提款、還款等操作。
業(yè)務訴求:由于歷史原因,現(xiàn)有的功能框架陳舊,日??蛻糍J款申請及使用過程中反饋的問題較多;同時客戶申請轉(zhuǎn)化率不高,申請環(huán)節(jié)流失率較高。業(yè)務部門希望了解產(chǎn)品功能和流程中存在哪些體驗問題?如何提高客戶申請轉(zhuǎn)化率,實現(xiàn)業(yè)務增長?
基于以上背景,我們決定針對小企業(yè)融資貸款產(chǎn)品進行一次可用性測試,幫助業(yè)務解決遇到的問題。
1. 需求收集
可用性測試通常是由設計師發(fā)起的,但是需求并非僅來源于設計師,可以是用戶、業(yè)務、產(chǎn)品、技術等角色的反饋。比如用戶反饋的問題、異常數(shù)據(jù)、階段性的業(yè)務目標、版本迭代優(yōu)化、常規(guī)的用戶行為數(shù)據(jù)監(jiān)測、創(chuàng)新產(chǎn)品方案設計等都可以作為可用性測試的需求來源。
我們通過建立可用性測試需求清單,統(tǒng)一收集各方提出的可用性測試需求,然后對需求進行統(tǒng)一合并、篩選、確認優(yōu)先級等,納入到可用性測試計劃排期,然后協(xié)同各方一起推動可用性測試計劃的執(zhí)行。
圖例:可用性測試需求收集清單模板
2. 編寫測試方案
在收到可用性測試需求后,我們需要根據(jù)需求制定可用性測試方案。一份完整的可用性測試方案由以下幾塊組成:
以下為針對小企業(yè)融資貸款產(chǎn)品可用性編寫的測試方案示例:
1)明確測試目的和范圍
在測試前,需要與需求提出方進行溝通,確定需要測試的產(chǎn)品是什么,想要驗證什么樣的結論或者達到怎樣的預期,是為了發(fā)現(xiàn)產(chǎn)品或原型中可用性的問題,還是借此與競品進行有效性、效率、滿意度的比較,或是對某些功能點進行測試等。明確本次測試的產(chǎn)品及范圍,以便后續(xù)測試工作的高效進行。
2)確定測試任務
可用性測試任務是指導測試進行的操作指引,我們通常會根據(jù)測試的需求和目標,把任務進行場景化設定,以任務腳本的形式引導用戶進行測試。測試任務腳本內(nèi)容包括:開場引導、任務設定、滿意度評估、結束后訪談等。
可用性測試一般情況下需要多人協(xié)同配合進行,由于涉及內(nèi)容較多,對被測用戶進行的活動任務也比較復雜且環(huán)環(huán)相扣,所以為了保障測試任務更好的實施,一般情況下會準備一份較為完整的測試腳本以供測試人員更好的配合。
圖例:xxx貸款產(chǎn)品可用性測試腳本模板
① 開場引導
向被測者介紹測試的目的,需要注意的事項等,測試前也可以做一個聊天式的溝通,了解用戶對產(chǎn)品的使用情況,幫助用戶將注意力轉(zhuǎn)移到產(chǎn)品上,為測試做鋪墊。
② 任務設定
設計測試任務就是“誰在什么情況下要做什么事”,緊抓“人”、“場景”、“目標”三個要素。任務設計的幾條核心原則:
a) 根據(jù)測試目的列出任務清單,任務不宜過多,必須是緊貼核心測試任務的。
比如針對貸款產(chǎn)品,用戶的核心任務就是申請、簽約、提款和還款。因此我們的任務設定就需要圍繞這幾個主流程進行。
b) 將任務賦予真實場景,畢竟用戶使用產(chǎn)品都是有真實場景的。
比如貸款產(chǎn)品申請,模擬用戶在資金鏈緊張的場景下,如何找到并完成貸款產(chǎn)品的申請流程。
c) 明確測試任務起點和終點,判斷用戶是否完成了任務的主要依據(jù)就是,用戶是否從起點(頁面A)到達了終點(頁面B)。起點未必一定要是首頁,起點位置應根據(jù)具體場景來確定,畢竟并不是每個任務都是從首頁開始的。
比如貸款申請,任務的起點是貸款產(chǎn)品的申請入口,任務的終點是完成貸款申請?zhí)峤弧?/p>
③ 滿意度評估
在每一次任務完成后,可以讓用戶對任務進行評分,注意評分要有相同的維度,否則無法進行統(tǒng)計。比如可以從產(chǎn)品功能的滿意度、操作的便捷性滿意度進行評分,評分可以采取5分制。最后計算平均值得出每個任務的平均滿意度分值。所有的任務平均分值再計算平均得出整個產(chǎn)品的綜合滿意度評分。
評估量表可以考慮比如SUS量表、ASQ量表等。具體選擇哪種量表需要根據(jù)測試的場景、目標等選擇合適的即可。以下為關于SUS量表的基本介紹信息:
以下為我們在某次可用性測試用使用的SUS量表示例:
圖例:針對某款貸款產(chǎn)品可用性測試SUS評估量表模板
④ 結束后訪談
在完成測試任務后,可以對用戶進行訪談,訪談目的是收集用戶對產(chǎn)品的其他反饋意見,同時也可以對測試記錄過程中有遺漏的地方進行回顧確認。
3)明確用戶招募
我們需要根據(jù)測試選用的具體的可用性測試方法,在方案中明確用戶招募的內(nèi)容。一般用戶招募需要從以下幾方面進行考慮:
① 招募的類型
通常招募的用戶類型分為:小白用戶、專家用戶。在招募時為了結果數(shù)據(jù)真實可靠,應避免該產(chǎn)品相關人員的參與。通常優(yōu)先選擇有代表性的用戶,其中真實的產(chǎn)品目標用戶為最佳。
② 招募的來源
招募的來源一般分為內(nèi)部招募和外部招募。我們需要根據(jù)實際情況進行選擇招募的渠道,以便在招募階段按照確定的招募渠道來進行用戶招募。
③ 招募的數(shù)量
測試者不宜過多,一般5名左右就夠了。
根據(jù)尼爾森博士相關理論:有5個人參加的用戶測試,就可以發(fā)現(xiàn)85%左右的產(chǎn)品可用性問題。因此招募的用戶數(shù)量不是越多越好。
圖例:尼爾森用戶招募與問題關系圖
4)確定測試的關聯(lián)資源
可用性測試通常都是線下進行的,就需要提前準備相關的資源等,以便測試執(zhí)行階段正常開展測試。一般需要確定的關聯(lián)資源包括:場地安排、測試設備、測試環(huán)境數(shù)據(jù)(軟件安裝包/版本等)、輔助測試人員、測試結束后贈送的禮物(如有)等。
在測試方案里我們需要根據(jù)不同的事項進行分工,根據(jù)不同的資源準備事項落實到對應的責任人,以便更好的完成測試的準備工作和進度跟蹤。
5)確定各節(jié)點時間排期
在制定可用性測試方案的時候,很重要的一點就是我們需要根據(jù)整體的測試時間安排,確定各階段節(jié)點的具體時間排期,需要在節(jié)點時間內(nèi)完成該任務事項。同時與各關聯(lián)方達成一致后,大家都按照這個時間排期計劃往前推進。同時在臨近時間節(jié)點的時候,需要提前確認該任務事項完成進度情況,做到整體進度可控。
同時需要考慮突發(fā)情況下,可能存在事項延期或者未能如期完成的情況。如果出現(xiàn)意外情況的時候,我們的對策是什么等等。
3. 用戶招募
在確定可用性測試方案后,我們就要開始進行招募用戶了。
用戶招募的關鍵之處在于所招募的用戶要具有代表性,可以根據(jù)產(chǎn)品后臺的使用數(shù)據(jù),了解用戶的群體特征是怎樣的,比如性別、年齡、婚姻狀況、職業(yè)、居住條件等等特征分布,通過這些條件篩選,有助于更好的招募到典型的目標用戶。
結合小企業(yè)融資貸款產(chǎn)品可用性測試,在招募用戶的時候,我們通過后臺大數(shù)據(jù)分析平臺,了解小企業(yè)貸款用戶的群體特征是怎樣的,比如申請身份、職業(yè)角色、性別比例、年齡分布等,為招募用戶提供基礎參考數(shù)據(jù)。
圖例:xxx貸款產(chǎn)品可用性測試用戶招募
4. 測試物料準備
測試物料是在正式測試之前需要提前準備的事項,需要在執(zhí)行測試前進一步明確清楚是否已準備妥當。一般需要準備的測試物料內(nèi)容包括:場地安排、測試設備、測試環(huán)境數(shù)據(jù)、安排工作人員、明確用戶排期、發(fā)送測試邀請函及測試結束后贈送的禮物(如有)等。
5. 測試執(zhí)行階段
在正式測試執(zhí)行階段,主要分為以下流程環(huán)節(jié):
測試執(zhí)行是整個可用性測試的關鍵環(huán)節(jié),操作執(zhí)行的好壞直接影響到整個可用性測試的結果。我們需要按照之前的測試方案中的測試任務腳本,引導用戶按照腳本執(zhí)行測試任務, 同時在測試中要隨時觀察記錄用戶的操作遇到的問題以及用戶的情緒表現(xiàn)等。在每次任務結束后及時進行任務滿意度評分。評分過程保持客觀獨立評價,不要干擾用戶評分。
如果測試用戶遇到測試相關的問題,不要直接告訴用戶應該怎么做。為了保證測試順利的執(zhí)行,我們需要注意以下幾點:
6. 測試結果整理分析
1)原始數(shù)據(jù)的整理記錄
測試完成后需要盡快針對原始數(shù)據(jù)進行整理,數(shù)據(jù)和問題的整理應盡可能詳細,方便后續(xù)核對和查閱。針對可用性測試,一般需要整理的材料包括:測試觀察問題記錄表、任務完成效率統(tǒng)計表、任務完成有效性統(tǒng)計表、測試問題截圖或者錄屏文件整理。通過原始數(shù)據(jù)和材料的整理記錄,可以確保結果分析的數(shù)據(jù)的真實性和準確性。
圖例:單個任務完成效率的統(tǒng)計
2)測試問題匯總整理
針對記錄的問題,需要詳細記錄問題。一般會提前制定一份可用性測試問題記錄表,記錄表需要明確記錄問題出現(xiàn)的模塊、功能頁面、版本、手機類型、問題描述、問題截圖、用戶情緒反饋、測試記錄人、記錄日期等。
圖例:測試問題匯總統(tǒng)計表
3)數(shù)據(jù)分析整理
結果分析整理可以從定量和定性結果兩方面進行,定量的結果可以分析任務的完成情況、任務的滿意度等,并借助可視化的圖表進行展現(xiàn),比如:
① 統(tǒng)計任務的滿意度評分情況
我們會統(tǒng)計并計算單個任務的滿意度評分,并與總均值進行比較,對于評分比較低的任務功能則需要引起注意。后續(xù)需要重點分析滿意度低的問題在哪里。
比如小企業(yè)融資貸款產(chǎn)品完成情況整理結果如下:
② 統(tǒng)計任務的完成情況
任務完成一般可以分為完成、求助后完成、未完成三種情況,不同的完成情況用不同的色塊表示,然后統(tǒng)計完成率情況。
比如小企業(yè)融資貸款產(chǎn)品完成情況整理結果如下:
圖例:單個任務完成情況的統(tǒng)計
③ 定性結果的整理
根據(jù)記錄的用戶測試中的問題,分析具體的問題類型,劃分為不同的類型進行統(tǒng)計,可以進行概括總結,歸納問題點集中表現(xiàn)在哪些方面,比如功能問題、性能問題、交互問題、視覺問題等,通過問題類型分布圖可以清晰明確的看出問題集中在哪幾個維度。
比如小企業(yè)融資貸款產(chǎn)品問題類型分布圖如下:
圖例:問題類型分布雷達圖
7. 測試分析報告編寫
在完成測試結果整理分析后,就可以開始分析報告的編寫。報告內(nèi)容一般分為以下幾塊:
測試結果匯總、任務方案概覽、測試問題分析、競品分析、優(yōu)化解決方案及后續(xù)的優(yōu)化計劃。
可用性測試分析報告作為總結性的材料,不僅僅是對可用性測試過程的復盤,同時也是對各關聯(lián)方具有重要的價值。體現(xiàn)在以下三方面:
五、如何驅(qū)動用戶體驗提升
可用性測試可以幫助我們發(fā)現(xiàn)產(chǎn)品中存在的體驗問題,在完成可用性測試報告后,并不意味著工作的結束。我們需要將可用性測試發(fā)現(xiàn)的問題、解決方案等與各相關方進行溝通,推動問題與優(yōu)化方案納入版本迭代優(yōu)化,做好優(yōu)化效果的驗證及追蹤。不斷持續(xù)的通過可用性測試,打磨優(yōu)化產(chǎn)品的用戶體驗。
以上就是我們在B端產(chǎn)品可用性測試的實踐經(jīng)驗。不同的產(chǎn)品使用的可用性測試的方法是和我們的服務的產(chǎn)品和具體的測試的需求是有較強關聯(lián)的,不同的測試需求需要考慮測試的目標場景和是否有限定因素等,不能簡單直接復用。大家可以根據(jù)具體的情況使用可用性測試這套工具和方法。
我們的可用性測試大多情況下都是線下進行的,希望大家能為自己爭取機會,多嘗試和用戶溝通,你會發(fā)現(xiàn)很多之前想不到的問題,你對用戶的行為習慣了解越多,設計的時候就越能避免產(chǎn)生體驗的問題。這樣才能有助于提升產(chǎn)品的用戶體驗,更好的幫助業(yè)務達成目標。
作者:WOWdesign,研究設計價值最大化,涉及用戶體驗、品牌體驗、空間體驗。
本文由 @WOWdesign 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于 CC0 協(xié)議。
避免產(chǎn)生體驗的問題有助于提升產(chǎn)品的用戶體驗,更好的幫助業(yè)務達成目標。
讓各個環(huán)節(jié)步驟充滿了可使用性,收藏了這篇好文
簡直就是深度好文,總結概括的非常詳細,有心了有心了