软件项目测试经验怎么写（产品的设计体验度量模型）

有很多同学，在产品的设计体验度量模型常常摸不着头脑，不知道该如何运用度量模型，或者运用哪一个度量模型。作者以度量模型的定义及其本质出发，探析如何使用度量模型，希望对你有所启发。

很多同学一提到“度量模型”这几个字就头大。我也收到过不少同学关于设计体验度量概念的问题，大多都是让我帮忙分析几个度量模型之间的优劣，想看看应该将哪一个模型用在自己的产品上。比如：

“可以对比分析下 SUS 和阿里云的 UES 度量模型吗？我所在的公司主要做的是 B 端系统，请问哪个更实用？”

“蚂蚁的 PTECH 模型和“两章一分”模型，后者是否更轻量级、更适合度量技术类的工具设计？”

对于这类问题，解释这些模型的具体用法，是治标不治本的。学知识要究其本质，我们就先看看以下这几个度量模型的本质性问题，如果你都读懂了，自然就会有上面这些问题的答案了。

一、体验度量模型是什么

体验度量模型也可以被叫做「产品体验评估模型」或「设计质量检测模型」等等。这类模型的使用对象通常是设计师或用户研究团队，其本质是一种产品设计及体验的质量的评估工具。一套体验度量模型的组成通常包括以下几个部分：

1. 度量维度

即对于要度量的内容的性质定义和分类，为的是让度量过程更具备逻辑、更全面。通常这些度量维度的英文首字母结合在一起，就是这个度量模型的名称。

比如蚂蚁集团平台设计部 2019年提出的用于评估企业级产品体验的度量模型 PTECH，其实是从产品的性能体验（Performance）、任务体验（Task success）、参与度（Engagement）、清晰度（Clarity）、满意度（Happiness）这五个维度来对产品的设计和体验质量做评估。这几个单词的首字母就组合成了「PTECH」这个模型名称：

2. 度量方法

包括需要度量和检测的具体内容、注意事项、操作策略和具体操作步骤、完成的指标等一系列内容。目的在于告诉设计师需要在不同的度量维度下收集哪些内容和信息，以及用什么策略和方法来做度量。

度量方法会从度量维度出发，针对每一个维度给出不同的策略和方法，并匹配对应的指标。比如我们上面说过的 PTECH 模型，除了划分度量维度，也对每个维度下关键的度量内容和度量手段做了规范和定义：

3. 评分机制

评分机制并不是必备项，可以被明确而简单的指标替代。但由于每项具体的度量内容对于产品体验的权重和影响不同，当设计师想要对于产品整体质量有一个精准的量化认知，就需要通过数字化公式进行计算。所以一些完整性较高的度量体系都是具备评分和转化机制的。

还是以 PTECH 模型为例，这个模型就引用了一套复杂的分数转换和核算方法，将五个维度测量出来的内容结果转化为数值，帮助设计师精确计算出产品的体验分值：

这种数字计算公式和方法并不是随随便便拍拍脑袋就可以想出来的，其中的逻辑和推演过程比较复杂，没有些许数学功底或是对度量模型不了解还真是不太行的。

不过也不得不说，这种高级的换算方式，不仅在确定公式的过程中增加了模型的复杂度，在使用公式计算出最终得分的过程也同样给设计师增加了不少工作负担。所以现在很多度量模型也会选择避重就轻，使用更加简单明了的指标来呈现度量结果。

比如谷歌公司的设计团队提出的 GSM 模型，就是将结果的评估重点放在对指标的定义上，用指标来判断设计质量的水平和标准：

看到这里你可能会有疑问：本就都是对于产品设计和体验的质量评估，为什么要有这么多不同的模型？大家就不能使用一套统一的标准模型么？

这是因为一款产品的评估方式本来就是多维度、多方面、多标准的，对不同业务领域的产品制定和使用统一的检验标准，是几乎不可能实现的理想情况。由于度量模型本身具备与产品强绑定的工具属性，所以「抛开产品自身特点和需求谈体验度量，就是耍流氓」。

蚂蚁的设计团队就应用过 PTECH 模型和「两章一分模型」等不同的度量方案。对于这种情况相信集团内部也曾经想努力地统一度量模型，尽量避免重复造车。但实际情况却是，这么多条业务线和产品类型，都各自有自己的想法和诉求。所以大家最终还是各自沉淀、百花齐放，也就有了不同的评估标准和模型工具。

值得一提的是，这种各自沉淀的过程并不是完全地重复造车，而是搭建思路和经验上的相互借鉴，取长补短，让每个团队都可以找到最适合自己业务的度量模型。

二、如何使用度量模型

判断一款度量模型好不好用，其实只有一个核心的判断原则：只有适合的，才是好用的。

同样的道理，当你想要对产品应用度量模型来做体验评估，也只有一个核心的使用原则：把度量模型当作工具去使用，而不是当作规则去迎合。

在实际工作中，工具和方法大多数情况下都是用来解决实际问题的，而它们的诞生也源于使用者对于这些问题的梳理和总结。你能看到的这些经典的度量模型，都是设计师们对于几十上百个项目千锤百炼后的经验沉淀，或多或少都会带有一些各自的业务特性和场景属性，因此没有绝对的高低优劣之分。

而能够完全适合你的产品特征、匹配你的度量需求的现成的度量模型是极少数的。这也是为什么你在借用这些模型的过程中，有时会有「不太好用」或「生拉硬套」的感觉。

因此，你可以根据你的产品特点和想要度量的内容，有目的性地、有选择性地、部分性地对这些业内已经成熟的度量模型进行借鉴和应用。当然在你的时间和精力允许的条件下，我也鼓励你参考这些经典案例，打磨出针对你自己产品的定制化度量模型。

所以你要做的，不是一板一眼地套用某个模型，而是发挥主观能动性，去判断、去筛选出真正对你的产品有用的部分，以及去学习这些模型搭建时的思考方式和工作经验。

度量模型就再高大上、评分标准再数理化，究其根本它也只是一款评估工具。对于这款工具的应用，不要为了彰显设计师的「工作量」或「学术专业性」而应用，也不要被这个工具限制住思考的能力。我们的核心目标是用它来发现产品的问题并找到有效的解决方案。

说了这么多，再来看看开篇的问题：SUS 和 UES 度量模型哪个更实用？你应该知道答案了吧？

专栏作家

元尧，长弓小子，人人都是产品经理专栏作家。一线互联网大厂B端体验设计师，清华大学美术学院本硕连读。曾负责国内最大开源组件库Ant Design组件的设计和运营工作，目前负责国际业务线B端产品体验设计和组件库的搭建工作。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。

该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。

,