一、前言
作为一个B端产品的产品经理，我们会面临很多问题：复杂的产品需求、纠缠的技术逻辑、难以决策的设计方案、难以计量的产品迭代效果。而对于作为支撑平台的B端产品经理而言，提高效率和体验又常常作为评估价值的主要方向，故因此我们需要一套科学的体验度量体系来指导我们前进的方向：产品目标的确立、需求价值的评估、迭代效果的量化。
那么何为产品的使用体验：即用户在产品使用场景中完成期望目标时所产生的体验。这是用户和产品直接接触的部分，也是最有感知的部分。无度量，无管理，我们如何管理体验？现代管理学之父，彼得·德鲁克说：「如果你不能很好地度量它，也就无法有效地管理它。」If you can’t measure it, you can’t manage it。Druker
但是B端产品相对C端产品而言产品体验更加难以度量，因为C端产品有明确的业务数据指标作为向导，但是B端产品由于功能流程冗长、业务交叉复杂、包含产品价格、安全性、稳定性等综合因素，用户体验的要素被掩盖在这些复杂的「变量」中难以剥离。而控制和分离变量，是一个科学的度量系统最基本的要求，故做了如下调研，方便大家参考借鉴！
二、谷歌HEART-GSM模型
1、简介
Kerry Rodden 作为谷歌资深用户体验研究员和数据分析师，在大量度量用户体验的探索与实践中总结出了HEART用户体验度量模型，帮助团队高效选择正确的数据指标。该模型在谷歌内部广泛使用，并通过论文、博客等渠道传播，使其他公司、团队也能够在使用的过程中受益。
2、HEART模型五个维度：
HEART模型主要包括五个维度：愉悦度、参与度、接受度、留存率与任务完成度
3、GSM-目标、信号、指标拆解三 步法
为了将这个抽象的度量标准应用于实践，Google又提出以“目标（Goal）——信号（Signal）——指标（Metirc）”的拆解流程来定义HEART指标数据。让使用该模型的产品团队，可以根据用户体验目标和业务目标，完成数据指标的选择，最终保证指标是服务于业务目标和用户体验的。
4、操作指南
5、优劣势分析
6、总结
HEART模型的C端倾向较明显，并不完全适用于B端产品的体验度量（需要在此基础上改良）。
三、阿里云UES模型
1、简介
UES（User Experience System）是阿里云设计中心通过多年设计实践中沉淀下来的云产品使用体验度量系统，它不仅是一套方法论，更是一套可运行的体系。
2、五大度量维度（有主观，有客观，有定性，有定量）
UES（User Experiences System）是基于阿里云易用性量表扩展而成的度量体系，包含易用性、一致性、满意度、任务效率和页面性能 5 个指标维度。
易用性 - Ease of use
易⽤性是产品使用质量的核心维度，它反应产品对⽤户而言是否易于学习和使用，包含易学性、易操作性和清晰性3个维度。易⽤性的提升可以促进操作效率和任务完成率的提升、降低学习成本、提升⽤户体验和满意度。
一致性 - Consistency
一致性指多款产品间通用范式部分的一致程度，分为整体样式、通用框架和常用场景及组件等维度。对于⽤户⽽⾔，体验⼀致性的提⾼可以降低⽤户的操作时⻓及错误率，降低学习成本，提升⽤户的满意度；对于产品设计及开发者⽽⾔，保持体验⼀致性可以提升开发效能，产品模块的可集成性、稳定性和可延续性更⾼。
满意度 - Happiness
满意度反映着用户对产品或服务的期望被满足的程度，这个指标一定程度上会反映用户再次使用和对产品进行推荐的程度。
任务效率 - Task Success
任务效率包含任务完成率和任务完成时间，云产品的任务链路相对复杂，针对有明确任务或有固定使用流程的产品，通过比对用户路径和产品设计的理想路径之间的差异，能够帮助我们发现产品流程设计上的问题。
性能 - Performance
监控性能的指标有很多，其中最影响用户感知的指标是首屏渲染时间（FMP），指用户从发出请求到看到控制台主要内容的时间。其次，还包括页面请求响应时间、API 请求响应时间等指标。
3、指标拆解方法
①、明确业务目标和体验目标
②、确定度量维度
③、拆解数据指标
④、完善度量方法
4、优劣势分析
优势：度量维度多、全面、包含主观、客观、有定性，有定量
劣势：实施成本高、开发成本高、分析成本高
5、总结
UES确实是比较科学全面、适合技术类B端产品的体验度量体系。但其庞大的体系、复杂的度量手段和工具可能都会使得我们在日常业务中无法轻量化地实施起来。
四、蚂蚁金服TECH 模型
1、度量模型诞生背景
企业级产品 / 企业级中后台这些概念在互联网经常被提到，一般提及这个词儿，我们往往能够想到以下这些产品：财务审批系统、CRM、ERP、算法专业人员训练模型的平台等等。在我们的印象中，这些平台往往具有以下特征：
流程冗长，操作繁杂，一个平台往往是若干复杂功能的合集；
相对于 C 端产品动辄百、千万级别的用户量，企业级产品往往用户量级不大；
开发流程简单，往往是产品经理画个 demo 就上线了；
页面设计难看，用户体验往往比较糟糕；
......
现阶段企业级产品也在慢慢演变，对于体验的追求也比前几年更为饥渴。他们的体验需求可以明显看到两个阶段的演进：
效能需求阶段：这个阶段的企业级中后台页面设计混乱，业务对于体验的需求显性表现在美化页面设计，提高设计效率和一致性。
体验需求阶段：这个阶段产品开始关注使用过程中的问题，慢慢转向注重于用户需求和体验设计。
就蚂蚁金服的企业级产品来讲，Ant Design 已经帮助解决了绝大多数第一阶段的需求。目前基本都处于第二阶段。体验度量实践也正是从这里开始。
2、实践过程
以HEART度量模型为基础，蚂蚁金服根据企业级产品现状和特征做了部分的补充和修正，修改点如下：
将 NPS 改成用户主观满意度：NPS 对 C 类产品是一个很有效的指标，对于企业级中后台来说，往往由于企业产品的封闭内环、用户基数等众多原因，可能还是满意度来的更加有效；
不强调留存率：企业级产品用户往往没有太多的可选余地，因此留存率未必适合用来衡量用户对于产品的喜好；
参与度和接受度指标合并：对于企业级中后台系统，用户使用的目标性更强，TA 就是来完成某个任务（或者说 TA 就是来完成工作的）因此活跃度基本和产品能否满足用户的需求强相关；
3、最终体验度量模型
基于 HEART 模型，结合企业级产品体验度量实践修正后的度量体系如下：
核心任务体验（Task Success）：主要聚焦于产品核心任务流程中的体验问题。可以采用定性、定量，或者两者结合的方式，最终来反映体验的细节问题。
参与度（Engagement）：产品能够提供的需求和用户预想之间距离有多远？
清晰度（Clarity）：引导、帮助清晰，用户是否能够顺利完成所想做的事情？
满意度（Happiness）：用户对产品及其他方面的满意度，比如视觉外观等。
4、优劣势分析
优势：多维度、多指标、主客观结合
劣势：客观的用户行为数据指标较少
五、总结
那么如何去搭建符合自身平台业务的体验度量体系呢？我们发现不同类型的产品差异较大。如办公协同类产品与业务平台类工具的体验目标就很难进行统一化的抽象处理。所以，「构建适合具体类B端产品的体验度量模型」显得更加对症下药。他山之石，可以攻玉。从诸多体验度量模型中取经总结（各大其他平台的度量模型都是基于HEART模型改良的），不难发现“先梳理产品目标+参考HEART+阿里云指标拆解方法”的思考方向可以帮助我们构建适合具体B端产品体验的度量模型。
网友评论