如何去评判或衡量一个B端产品的架构方案设计是否合理？或许我们可以寻找适合B端产品的体验度量方案，并将B端产品使用体验作为评判依据之一。那么，常见的B端云产品常用的体验度量模型有哪些？来看看本文的总结分析。
B 端产品使用体验是衡量 B 端产品架构方案设计是否合理、产品是否好用的一个重要依据，也是提升产品竞争优势的重要因素。且 B 端产品具有链路冗长、操作复杂等特点，好的体验设计有助于降低用户上手门槛，提升用户体验。因此，度量 B 端产品的使用体验尤为重要。
但由于业务特征的差异，C 端产品较为成熟的体验度量方案很难直接搬用于 B 端产品，「寻找适合 B 端产品的体验度量方案」成为一个难点。
基于上述背景，本篇文章将介绍一些B 端云产品常用的体验度量模型，希望能为大家提供实践参考。
行业中现有的 B 端产品体验度量方案有哪些呢？以指标数据的主客观属性为依据，可将体验度量方案划分为客观度量、主观度量和兼顾主客观度量三大类型。
客观度量主要是通过数据埋点监测用户行为数据，典型模型/指标如 PULSE 模型、活跃用户数、留存率、ARPU、LTV 等；
主观度量主要是收集用户对产品的主观评分，典型模型/指标包括 NPS、费力度、客户满意度指数、KANO 满意度模型等；
主客观兼顾度量则是结合用户行为数据和主观打分得到分值，并把分值划分成不同等级作为参考，典型模型包括 UES 模型、HEART 模型、GSM 模型、PTECH 模型等等。
图| 现有体验度量模型概览
从该分类可看出，互联网大厂目前使用的度量模型大多兼顾主客观数据，能够更全面地量化产品的使用体验。因此，本篇文章介绍的体验度量模型将聚焦于该类型，主要侧重于UES 模型的介绍，同时会简单地介绍下谷歌的HEART、GSM 模型和蚂蚁金服的 PTECH 模型。
UES（User Experience System）是阿里云设计中心通过多年设计实践沉淀下来的云产品使用体验度量系统，它不仅是一套方法论，更是一套可运行的体系，由三大部分有机构成：
一是包含五大维度的 UES 体验度量模型；
二是包含易用性测试工具和数字化管理平台的体验工具集；
三是体验问题从发现到闭环的体验管理机制。
由此可见，除了确定模型指标，UES 还进一步完善了基于 UES 模型的数字化管理体系，包括工具化的度量产品、系统化的管理机制（本篇文章主要介绍的是理论化层面的 UES 体验度量模型）。
图| UES 构成
度量产品体验的指标有很多，但整体可分为三大类，分别是主观态度、客观行为和系统表现，如下图所示，从下至上，主观性会越来越强。
图| 体验指标类型
UES 模型为综合运用主观和客观、定性和定量分析的度量体系，包含易用性、一致性、满意度、任务效率和性能5个度量维度，适用于技术类B端（云）产品的体验度量场景。
图| UES 模型五大度量维度
首先，衡量主观态度的维度有三个：易用性、一致性和满意度。
其次，衡量客观行为的维度为任务效率。任务效率反映用户使用产品完成任务的准确性、完备性及相应的资源消耗程度。针对有明确任务或有固定使用流程的产品，通过比对用户路径和产品设计的理想路径之间的差异，能够帮助我们发现产品流程设计上的问题。
最后，衡量系统表现的维度为性能。性能反映用户使用产品的流畅性和稳定性，影响用户感知。
从整体上看，这些指标间并非相互独立，而是相互影响、相互促进。比如说，易用性的提升可以促进任务效率的提升，降低学习成本，提升用户对产品的满意度；一致性的提高可以降低用户的操作时长及错误率，进而提升任务效率和用户的满意度。而任务效率和性能的提升也能正向影响满意度。
在五大度量维度的基础上，UES 模型的每个维度均细分了相应的二级指标，且运用了多种度量方法、度量工具来度量指标，整体框架如下：
图| UES 模型框架
易用性包含易操作性、易学性、易见性/清晰性三个子维度，主要通过易用性测试、启发式评估等方法来度量。
一致性包含整体样式一致性、通用框架一致性、常用场景组件一致性等三个子维度，主要通过启发式评估来度量。
满意度的度量方法主要有用户访谈、问卷调研，采用的度量工具为可用性度量表、满意度问卷。
任务效率包含功能使用率、任务完成率、任务完成时间、任务完成效率等子维度，需要通过用户行为数据采集的数据监控方法来度量。
性能包含首屏渲染时间、页面请求响应时间、API 请求响应时间、页面请求成功率等维度，需要通过应用实时监控服务的性能监控方法来度量。
对于每一个细分指标的定义，下表给出了相应的解释。但这些仅是比较普遍、通用的解释，在应用中，应根据实际情况进行调整。比如说，对于满意度的度量，SaaS 和 PaaS 产品考量的维度会有些许不同。衡量 SaaS 产品满意度时可能会考量产品的智能化程度，衡量 PaaS 产品满意度时可能还会考量产品的开发效率、开放能力等。
图| UES 模型指标定义
首先是易用性度量，UES 模型的易用性度量运作机制如下图。度量方法主要分为面向专家的启发式评估和面向真实用户的易用性测试。这个过程中，需要由易用性专业建设组和业务线设计师、产品团队共同参与。整体可分为三步走：
一是统一易用性度量的标准、行动指南，以指导易用性度量的全流程；
二是输出专业的易用性度量报告；
三是通过系统化监控和专项改进进行闭环管理。
图| 易用性度量运作机制
下表是启发式评估和易用性测试过程中会运用到的易用性度量量表工具，主要是让专家和用户反馈使用这款产品的真实感受，对易用性的每个细分指标：易操作性、易学性、易见性的表现进行评分。
表｜易用性度量表
接着是一致性度量，一致性的常用度量方法为专家评估法，其具体实施步骤如下：
第一步是组织评测人员：招募3~5人组成专家组。需注意的是，被评测产品的设计师需回避；
第二步是制定评测计划：划定评估的范围，建议一次性评估的功能不要太多；
第三步则是实施具体评测：在评估过程中，各位专家需独立完成，避免讨论沟通；
第四步为召开评测会议：让评估人员依次讲述评估发现并进行互动讨论；
最后是总结评价结果：将所有评估结果进行去重和收敛，输出结论建议。
图| 专家评估法实施步骤
在运用专家评估法度量一致性的过程中，所运用的度量工具表为一致性度量量表，主要是让专家对产品整体样式、通用框架、常用场景及组件的细分指标的一致性表现进行评分。
表｜一致性度量表
然后是满意度度量。通用的满意度度量量表框架如下，主要是对产品功能的易学性、易操作性、费力度等进行评价，但实际应用过程中应根据所度量对象适当调整量表内容。
表｜满意度度量量表
任务效率为客观行为数据，需通过数据埋点与采集，进行用户行为分析得到相关原始数据，再根据指标定义公式计算相应的指标值。
性能度量指标为系统表现数据，可通过数据埋点或从系统后台拉取数据，借助性能监控系统实时监控性能指标。企业可结合实际业务场景自行搭建性能监控系统，也可应用市场上成熟的 APM 类监控产品，如阿里云的 ARMS( Application Real-Time Monitoring Service, 应用实时监控服务 )。
图 | ARMS 性能监控效果图
介绍完 UES 的指标体系及相应的度量方法及工具后，则到了最后一步：如何根据搭建好的指标体系及获取到的指标计算出产品或功能的体验得分呢？
整体的原理是：一级指标得分为其所包含的二级指标的加权平均值，而测评总分由一级指标得分加权平均得到。测评总分计算公式如下：
式中，S 为测评总分，ai为第 i 个一级指标的得分，Wi为第 i 个一级指标的权重，n 为一级指标的数量。
对于权重的确定，阿里对 UES 模型的权重设计为：易用性和一致性 0.3，任务效率和性能 0.1， 满意度 0.2。
但对于面向大企业的B端产品，该权重不一定适合照搬。那么如何根据实际的体验度量对象确定指标的权重呢？
表 | 指标权重计算方法
此处归纳了常见的指标权重计算方法，主要有三类：主观赋权法、客观赋权法和综合赋权法。
这里简单介绍下实操性比较高的层次分析法和优序图法。
首先是层次分析法，该方法常被运用于多目标、多准则、多要素、多层次的非结构化的复杂决策问题，特别是战略决策问题。
其优点在于系统化、简洁实用，且所需定量数据信息较少，但也存在缺点，比如说指标过多时，数据统计量大，且权重难以确定；特征值和特征向量的精确求法比较复杂。
该方法整体可分为三步：
一是基于问卷数据构造判断矩阵。具体而言，由专家对同一层次内 n 个指标的相对重要性（两两因素之间）进行打分，标度范围取 1-9 之间：
1 表示两个指标具有相同重要性，3 表示两个因素中，前者比后者稍重要，标度越高表示前者比后者的重要性程度越高。另外，若因素 i 与因素 j 的重要性之比为 aij，则因素 j 与因素 i 的重要性之比为 aij 的倒数。
根据相对重要性打分，即可构建判断矩阵 A 。
第二步则是基于判断矩阵计算权重，将矩阵 A 的各行向量进行几何平均（方根法），然后进行归一化，得到各评价指标权重和特征向量 W 。
最后一步为一致性检验。所谓一致性是指判断思维的逻辑一致性（如当甲比丙是强烈重要，而乙比丙是稍微重要时，显然甲一定比乙重要。这就是判断思维的逻辑一致性，否则判断就会有矛盾）。一致性检验是指确定不一致的允许范围。通过一致性检验的权重值才是合理的。
可能层次分析法的权重计算和一致性检验原理比较复杂，但在实际应用过程中，可以利用市面上成熟的层次分析法工具来实现，如元决策的 yaahp 软件，导入问卷数据，系统即可自动计算出相应的权重并进行一致性检验。
然后是优序图法，该方法非常适合在参与评估指标数量较多（如需评估的指标超过5个）的情况下使用。当指标数量较多时，优序法的专家打分工作量相对较小，且简单易实操。但该方法也存在一定的弊端，如未进行一致性检验或多轮验证，权重数据的严谨性相对较差。
该方法整体可分为三步：
一是重要性打分，由每位专家独立对问卷内各指标进行重要性打分，并计算出各指标所有专家打分的平均分。
二是指标重要性比较，通过各指标的平均分，将不同指标间的平均分进行两两比较，其中，分数相同的计为 0.5，相对较大的记为 1，相对较小的记为 0，并将各指标比较的每行分数相加，得到各指标的优序数（TTL）。
最后则是对 TTL 值进行归一化处理，得到指标的权重值。
表｜层次分析法和优序图法优缺点比较
HEART-GSM模型包括【5】+【3】两个部分：5个用户体验度量维度和3个确定数据指标的步骤。
首先，代表5个用户体验度量维度的 HEART 模型由 Google 于 2010 年发表，是以用户为中心的度量模型，涵盖了用户主客观数据以及可用性指标，可用于大范围的用户体验度量，五个维度分别为愉悦度、参与度、接受度、留存度和任务完成度。
图｜HEART 模型五大维度
为了将这个抽象的度量标准应用于实践，Google 又提出以“目标（Goal）——信号（Signal）——指标（Metric）”的拆解流程来定义 HEART 指标数据，让使用该模型的产品团队，可以根据用户体验目标和业务目标，完成数据指标的选择，最终保证指标是服务于业务目标和用户体验的。
这三个大步骤又可细分为五个小步骤，首先是梳理业务流程，分析确定产品目标或者体验目标，接着，结合度量维度的定义和目标选取与实际业务流程贴合的度量维度，然后是选择可以显示目标成功或失败的信号，最后是从信号中提取适当选择的数据指标，并选取相应的度量方法进行追踪。
图｜GSM 拆解流程
整体而言，HEART 模型的C 端倾向较明显，并不完全适用于 B 端产品的体验度量，比如说，由于 B 端产品的业务性质，用户使用产品后较难因为个人使用的体验而在参与度、留存度及任务完成度上体现出差异。
图 | HEART-GSM 模型优劣势
可能会有小伙伴对信号跟指标的区别不太清晰，这里说下我的理解：
在 GSM 模型中，目标、信号、指标之间是承接的关系。确定目标从而判断目标对应的信号，然后拆解为可量化的指标。信号是目标的分解，一个目标可以分解为多个信号（信号也可理解为目标对应的表现，目标的成功或者失败，如何作用在用户的行为之中，哪些行为、感受可以说明目标已经成功)。指标是信号的衡量标准，一个信号可以由多个指标来衡量。
举个例子：
以 HEART 度量模型为基础，蚂蚁金服根据企业级产品现状和特征做了部分的补充和修正，推出了适用于企业级产品的 PTECH 模型。PTECH 模型与 HEART 模型的主要区别在于：
图| PTECH 模型框架
PTECH 模型通过马斯洛需求金字塔理论推导出用户体验需要满足的5个层次，分别对应度量框架的五个维度，做到了定量与定性全覆盖。生理-安全-归属-尊重-自我实现五个层次分别对应：
图 | PTECH 模型优劣势
以上就是本次文章的全部内容啦，篇幅有些长，划个重点回顾下吧~
1）综合主客观指标的产品体验度量模型主要包括：UES 模型、HEART-GSM 模型、PTECH 模型。
2）UES 模型为综合运用主观和客观、定性和定量分析的度量体系，包含易用性、一致性、满意度、任务效率和性能5个度量维度，适用于技术类 B 端（云）产品的体验度量场景。
3）HEART-GSM 模型包括【5】+【3】两个部分：5 个用户体验度量维度——愉悦度、参与度、接受度、留存度和任务完成度、3 个确定数据指标的步骤——目标（Goal）——信号（Signal）——指标（Metric）。
4）PTECH 模型是基于 HEART 模型修订的，主要度量维度如下图：
本文由 @Problemer 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。