編輯導語：在B端工作中，針對體驗度量的常見體驗度指标有三個：CES、NPS和SUS評分量表，它們分别有不同的使用場景和不同的特點，本文作者對這三個體驗度量指标以及它們的計算方式進行了分析，一起來看一下吧，希望每個設計師都能擁有話語權而不是當一個“美工”。

上一篇講了關于用戶行為監測的部分，這一篇主要是常用的體驗度量指标以及計算方式。針對體驗度量在工作中常見的有體驗度指标有三個：CES、NPS、SUS評分量表，接下來會一一進行講解。

一、CES

CES易用度主要場景在産品前期跟全量上線後：

是一個結合專家與真實用戶的度量指标。

1. 使用過程

1）針對功能進行調研

招募對象：

真實用戶的選擇上，如果是做新産品或功能的調研，可以找全部使用用戶。但是如果是流程上，找老用戶能夠有更好的測試效果。調研專家除了可以是通過朋友或者是公司内部的專家進行調研，還可以通過第三方尋找合适的專家（通常比較貴）。

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端場景中内部用戶還會考慮到其他的主觀因素：

1. 合作關系：雙方合作時候，如果是一個人評價自己的同事或者是搭檔的情境下，會思考到給與差評思考的顧慮，這裡面也有可能是主觀給與對方差評的可能行。比如：經典的不要讓一個産品經理評價程序員。
2. 中庸傾向：中國文化裡面的中庸之道淵源流傳，影響到了大部分人，尤其是在可能有利益相關人員的打分的時候就會有主觀因素的影響。

會導緻調研測量不準，而會對後面産品設計給與錯誤的引導。

二、 NPS

NPS（淨推薦值）：主要場景是觀測是否有良好的口碑或者用戶流失的風險。

通常的評分機制是0到10分，主要分為三個類别：

計算方式：（9分到10分的調研者比例）-（0分到6分的調研者的比例）。

這裡的計算完全可能出現負數，所以提前一定要有心理預期（之前真的出現了負數，然後組裡有人emo了）。找到問題解決問題就好，千萬不要emo。

三、 SUS評分量表

可行性測試：讓用戶使用原型或産品來發現實際頁面中的可用性問題,屬于典型的定性研究。

1. 使用場景

主要集中在兩個場景：

2. 可用性測試流程

1）前期招募

通過客戶成功推薦/系統内發信息等多種方式PUSH到用戶，使得用戶自願加入到可行性測試當中。招募10名以上的用戶，保證樣本的多樣性進行測試。

這裡有個3小技巧如何進行招募：

1. 針對同事：很多客戶成功怕麻煩到了用戶之後會導緻續約率下降，所以一般很難推薦。那我們跟客戶成功溝通的時候，就主打的是如何提高續約率（這個辦法跟怎麼跟開發溝通時候相同，就告訴他“這個用戶體驗優化後您能幫助他進行升職加薪”那他大概率會幫你的）。
2. 針對用戶：在PUSH信息中，直接挑明利益點（獎勵）可以讓客戶更直接的做出自己的選擇，如果他們想要獎勵的話整個流程之中會更加的配合，效果會更好。
3. 說到做到：說好的獎勵一定要能夠實現，如果不能夠實現的話一定要準備好如何去解釋，要不然會失去用戶的信任。

測試方法：整體的測試方法類似于劇本殺，不過是用在商業之中為的是實現商業目的。

發放任務卡，進行角色扮演，以一個實際任務流程串聯起來，也可以是以工作坊（工位）完成一個遊戲，并且給與獎品。

測試卡片一般分為4個部分：

1. 場景描述：主要是描述職位信息，以及要做的任務是什麼，有什麼流程先給予用戶的預期；
2. 測試任務：測試人員引導被測試人員完成的測試任務；
3. 完成情況：這裡是測試人員根據測試情況進行如實的記錄（一般情況下還要記錄以及詢問為什麼，後期可以作為設計的依據）；
4. 主觀報告：用戶根據主觀進行判斷滿意度如何。

2）評分标準

主觀報告通常情境下都是5分制，1分到5分表示非常不統一到統一的強度。

3）計算方式

可行性測試的計算方式需要轉化值的操作：

轉化完之後，全部的值相加。總值乘以2.5得到sus總分。推薦值：B端行業平均得分是67.7分。如果低于這個分值的話，那得回溯看哪裡除了問題。

四、 總結

以終為始，從業務目标與用戶出發制定相關的okr。使用易用度測試和可行性測試來診斷現有産品的問題，結合用戶行為監控的方式來制定設計策略以及流程優化方案可以有依據的的進行設計。

從而驗證設計的價值，獲得項目的話語權而不是隻是一個頁面做的很好看的“美工”。

本文由 @一隻雞腿 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部