B端體驗度量衡:體驗度量衡指標以及實施篇
編輯導語:在B端工作中,針對體驗度量的常見體驗度指標有三個:CES、NPS和SUS評分量表,它們分別有不同的使用場景和不同的特點,本文作者對這三個體驗度量指標以及它們的計算方式進行了分析,一起來看一下吧,希望每個設計師都能擁有話語權而不是當一個“美工”。
上一篇講了關于用戶行為監測的部分,這一篇主要是常用的體驗度量指標以及計算方式。針對體驗度量在工作中常見的有體驗度指標有三個:CES、NPS、SUS評分量表,接下來會一一進行講解。
一、CES
CES易用度主要場景在產品前期跟全量上線后:
- 產品前期:找得用戶的痛點
- 全量上線后:設計價值的驗證
是一個結合專家與真實用戶的度量指標。
1. 使用過程
1)針對功能進行調研
招募對象:
- 3名以上的專家
- 10名以上的真實用戶
真實用戶的選擇上,如果是做新產品或功能的調研,可以找全部使用用戶。但是如果是流程上,找老用戶能夠有更好的測試效果。調研專家除了可以是通過朋友或者是公司內部的專家進行調研,還可以通過第三方尋找合適的專家(通常比較貴)。
2)表格的制定
根據業務目標(或者是期待值)制定表格內容,常見的分類是:
- 易操作性:主要是針對流程進行統計,測試流程的優化是否達到用戶預期
- 易學性:主要是測試用戶學習起來的成本是高還是低(通常是讓用戶學習成本低)
- 易見性:針對視覺效果進行統計
打分機制:通常是1-10分,5.5分為中間分。5到1分是反對強度有低到高,6到10分是同意強度是由低到高的過程。
3)收集后,進行計算
計算公式:
分解:分成括號外和括號里進行分解。
括號里:
- X-真實用戶的每道題的得分;
- y-專家每道題的得分;
- ∑-求一定范圍數值的和;
- k-表格的最后一道題的數值。
括號里主要是求每道題的平均值。
括號外:
- M-真實用戶人數;
- N-專家用戶人數;
- 0.6-真實用戶權重;
- 0.4-專家權重。
注意點:權重這里專家不要等于或者是超過真實用戶,如果這么做會導致最后設定的結果與實際場景不符,違背了調研的初衷。
4)評分標準
最后會算出來一個值,數值的范圍在:0-10之間。
評分標準分:
- 差:0-5分;
- 中:5-7分;
- 優:7-8.5分;
- 卓越:8.5-10分。
基準線(基礎要達到的數值):5.5分。
2. 為什么不用滿意度
滿意度跟CES都是常用的指標,很多場景下很多人分不出來兩者的區別。其中滿意度更偏向于C端,因為用戶做調研時候更加的客觀,更能注重自身的感受,跟調研方沒有直接的利益沖突和聯系。
但是B端場景中內部用戶還會考慮到其他的主觀因素:
- 合作關系:雙方合作時候,如果是一個人評價自己的同事或者是搭檔的情境下,會思考到給與差評思考的顧慮,這里面也有可能是主觀給與對方差評的可能行。比如:經典的不要讓一個產品經理評價程序員。
- 中庸傾向:中國文化里面的中庸之道淵源流傳,影響到了大部分人,尤其是在可能有利益相關人員的打分的時候就會有主觀因素的影響。
會導致調研測量不準,而會對后面產品設計給與錯誤的引導。
二、 NPS
NPS(凈推薦值):主要場景是觀測是否有良好的口碑或者用戶流失的風險。
通常的評分機制是0到10分,主要分為三個類別:
- 0-6分 : 貶低者
- 6-8分:被動者
- 8-10分:推薦者
計算方式:(9分到10分的調研者比例)-(0分到6分的調研者的比例)。
這里的計算完全可能出現負數,所以提前一定要有心理預期(之前真的出現了負數,然后組里有人emo了)。找到問題解決問題就好,千萬不要emo。
三、 SUS評分量表
可行性測試:讓用戶使用原型或產品來發現實際頁面中的可用性問題,屬于典型的定性研究。
1. 使用場景
主要集中在兩個場景:
- 上線前測試DEMO
- 上線后進行測試,預測效果如何
2. 可用性測試流程
1)前期招募
通過客戶成功推薦/系統內發信息等多種方式PUSH到用戶,使得用戶自愿加入到可行性測試當中。招募10名以上的用戶,保證樣本的多樣性進行測試。
這里有個3小技巧如何進行招募:
- 針對同事:很多客戶成功怕麻煩到了用戶之后會導致續約率下降,所以一般很難推薦。那我們跟客戶成功溝通的時候,就主打的是如何提高續約率(這個辦法跟怎么跟開發溝通時候相同,就告訴他“這個用戶體驗優化后您能幫助他進行升職加薪”那他大概率會幫你的)。
- 針對用戶:在PUSH信息中,直接挑明利益點(獎勵)可以讓客戶更直接的做出自己的選擇,如果他們想要獎勵的話整個流程之中會更加的配合,效果會更好。
- 說到做到:說好的獎勵一定要能夠實現,如果不能夠實現的話一定要準備好如何去解釋,要不然會失去用戶的信任。
測試方法:整體的測試方法類似于劇本殺,不過是用在商業之中為的是實現商業目的。
發放任務卡,進行角色扮演,以一個實際任務流程串聯起來,也可以是以工作坊(工位)完成一個游戲,并且給與獎品。
測試卡片一般分為4個部分:
- 場景描述:主要是描述職位信息,以及要做的任務是什么,有什么流程先給予用戶的預期;
- 測試任務:測試人員引導被測試人員完成的測試任務;
- 完成情況:這里是測試人員根據測試情況進行如實的記錄(一般情況下還要記錄以及詢問為什么,后期可以作為設計的依據);
- 主觀報告:用戶根據主觀進行判斷滿意度如何。
2)評分標準
主觀報告通常情境下都是5分制,1分到5分表示非常不統一到統一的強度。
3)計算方式
可行性測試的計算方式需要轉化值的操作:
- 奇數項:得分-1
- 偶數項:5-得分
轉化完之后,全部的值相加。總值乘以2.5得到sus總分。推薦值:B端行業平均得分是67.7分。如果低于這個分值的話,那得回溯看哪里除了問題。
四、 總結
以終為始,從業務目標與用戶出發制定相關的okr。使用易用度測試和可行性測試來診斷現有產品的問題,結合用戶行為監控的方式來制定設計策略以及流程優化方案可以有依據的的進行設計。
從而驗證設計的價值,獲得項目的話語權而不是只是一個頁面做的很好看的“美工”。
本文由 @一只雞腿 原創發布于人人都是產品經理,未經許可,禁止轉載
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
正面問題:得分-1
反向問題:5-得分
SUS那里的計算方式有誤哦
其實這個跟我這個一樣,我們是正面的是奇數,反向問題是偶數。
偶數項分數+4 ?
對的
我重新思考了一下,是不是我倆說的是不是不同的計算方式?
反向問題+4的話,分數超過5分了,正向問題轉化都在4分內,你給反向問題設置的分數是負分嗎,為什么正負問題分數值不統一,我看一般SUS量變的反向問題都是 5-得分
這個我再仔細去查一下,謝謝反饋
查了一下計算方式,的確是我寫錯了,謝謝糾正。馬上修改。
謝謝指正