如何度量 B 端产品的体验？
齐治设计 关注作者
2021-07-05
编辑导语：To B 产品与 To C 产品的服务对象、业务内容都有所差异，那么，B 端产品可以如何进行更合理的产品架构方案设计？其中，用户 B 端产品体验是一个重要的衡量依据。本篇文章里，作者总结、梳理了寻找适合 B 端产品体验度量模型的方法策略，一起来看一下。
一、写在前面
1. 什么是体验？
体验是一个比较抽象的概念，很多时候只是用户对产品的主观感受。但它又切实影响到了产品在用户 / 客户心中的评价，“好不好用” 的产品玄学问题拆解出来应该是涉及内容广泛、影响范围不一的诸多用户体验问题。
强烈的用户主观导向性，是影响 C 端产品业务展开的重要因素，故针对 C 端用户体验的度量模型早有发展。而随着近几年国内互联网的 toB 产业发展到非常火热的阶段，B 端体验 C 端化的要求也逐渐显露，尤其是用户体验的度量上。原本不甚受 B 端产品重视的用户体验越来越成为其竞争力的一大考量因素。
但由于业务特征的差异，C 端产品较为成熟的体验度量方案很难直接搬用于 B 端产品，「寻找适合 B 端产品的体验度量方案」自然成了当下热点的设计话题。
2. B 端产品的体验度量现况如何？
B 端产品具有链路冗长、操作复杂等特点。毋庸置疑，好的体验设计有助于优化这些特点可能带来的体验雷点，降低用户上手门槛。
那么如何验证设计的好坏呢？体验度量或许是一个不错的回答。「如何具体展开」就成了我们接下来要展开的问题，首先来分析一下目前面临的部分现况问题。
以齐治（外部）产品为例，作为技术导向的业务平台类工具：
- 行业客户对信息安全的保密级诉求使得设计人员很难获取到用户行为数据，无法运用一些客观法的经典模型和指标；
- 主观法的 NPS 度量侧重综合评价，用户体验在产品价格、安全性、稳定性等诸多变量中无法剥离；而满意度、尖叫度等度量方式在设计之初就更偏向于 C 端产品的评价，各项指标与齐治产品的 B 端特性相差太远；
- 技术类产品的用户在体验感知上并不强烈，导致很多主观法模型的数据价值存在局限，没有合适的度量方法指导，不确定的用户体验就无法转化为确定的量化数值。
所以，我们迫切想要寻找一个适用于 B 端产品、适用于齐治产品的度量方案。
二、现有体验度量方案
寻找合适自身的体验度量方案之前，我们应对现有方案进行清晰、全面的认知。首先试着从主客观的本质属性出发，对体验度量做一个简单的分类盘点。
可以发现，为了更全面地量化用户体验，各大厂商目前正在使用的度量模型大多兼顾主客观数据，下面让我们详细地了解一些优秀的模型方案。
1. Google｜HEART + GSM 模型
HEART 模型主要包括五个维度：愉悦度、参与度、接受度、留存率与任务完成度。
为了将这个抽象的度量标准应用于实践，Google 又提出以 “目标（Goal）——信号（Signal）——指标（Metirc）” 的拆解流程来定义 HEART 数据。通过 GSM 的具象化规范处理，HEART 模型得以灵活作用于整个产品或某个功能的体验度量，实现对关键目标的价值衡量。以量化数据驱动产品的设计决策，Google 的 HEART+GSM 模型为后人都提供了一个绝佳的参考答案。
不过，答案仅供参考，老话说得一点没错。HEART 模型的 C 端倾向较明显，并不完全适用于 B 端产品的体验度量。
2. 支付宝｜PTECH 模型
PTECH 模型是基于 HEART 模型构建的体验度量模型。具体做法是将愉悦度改为满意度，将任务完成度扩展为任务体验，在参与度下并入接受度、弱化留存率，引入清晰度与性能体验的全新维度。
PTECH 针对 B 端产品的业务特性作出优化，旨在用户行为分析和应用性能检测并重。不过性能体验维度的指标要求，意味着对度量对象展开实时监控的成本不低，普适性会有所降低。
3. 阿里云｜UES 模型 + 易用性量表
UES（User Experiences System）是基于阿里云易用性量表扩展而成的度量体系，包含易用性、一致性、满意度、任务效率和页面性能 5 个指标维度。
其中易用性是 B 端产品的重要属性，他的背后就是易用性量表的标准。
除了确定模型指标，UES 还进一步完善了基于 UES 模型的数字化管理体系。通过深入思考体验度量的规范化工作流程，以理论化的度量模型支撑，UES 自研了工具化的度量产品，形成了系统化的管理机制。
如你所见，UES 确实是比较科学全面、适合技术类 B 端产品的体验度量体系。但其庞大的体系、复杂的度量手段和工具可能都会使得我们在日常业务中无法轻量化地实施起来。
4. 58 同城｜B-Metric 模型
B-Metric 是一个关注业务特点与用户角色的度量模型。从度量目的出发，总结出 B 端产品最关注的问题是系统的质量与安全、核心任务流的使用体验以及企业效率效能的增益。由此确定了基础体验、角色体验、企业价值这三大度量指标。
同时，考虑到不同类型、不同生命周期的产品，度量指标的偏重会有所差异，以及，不同的用户角色，体验频率和深度等也会有很大不同，所以 B-Metric 还引入指标权重和角色权重的概念；具体表现如下：
- 根据产品特征，对基础体验和角色体验的各个指标赋予不同的权重；
- 根据角色特征，对各个角色赋予不同的权重。
总的来说，B-Metric 属于较为综合的 B 端产品评价模型，体验度量被解读出更多的价值内容，产品、设计、研发和市场都可以从度量结果中找到其关注的信息。
不过模型目前还处于初级阶段，指标的合理性缺乏验证。
5. 酷家乐｜四象模型
四象模型是面向工具类产品的体验度量方案。
首先，拆解出生产力的关联要素是人与工具，由「人」得出度量维度「角色」与「心智」，由「工具」得出度量维度「功能」与「性能」。这便支撑起来四象模型的前置理论。以这四个维度作为产品体验的思考方向，接下来的工作是寻找可衡量的目标。
最后，借鉴 GSM 的思维方式，四象模型进一步将 “高适用、易学性、高效率、强稳定” 的体验目标转化为具有实际指导价值的方法论，明确各目标下的体验原则、体验细则以及可衡量指标。“前置理论的寻找 → 四象雏形的设计 → 体系化模型的建设”，酷家乐这种「构建强针对性产品的度量模型」的方法流程可以带给我们不少启发。
6. 其他
除了上述的五个模型，还有 1688 针对 C 端产品的五度模型、腾讯针对聊天软件的满意度评估模型、网易用于指导设计产出、检验设计成果的 GUCDR 模型等等，都是业内现有的非常优秀的体验度量模型，不过他们对于本文讨论的 B 端产品体验度量可参考价值不高，故在此不一一深入介绍了。
三、如何构建适合具体类 B 端产品的体验度量模型
最后，回到本文开始的话题：「寻找适合 B 端产品的体验度量方案」。
现有方案的低匹配度，使得构建新模型成了更优解。构建之前，通过对 B 端产品的类型细分，我们发现不同类型的产品差异较大。如办公协同类产品与业务平台类工具的体验目标就很难进行统一化的抽象处理。
所以，「构建适合具体类 B 端产品的体验度量模型」显得更加对症下药。他山之石，可以攻玉。从诸多体验度量模型中取经总结，不难发现 “HEART + 业务特色” 的思考方向可以帮助我们构建适合具体 B 端产品体验的度量模型。
那么如何发掘自己的业务特色？不妨试着引入 GSM 模型。
确定目标时，以业务目标拆解设计目标，可以让设计价值和业务价值快速建立连接。所以我们先回答一个基本问题：基于某某产品的业务特色，影响体验好坏的关键因素是哪些？继续以齐治（外部）产品为例，从如下四个方面展开思考：
- 产品类型：企业级产品 (对内对外) 还是消费级产品？用户类型？用户量级？
- 业务功能：功能目的是什么？功能复杂度如何？任务效率如何？
- 用户诉求：用户角色？不同角色的心智认知、情感倾向如何？
- 性能体验：是否稳定？是否流畅？
如此不断的深入设问是为了寻找有价值的体验信号，再结合 HEART 等经典模型进一步确定具体类产品的度量维度。
当然，行之有效的体验度量模型需要体系化的建设，具体指标和度量方法的明确也是不可或缺的，这些让我们留作后谈。
本文由 @齐治设计 原创发布于人人都是产品经理，未经许可，禁止转载
若有收获，就点个赞吧
0 人点赞
