编辑导语：在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端场景中内部用户还会考虑到其他的主观因素：

1. 合作关系：双方合作时候，如果是一个人评价自己的同事或者是搭档的情境下，会思考到给与差评思考的顾虑，这里面也有可能是主观给与对方差评的可能行。比如：经典的不要让一个产品经理评价程序员。
2. 中庸倾向：中国文化里面的中庸之道渊源流传，影响到了大部分人，尤其是在可能有利益相关人员的打分的时候就会有主观因素的影响。

会导致调研测量不准，而会对后面产品设计给与错误的引导。

二、 NPS

NPS（净推荐值）：主要场景是观测是否有良好的口碑或者用户流失的风险。

通常的评分机制是0到10分，主要分为三个类别：

1. 0-6分 ： 贬低者
2. 6-8分：被动者
3. 8-10分：推荐者

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

这里的计算完全可能出现负数，所以提前一定要有心理预期（之前真的出现了负数，然后组里有人emo了）。找到问题解决问题就好，千万不要emo。

三、 SUS评分量表

可行性测试：让用户使用原型或产品来发现实际页面中的可用性问题,属于典型的定性研究。

1. 使用场景

主要集中在两个场景：

1. 上线前测试DEMO
2. 上线后进行测试，预测效果如何

2. 可用性测试流程

1）前期招募

通过客户成功推荐/系统内发信息等多种方式PUSH到用户，使得用户自愿加入到可行性测试当中。招募10名以上的用户，保证样本的多样性进行测试。

这里有个3小技巧如何进行招募：

1. 针对同事：很多客户成功怕麻烦到了用户之后会导致续约率下降，所以一般很难推荐。那我们跟客户成功沟通的时候，就主打的是如何提高续约率（这个办法跟怎么跟开发沟通时候相同，就告诉他“这个用户体验优化后您能帮助他进行升职加薪”那他大概率会帮你的）。
2. 针对用户：在PUSH信息中，直接挑明利益点（奖励）可以让客户更直接的做出自己的选择，如果他们想要奖励的话整个流程之中会更加的配合，效果会更好。
3. 说到做到：说好的奖励一定要能够实现，如果不能够实现的话一定要准备好如何去解释，要不然会失去用户的信任。

测试方法：整体的测试方法类似于剧本杀，不过是用在商业之中为的是实现商业目的。

发放任务卡，进行角色扮演，以一个实际任务流程串联起来，也可以是以工作坊（工位）完成一个游戏，并且给与奖品。

测试卡片一般分为4个部分：

1. 场景描述：主要是描述职位信息，以及要做的任务是什么，有什么流程先给予用户的预期；
2. 测试任务：测试人员引导被测试人员完成的测试任务；
3. 完成情况：这里是测试人员根据测试情况进行如实的记录（一般情况下还要记录以及询问为什么，后期可以作为设计的依据）；
4. 主观报告：用户根据主观进行判断满意度如何。

2）评分标准

主观报告通常情境下都是5分制，1分到5分表示非常不统一到统一的强度。

3）计算方式

可行性测试的计算方式需要转化值的操作：

• 奇数项：得分-1
• 偶数项：5-得分

转化完之后，全部的值相加。总值乘以2.5得到sus总分。推荐值：B端行业平均得分是67.7分。如果低于这个分值的话，那得回溯看哪里除了问题。

四、 总结

以终为始，从业务目标与用户出发制定相关的okr。使用易用度测试和可行性测试来诊断现有产品的问题，结合用户行为监控的方式来制定设计策略以及流程优化方案可以有依据的的进行设计。

从而验证设计的价值，获得项目的话语权而不是只是一个页面做的很好看的“美工”。