UES体验度量模型

前言

User Experience System是阿里云设计中心通过多年设计实践中沉淀下来的云产品使用体验度量系统，它不仅是一套方法论，更是一套可运行的体系。

由三大部分有机构成：

• 一个包含五大维度的 UES 体验度量模型。
• 一个体验问题从发现到闭环的体验管理机制。
• 一个易用性测试和数字化管理的体验工具集。

发展历史

NPS阶段

我们如何管理体验？现代管理学之父，彼得·德鲁克说：「如果你不能很好地度量它，也就无法有效地管理它。」
If you can’t measure it, you can’t manage it。
Druker

现代商业社会本质上是建立在数字交换上的社会，生产、购买、售卖、投资、贸易，新的价值在劳动中产生，又被一次次计量和转换为新的形态。如果用户体验不能被度量，就注定难以融入到这个数字构成的生产和管理体系中。因此，我们做的第一件事情，便是寻找一个和用户体验关联的商业产品核心度量指标。

我们发掘的第一个指标，是 NPS：Net Promoter Score，净推荐值。
但这个过程并非一帆风顺，硬核的阿里云产品从来都是技术导向，对用户体验的感知度不像 C 端产品那么强烈，更难引起重视。我们决定先在小范围的产品进行切入。2016 年 10 月起，我们首先从云安全的产品入手，一步步去推进 NPS 度量，去建立体验心智。同时，在 NPS 的问卷中，我们加入更细致的满意度问卷，让用户更好地反馈，对体验问题进行深入洞察。
设计中心的持续推动，让 NPS 开始被产品的管理者所认可和重视。那些不确定的用户体验，开始转化为确定的净推荐值和大量的体验问题反馈，给产品改进带来实实在在的指引，进而又让产品更加重视对用户体验的管理。体验和产品的故事，从此走向了一个良好的正循环。而过去一年，NPS 已经从一个设计发掘的体验数值，变成了大量云产品的核心指标，而从这些举足轻重的产品中，我们发现并改进上百个用户体验问题。

但对于设计师来说，度量用户体验的命题却远未得到解决。NPS 更多侧重在用户的综合评价上，包含产品价格、安全性、稳定性等综合因素，用户体验的要素被掩盖在这些复杂的「变量」中难以剥离。
而控制和分离变量，是一个科学的度量系统最基本的要求。于是，我们的设计师又开始了新一轮的研究和测试，以寻找一个更合适的用户体验度量方法，去回答一个最基本的问题：我的产品使用体验，好吗？

初步小试

要回答这个问题，首先要回答的是：什么因素会影响产品使用体验？
1989年，在技术接受模型( Technology Acceptance Model，TAM )中，Davis 指出了两个影响技术类产品使用的核心因素：“有用性（usefulness）”和“易用性（ease of use）”。“有用性”更多是产品能力本身层面的属性，关乎功能和商业，而“易用性”则是设计师能把握和发力的核心，因此，我们决定聚焦「易用性」，作为撬动中后台技术产品使用体验的杠杆。
那，如何度量易用性呢？
通过对计算机系统可用性问卷（computer system usability questionnaire，CSUQ）、用户界面满意度问卷（Questionnaire for User Interface Satisfaction，QUIS）、网站分析和测量问卷（WAMMI）、系统可用性量表（System usability scale，SUS）等 15 个经过广泛应用的体验度量方法进行分析和验证，并基于测试难度和置信区间进行综合评估，最终我们得出结论：并没有一个合适的易用性量表。

这些量表虽然久经考验，但它们都不是为互联网时代和云产品体系而生。以 SUS 量表为例，John Brooke 在 1986 年编制它的时候，乔布斯刚刚离开苹果创建 NeXT ，距离中国第一封电子邮件发出还有一年。它也并非为中文而设计，其中的第8题：「我发现这个系统使用起来非常笨拙(cumbersome)。」在实际测试时让用户十分困惑，因为在中文语境中，很少有人会用「笨拙」这个词去形容一个软件系统，但你又很难找到一个更合适的词汇去覆盖它的本意。
因此，与其墨守成规地去套用一个过时的量表，我们决定去粕取精，去设计一个适合我们自己的量表。在15个易用性问卷中，我们抽取合并出30个典型问题，并走访客户和用户研究专家，让他们选择这30个问题中最关心和认为最重要的问题，以此确定一个12题版的标准问卷，以及6题版的核心问卷。我们把这套度量表，命名为：

易用性度量量表
Product ease of use metric, PEM
我们对收集到的样本数据进行了一次信度分析，在最常用也是最准确的科隆巴赫 α 系数分析中，我们的评分甚至优于 SUS 等传统量表的信度。而更关键的是，有了高置信度的量表，我们不再需要成百上千的测试数，而是达到十几个样本即可。这对许多需要用户基数比较少和测试难度高的技术产品无疑至关重要。
整体量表值得信赖还不够，我们又进一步进行了探索性因素分析，以验证我们的问卷是否能有效地将 12 个变量综合为 3 个核心因子，它们分别是：
易操作性：反映产品是否易操作，与用户的操作效率和任务完成率密切相关。
易学性：反映产品是否易于学习，衡量其学习成本与上手难度。
易见性（清晰性）：反映产品的感知清晰性，关乎其信息展示、结构布局和功能入口等方面。

而通过 KMO 和 Bartlett 的检验，发现易用性量表非常适合进行因子分析，结果具有显著性，且量表 3 个维度项目的因子载荷系数符合易用性预设的专业维度，综合说明易用性量表具有较高效度水平。
如果以上统计分析过于拗口的话，用人话说就是：
「易用性度量量表，你值得信赖。」

验证了置信度后，我们立刻想到，那易用性 PEM 评分，和 NPS 是否有关联呢？
而对样本数据的统计分析后，易用性和 NPS 被认为是：强正相关。

这意味着，产品易用性和产品净推荐值中存在着一道隐形的桥梁，在理论上，我们能间接验证体验的商业价值。易用性的理论体系建立完成后，很快，我们撰写了一份易用性度量的规范指南，包含「任务制定-用户招募-易用性测试评分-统计分析-度量报告-问题解决」的整个测试闭环流程，以帮助易用性测试的标准化执行。

但更重要的是机制。我们成立了易用性小组，组织产品易用性测试专场，以保障测试工作的有序开展。在这个过程中，业务方真切地观察到用户的行为，听到了用户的声音，也了解了产品体验的重要性和体验度量的专业方法。这时的易用性度量就不再仅是一场专业的研究行为，也是一次潜移默化间，不同团队和角色互相理解和信任的关系建构。

小试成功

有了易用性测试的成功为基础，我们便有了更多的信心，去探索更全面的云产品体验度量系统。而这，就是回到了我们前面说的，阿里云产品使用体验度量系统：UES（User Experience System）。
易用性描述了产品体验的一个重要维度，但不是唯一。交互和视觉设计是否一致、页面渲染和API调用是否快捷，这些或主观或客观的因素都会综合影响用户体验。
和易用性的思路一样，我们也不机械套用已有的模型。适合网站的 PLUSE、谷歌的 HEART、蚂蚁的 TECHP，它们各有切入点，也各有其适应场景。方法虽无法穷尽，思维却可以归纳。我们发现，无论模型怎么变化，表达产品体验的重要度量指标，总逃不开这三个范围：用户态度、用户行为、系统表现。
于是我们根据 B 类技术产品特性，在多个维度中评估和挑选，重新思考定制，设计了 UES 模型

其中，NPS 问卷中的满意度反映产品的整体主观体验；一致性提供以规范为纲的设计一致性走查和客观计量方法；性能关注产品的体验技术指标；任务通过 UBA 工具度量核心任务的成功率；易用性则得出产品体验最核心的主观指标，并输出具体体验问题清单，指导产品改进。
这五个维度有主观，有客观，有定性，有定量，我们用不同的测试方法和工具适应不同的测试指标，以期实现对一个产品各方位体验的完整度量。这套模型还在不断修订和完善中，但最好的模型，不是一个完美的模型，而是一个在业务中应用的模型。

在模型阶段性成熟后，我们立即开始了在业务工作流中的试点，从三件事情开始：
第一、促进 UES 成为了业务线体验管理的抓手。
基于之前 NPS 和易用性达成的良好效果，加上业务线自身对产品体验的诉求越来越强烈，UES 推出后很快获得了理解和认可，设计团队与业务线联合发起了以 UES 为抓手的体验改进项目，这让 UES 能够很快在业务产品中实际跑起来，获取到真实的体验数据和改进反馈。

第二、推动 UES 加入到产品商业化发布流程。
在阿里云，一款产品的真正发布需要经过立项、研发、线上运行的层层筛选。而加入其中，意味着 UES 固化成为了产品发布的质量标准，背后是对公司从战略层面对体验的认可，也是对设计团队之前所有体验度量研究工作的认同与信任。

第三、打造核心产品的 UES 体验改进最佳实践。
云服务器 ECS 无疑是阿里云最核心的产品，为中国 80% 的创新企业提供弹性可伸缩的计算资源。我们选择从 ECS 入手，不仅仅因为它是最核心的产品，更因为它是极其庞大和复杂的系统，如果能完成 ECS 的 UES 体验度量，意味着我们就能覆盖绝大多数的产品系统。
实践也证明了 UES 的有效性，在第一轮的测试后，我们获取了 ECS 的体验基线，优化了控制台整体样式一致性，针对易用性收集到的严重影响用户体验的问题，优化重点链路的使用体验和文案的易理解性。
几个月后第二次测试，ECS 的各项 UES 指标都有不同程度的提升，且 NPS 评分也维持到了较高区间。更关键的是，大量过去不受重视的体验问题得以曝光和修复，并反映到了实际的体验分增长中。这三件事情确保了 UES 在阿里云商业化产品体系中顺利和可持续的运转，但这，还远远不够。

面面俱到
第三、打造核心产品的 UES 体验改进最佳实践。
云服务器 ECS 无疑是阿里云最核心的产品，为中国 80% 的创新企业提供弹性可伸缩的计算资源。我们选择从 ECS 入手，不仅仅因为它是最核心的产品，更因为它是极其庞大和复杂的系统，如果能完成 ECS 的 UES 体验度量，意味着我们就能覆盖绝大多数的产品系统。
实践也证明了 UES 的有效性，在第一轮的测试后，我们获取了 ECS 的体验基线，优化了控制台整体样式一致性，针对易用性收集到的严重影响用户体验的问题，优化重点链路的使用体验和文案的易理解性。
几个月后第二次测试，ECS 的各项 UES 指标都有不同程度的提升，且 NPS 评分也维持到了较高区间。更关键的是，大量过去不受重视的体验问题得以曝光和修复，并反映到了实际的体验分增长中。这三件事情确保了 UES 在阿里云商业化产品体系中顺利和可持续的运转，但这，还远远不够。

除了「看」的整合，更关键的是「做」的提效。
对于 UES 中最核心也最复杂的易用性测试，虽然我们有了完整的行动指南，但依然需要大量的学习、培训成本，难以适应集中爆发的大量产品测试需求。
于是易用性测试工具 – Etest 应运而生。
Etest 是一个在线化、智能化的易用性测试工具。收到邀请参加易用性测试的用户，能通过Etest完成在线远程测试的，完成测试任务并提交对产品的体验反馈、为设计师提供多维数据分析。同时，Etest 能帮助每个产品的易用性测试节约大量的人力时间成本和差旅产生的费用。
年初的疫情，让客户现场拜访和调研的活动都无法正常开展，而 Etest 恰好解决了这个问题。我们通过 Etest 完成了超过 100 名用户的远程测试，保证了产品体验改进工作的持续开展。

组成部分

易用性 Ease of Use

产品使用质量的核心维度，它反应产品对用户而言是否易于学习和使用，包含易学性、易操作性和清晰性3个维度。易 性的提升可以促进操作效率和任务完成率的提升、降低学习成本、提升用户体验和满意度。

一致性 Consistency

指多款产品间通用范式部分的一致程度，分为整体样式、通用框架和常用场景及组件等维度。可以降低用户户的操作时长及错误率，降低学习成本，提升用户的满意度；对于产品设计及开发者 ，保持体验一致性可以提升开发效能，产品模块的可集成性、稳定性和可延续性 。

满意度 Happiness

反映着用户对产品或服务的期望被满足的程度，这个指标一定程度上会反映用户再次使用和对产品进行推荐的程度。

任务效率 Task Sucess

包含任务完成率和任务完成时间，云产品的任务链路相对复杂，针对有明确任务或有固定使用流程的产品，通过比对用户路径和产品设计的理想路径之间的差异，能够帮助我们发现产品流程设计上的问题。

性能 Performance

监控性能的指标有很多，其中最影响用户感知的指标是首屏渲染时间（FMP），指用户从发出请求到看到控制台主要内容的时间。其次，还包括页面请求响应时间、API 请求响应时间等指标。