项目背景
1.产品体验问题日渐显露
在银泰商业中后台（MOS）中，长期以来一直缺少对于中后台产品体验的关注，对产品体验的态度就是“能用就行”（这也是业内B端产品的通病）。而随着MOS的不断发展，尤其是从2021年初开始正式开始了商业化征程，这些产品体验问题也被不断暴露出来。
有问题就需要解决它们，但是面对成百上千的体验问题，如果没有一个统一且客观的度量方案对问题进行描述和评估，我们就很难针对性地进行体验优化和产品升级，如同医生给病人治疗，一定先通过诊断然后才能给出精准的治疗方案。
这也如同业内通常说的：无度量，不优化；要优化，先度量。
2.现有度量方案不够精细
针对诸多体验问题，MOS内部已经着力于通过用户问卷调研的方式来完成满意度和NPS这两个维度的体验度量。当前也取得了一些阶段性的进展，尤其是在MOS全局的基础体验大盘和显性问题的归纳中。
但就两种方案本身来说，首先它们都是聚焦于MOS整体的宏观体验度量，而未能拆解到单一独立项目或核心链路中。
其次，它们都是偏向于用户的主观意愿的判断，是比较笼统且粗放的方案。而在影响中后台产品体验的诸多因素中，用户主观意愿的捕捉和度量只是其中的一部分。也就是说，现存的度量方案存在的问题比较明显：不够精细、不够精准。
如果想要解决以上两个问题，针对具体场景和核心项目的产品使用体验度量就尤为必要。
度量方法的差异性
1.体验的拆分
如果想要清晰地对体验进行度量，就需要先在内部对体验的构成达成一致：何谓体验，体验的构成要素有哪些？
目前业内主流的体验划分如下图所示，从商业化产品运作的视角，将产品体验拆分成四个大的要素：
而MOS的体验度量，则是聚焦于产品功能使用体验——这个要素决定了每个核心项目的直接体验感受，而商业交互、服务售后等体验要素则是更多地使用宏观的NPS和满意度进行度量。
这里可以举个不算很恰当的例子：假设现在有一个人（MOS某域产品）感觉不舒服，来到医院。中医会问病人是不是不舒服，哪里不舒服（此中医就是NPS和满意度），西医则会要求病人按照抽血化验、CT拍片等一整套标准化诊断流程走下来看哪里除了问题（此西医生就是产品体验度量Metric）。
2.差异性对比
体验度量体系
在中后台的业内目前已经有了一些比较成熟的体验度量方案，如蚂蚁的PTECH和阿里云的UES。这些经过验证的模型可以给MOS一些启发，但是依旧需要结合MOS当前最紧要的体验问题现状进行进一步的定制和优化。
我们在S1进行过样本量在3000+的用户问卷调研，发现影响MOS产品体验的三大主要问题在于：产品功能丰富度不够、操作不便捷、系统故障率较高。一方面我们需要将研发终点投入到这三个方面，另一方面在构建体验度量体系时，需要充分考虑到这些体验问题，来保证我们的付出有正负向的体验反馈。
与满意度等主观度量方案不同的是，产品体验度量因为落实到某个具体的终点项目或者任务链路，因此体验的量化、问题的诊断以及后续改进体验的Action等，是可以形成一个具体且可控的闭环的——这种具体到项目级的闭环则是一个完整的体验度量体系。
体验度量维度拆解
同时经过对业内现有的度量模型的调研，我们认为同样是聚焦中后台产品的阿里云UES会更适合当前的MOS，因此在上述的体验问题基础上，结合UES的度量模型，我们从系统表现、客观行为、主观感受三个大方面，推出了MOS体验度量的若干要素。
1.易用性（Ease of Use）
1.1.描述
易用性是中后台体验设计中最重要的原则之一，对于用户而言，易用性的提⾼可以提升用户的操作效率和任务完成率，降低用户对产品或功能的学习和上手成本，从而整体提升MOS产品体验满意度。为了更加清晰且更精确地度量易用性，我们这里针对易用性做进一步拆分，从正逆向难易程度、新旧客户上手难易度等维度得出三个关键性的子项：易操作性、易学性、易见性。
1.2.度量步骤
易用性度量在实践过程中，主要分为三个步骤：
- 核心任务测试：主要是为了观察用户在既定任务下的使用路径和状态；
- 产品体验访谈：在测试完成之后为了缓解紧张情绪，我们需要进行更加随和的访谈，引导用户说出体验槽点和潜在诉求；
- 易用性量化：针对事先准备好的12分量表（如下）让用户评分，实现易用性得分量化；
这里需要注意的是，易用性度量作为一个产品使用体验最直接也是最准确的度量手段，其很大程度上依赖于任务流的精确，因此在设定情景任务时务必需要尽可能地还原测试者的真实使用情境。
同时测试者的人数不需要太多，一般为3-5人就可以保证80%的可信度和有效性（数据来自阿里云科伯隆系数）
1.3.量化算法
收集测试者的易用性量表后，首先计算单个量表内12项的平均分得到
，然后平均计算所有测试者的分值，得到一个人均分值，即为该项目的易用性得分。
2.一致性（Consistency）
2.1.描述
一致性是体验设计中最基本的原则之一，对于银泰百货这类复杂且庞大的中后台产品体系而言尤甚。于用户侧体验一致性的提高可以降低用户降低学习成本与错误率，提升其满意度；于产品研发侧，保持体验一致性可以提升研发效能，保持较高的产品稳定性和提升集成度。为了更加清晰且更精确地度量一致性，我们对其做进一步拆分，共包含了三个关键性的子项：产品框架、通用组件、整体样式。
2.2.度量步骤
我们组建一致性质量小组，针对度量项目所涉及到的所有核心页面进行截图，然后针对出现的控件数量和样式进行分别计数，填入事先准备好的一致性核验表。
2.3.量化算法
在一致性核验表中，我们分别计算产品框架、通用组件、整体样式的一致性偏移率（不一致的个数/总数），然后根据三者在前台对用户造成的感知程度的大小来分别赋予30%、50%、20%的权重，最后进行加权平均即可得到该产品的一致性得分。
3.稳定性（Stability）
3.1.描述
系统表现从一定意义上来看更像是万丈高楼平地起的地基——当用户日常使用的时候很难对其有较强的感知，但只要出现问题那就是令人崩溃且无法挽回的。
业内对于评估系统表现的评估指标一般有两个：稳定程度、流畅程度。
在MOS体验度量中，我们多次思考后认为对于比较复杂的业务场景中，追求系统流畅度并不是很现实和客观——比如说同样是2500ms，对于复杂如商品域下的产品来说就是比较顺畅的体验，但是对于待办任务这样扁平的产品而言就比较卡顿了，正因如此，在MOS体验度量体系中，我们只采用了稳定性这一指标。
3.2.度量步骤
为了可以客观评估稳定性这一维度，我们使用了“系统报错影响用户占比”这个指标。通过对报错数据的抓取来反向推导稳定性数据。
起初我们使用“一共加载了M次，其中报错出现了N次，那么该产品不稳定程度为N/M*100%”的方案（基于PV）来描述，但是这里存在一个问题，那就是当一个产品出现报错时，用户可能会反复试错产生了多次无效的加载，这样就会影响稳定性的客观。
所以我们决定采用“产品出错影响用户占总用户的百分比”（基于UV）来描述稳定性。其中数据的采集来自集团AEM提供的数据埋点和自动核算能力（统计接口请求报错和JS加载报错）。
3.3.量化算法
分别统计JS报错和接口报错影响到的用户数(
)，以及系统用户总数
，利用其和单位1的差值即可得到系统的稳定程度。这里需要注意的是，依赖于AEM的报错分析能力升级，JS报错和接口报错影响用户占比可以自动算出，因此我们只需要将其求和即可得到不稳定率。
4.效用性（Efficiency）
4.1.描述
用户在使用中后台产品时，只有一个目的那就是完成某项具体的任务。因此任务完成的是否顺畅、是否便捷就会非常影响他的体感。
因此如何对效用性进行客观度量和评估就是一个非常重要的话题，这里我们引入的任务完成率、任务完成耗时两个维度，同时我们认为在考虑到一个产品面向用户时不论是新手还是老用户，其一般都是服从正态分布的——也即大部分用户都会聚集在最中间的位置，如下图所示（仅作为正态分布的示例）
4.2.度量步骤
为了能够系统性采集到产品核心链路中的完成率和耗时，在这里我们引入AEM的自定义链路能力，只需要将产品的起点地址输入AEM，然后在新开页面完成任务流即可在AEM中形成完整的链路和各节点的转化、访问数据以及节点跳转的耗时，并且对于任务耗时这类大样本的数据采用了更客观的中位数。
4.3.度量算法
在这里我们引入了符合正态分布的算法，将任务完成率计为
，任务耗时计为
，同时取ln函数：
5.满意度（Satisfaction）
5.1.描述
这里的满意度指的是聚焦于某个项目下，某次任务下触发的满意度调研。我们会定期关心用户在使用产品时（后）的真实感受——这也是和比较宏观的MOS系统满意度调研有差异的地方。
5.2.度量步骤
在过去我们可以通过Uone满意度问卷针对一些样本用户定向投放，虽然比较简单但是一定程度上牺牲了样本的普适性。
现在，得益于集团AEM的评分插件，我们可以通过设置满意度问卷的触发条件和疲劳度控制，无差别地投放给更大的样本用户。在投放一定周期后（一般为7天），AEM平台也会自动进行数据的回收。
5.3.量化算法
满意度的算法有PSAT和CSAT两种：
PSAT=（5分样本数-(1分样本数+2分样本数))/总样本数 * 100 + 100
CSAT= (5分样本数+4分样本数）/ 总样本数 * 100%
而在MOS体验度量体系中，我们采用的是CSAT，并将其划归为10分制：
从上述算法也可以看出，PSAT带有一种类NPS的理念在里面，也即需要减去打了低分（不满意和非常不满意）的占比，以得到一个“纯粹”的满意度。所以同样的数据，PSAT会比CSAT更低，但是对于所有项目只要采用同种量化方案，那么两种满意度算法都可行的。
MOS体验度量模型
为了能够将上述度量体验的5个维度贯穿，形成有机的整体，同时也是为了更加简洁且直观地看出产品体验中的长处和短板，我们也试图建立一个独立的体验度量模型来对其进行可视化描述。
1.产品分级
但是由于当前MOS全域产品都有所不同，对于诸如要快速上线所以牺牲了体验的少用户短链路类产品而言，完整的体验度量实践成本较高且并无此必要，而且体验度量的量化并非完全是为了一个数值，因此在这里我们初步地将MOS各类产品进行产品分级：S级、A级、B级。根据这三类产品进行不同程度的体验度量落地。
以下为暂定分级方案，后续将会根据MOS各产品现状和未来规划进行更客观的划分
2.体验可视化
对于S级的产品，设计师从需求待确定之初就已经参与其中，到后来的满意度接入再到最后上线后体验监控和数据回收，需要有足够完整的链路支撑。此类产品比较典型的，主要是面向导购员、中台招商以及HR域部分全员支持性产品，则需要使用五边形的体验度量模型来进行可视化描述。
而对于另一类产品，本身面向的用户群可能只有20人左右，或者任务流比较简单，比如小蜜的B端对话产品、储值卡售卡单向链路等，对于此类产品，使用三边形的体验可视化进行描述。
度量实践开展
1.标准化流程
体验度量对于存量的产品和增量产品都是适用的。
对于新上线产品也即增量产品，在需求确定阶段设计就会宣讲体验度量并将其落实到prd中，而易用性和一致性度量会在上线前的内测环节进行实践量化，效用性、稳定性等则需要等到产品上线并运行一个周期后（一般是30天）进行数据回收。
对于已上线的存量产品，我们会直接拉取现在已有的数据进行体验量化，并且诊断出具体问题进而生成完整的体验报告告知相关人员，在下次改版时融入需求prd中，从而形成一次闭环。
2.接入时机
如上所述，体验度量在新产品上线前，相当于起到了一次体验质检作用，因此在需求确定阶段就可以接入。
而对于旧产品在其改版前，体验度量的作用相当于对其进行系统化的体验诊断，同时保证相关人员对当前体验问题形成一个共识，继而在改版需求中将体验问题真正纳入实践和优化之中。
只要完成上述4个tips，其他的数据回收和采集包括最终的量化方案，以及体验度量的报告，都不需要需求方同学做，我们就可以提供一份系统且完整的体验度量报告，帮助其发现体验问题和提出体验优化方案。可谓是一劳永逸，投籽赢瓜。
我们的希冀
体验度量算是今年中后台产品或者B端行业最重要也是最新的体验发展趋势，从整体看各类产品都处于摸索和发掘的阶段尚未形成定论，此次MOS体验度量进行从0到1的建立，也是迎合趋势同时也是基于MOS体验现状出发的考虑。
短期内，希望通过可视化的产品使用体验度量和系统化度量方案，让体验的管理变得低成本、高效率、可控，能够在现在这个阶段引起相关业务、产品乃至更多人对中后台体验的重视。
其次，对产品使用体验的度量至少可以在产品和设计侧形成一种共识，对产品的每一次完善和升级都可以做到工具和方法可以把控。
而在更长远的未来，我们希望能够形成真正客观且合理的体验度量方案，帮助MOS所有的产品能够实现体验的数字化管理。
