产品使用体验如何量化与管理——阿里云 UES 全面

　　作为一个体验设计师，我们会面临很多问题：复杂的产品需求、纠缠的技术逻辑、难以决策的设计方案、难以计量的设计价值。

　　而对于面对横跨 IaaS, PaaS, SaaS 几百款产品的阿里云设计师，问题更具挑战性，但也更具备机会。我们面临着庞大的产品体系，也就意味着充足的实践空间；我们面对着复杂的设计问题，也就意味着全面的经验沉淀。因此，如何在支撑业务的同时创造机会，让设计在行业中出更大的能量和价值，就成为了我们的。

　　我们意识到，对于一个复杂的产品系统，体验设计师不应仅是体验的微观设计者，也应是体验的宏观管理者。但体验是一个过于宽泛和宏大的词，而我们专注于其中和设计师最紧密也最攸关的部分：产品的使用体验，即用户在产品使用场景中完成期望目标时所产生的体验。这是用户和产品直接接触的部分，也是最有的部分。

　　UES（User Experience System）是阿里云设计中心通过多年设计实践中沉淀下来的云产品使用体验度量系统，它不仅是一套方，更是一套可运行的体系，由三大部分有机构成：

　　通过 UES，我们度量、我们监测、我们改进。我们希望打造云计算领域第一个系统化、工具化的产品使用体验管理体系，并致力于将它给更多行业的设计师所用。

　　但罗马不是一天建成的，凭空出现的大厦要么是海市蜃楼，要么是空中楼阁，而对于任何不断进化的复杂系统，科学的推理过程，往往比暂时的结果更有价值。因此这回，我们不直接给你结果，而是把从头说起。

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

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

　　但这个过程并非一帆风顺，硬核的阿里云产品从来都是技术导向，对用户体验的度不像 C 端产品那么强烈，更难引起重视。我们决定先在小范围的产品进行切入。2016 年 10 月起，我们首先从云安全的产品入手，一步步去推进 NPS 度量，去建立体验。同时，在 NPS 的问卷中，我们加入更细致的满意度问卷，让用户更好地反馈，对体验问题进行深入洞察。

　　设计中心的持续推动，让 NPS 开始被产品的管理者所认可和重视。那些不确定的用户体验，开始为确定的净推荐值和大量的体验问题反馈，给产品改进带来实实在在的，进而又让产品更加重视对用户体验的管理。体验和产品的，从此了一个良好的正循环。而过去一年，NPS 已经从一个设计发掘的体验数值，变成了大量云产品的核心指标，而从这些举足轻重的产品中，我们发现并改进上百个用户体验问题。

　　但对于设计师来说，度量用户体验的命题却远未得到解决。NPS 更多侧重在用户的综合评价上，包含产品价格、安全性、稳定性等综合因素，用户体验的要素被在这些复杂的「变量」中难以剥离。

　　而控制和分离变量，是一个科学的度量系统最基本的要求。于是，我们的设计师又开始了新一轮的研究和测试，以寻找一个更合适的用户体验度量方法，去回答一个最基本的问题：

　　1989年，在技术接受模型( Technology Acceptance Model，TAM )中，Davis 指出了两个影响技术类产品使用的核心因素：「有用性（usefulness）」和「易用性（ease of use）」。「有用性」更多是产品能力本身层面的属性，关乎功能和商业，而「易用性」则是设计师能把握和发力的核心，因此，我们决定聚焦「易用性」，作为撬动中后台技术产品使用体验的杠杆。

　　这些量表虽然久经，但它们都不是为互联时代和云产品体系而生。以 SUS 量表为例，John Brooke 在 1986 年编制它的时候，乔布斯刚刚离开苹果创建 NeXT ，距离中国第一封电子邮件发出还有一年。它也并非为中文而设计，其中的第8题：「我发现这个系统使用起来非常笨拙(cumbersome)。」在实际测试时让用户十分困惑，因为在中文语境中，很少有人会用「笨拙」这个词去形容一个软件系统，但你又很难找到一个更合适的词汇去覆盖它的本意。

　　因此，与其墨守成规地去套用一个过时的量表，我们决定去粕取精，去设计一个适合我们自己的量表。在15个易用性问卷中，我们抽取合并出30个典型问题，并走访客户和用户研究专家，让他们选择这30个问题中最关心和认为最重要的问题，以此确定一个12题版的标准问卷，以及6题版的核心问卷。我们把这套度量表，命名为：

　　在进行了一段时间的实验室测试后，我们对收集到的样本数据进行了一次信度分析，在最常用也是最准确的科隆 α 系数分析中，我们的评分甚至优于 SUS 等传统量表的信度。而更关键的是，有了高置信度的量表，我们不再需要成百上千的测试数，而是达到十几个样本即可。这对许多需要用户基数比较少和测试难度高的技术产品无疑至关重要。

　　整体量表值得信赖还不够，我们又进一步进行了探索性因素分析，以验证我们的问卷是否能有效地将 12 个变量综合为 3 个核心因子，它们分别是：

　　而通过 KMO 和 Bartlett 的检验，发现易用性量表非常适合进行因子分析，结果具有显著性，且量表 3 个维度项目的因子载荷系数符合易用性预设的专业维度，综合说明易用性量表具有较高效度水平。

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

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

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

　　有了易用性测试的成功为基础，我们便有了更多的信心，去探索更全面的云产品体验度量系统。而这，就是回到了我们前面说的，阿里云产品使用体验度量系统：UES（User Experience System）。

　　易用性描述了产品体验的一个重要维度，但不是唯一。交互和视觉设计是否一致、页面渲染和API调用是否快捷，这些或主观或客观的因素都会综合影响用户体验。

　　和易用性的思一样，我们也不机械套用已有的模型。适合的 PLUSE、谷歌的 HEART、蚂蚁的 TECHP，它们各有切入点，也各有其适应场景。方法虽无法穷尽，思维却可以归纳。我们发现，无论模型怎么变化，表达产品体验的重要度量指标，总逃不开这三个范围：用户态度、用户行为、系统表现。

　　于是我们根据 B 类技术产品特性，在多个维度中评估和挑选，重新思考定制，设计了 UES 模型的五个维度：

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

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

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

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

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

　　其中，NPS 问卷中的满意度反映产品的整体主观体验；一致性提供以规范为纲的设计一致性走查和客观计量方法；性能关注产品的体验技术指标；任务通过 UBA 工具度量核心任务的成功率；易用性则得出产品体验最核心的主观指标，并输出具体体验问题清单，指导产品改进。

　　这五个维度有主观，有客观，有定性，有定量，我们用不同的测试方法和工具适应不同的测试指标，以期实现对一个产品各方位体验的完整度量。这套模型还在不断修订和完善中，但最好的模型，不是一个完美的模型，而是一个在业务中应用的模型。

　　基于之前 NPS 和易用性达成的良好效果，加上业务线自身对产品体验的越来越强烈，UES 推出后很快获得了理解和认可，设计团队与业务线联合发起了以 UES 为抓手的体验改进项目，这让 UES 能够很快在业务产品中实际跑起来，获取到真实的体验数据和改进反馈。

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

　　云服务器 ECS 无疑是阿里云最核心的产品，为中国 80% 的创新企业提供弹性可伸缩的计算资源。我们选择从 ECS 入手，不仅仅因为它是最核心的产品，更因为它是极其庞大和复杂的系统，如果能完成 ECS 的 UES 体验度量，意味着我们就能覆盖绝大多数的产品系统。

　　实践也证明了 UES 的有效性，在第一轮的测试后，我们获取了 ECS 的体验基线，优化了控制台整体样式一致性，针对易用性收集到的严重影响用户体验的问题，优化重点链的使用体验和文案的易理解性。

　　几个月后第二次测试，ECS 的各项 UES 指标都有不同程度的提升，且 NPS 评分也维持到了较高区间。更关键的是，大量过去不受重视的体验问题得以和修复，并反映到了实际的体验分增长中。这三件事情确保了 UES 在阿里云商业化产品体系中顺利和可持续的运转，但这，还远远不够。

　　各维度的数据指标产生后，很快我们就意识到，我们亟需一个「数字化管理平台」来对这些数据进行统一的查看和管理，并洞察结果能够改进落地。建平台本身不是目的，但需要建立好工具和平台，体验管理才实现标准化和规模化。

　　它需要能够对所有的体验数据做一站式的便捷化管理，经过UES标准的数据模型和加权，将5个维度的度量分形成「体验分」呈现给产品PD。

　　针对在各维度测试环节中提出的体验问题，包括体验设计、功能开发、前端、文案4个类型，需要能方便进行实时的与修复，帮助体验问题从「洞察」到「闭环」。

　　最后，它能够支持完成单个产品内多次度量的比较，明确体验改进的效果，为产品规划提供辅助决策。

　　基于以上三个目标，我们设计并在云知（阿里云数字化产品管理系统）集成了 UES 的体验度量看板，让 PD 可以随时查看目前产品使用体验的水位，了解产品体验的薄弱项，跟进体验问题改进。

　　对于 UES 中最核心也最复杂的易用性测试，虽然我们有了完整的行动指南，但依然需要大量的学习、培训成本，难以适应集中爆发的大量产品测试需求。

　　Etest 是一个在线化、智能化的易用性测试工具。收到邀请参加易用性测试的用户，能通过Etest完成在线远程测试的，完成测试任务并提交对产品的体验反馈、为设计师提供数据分析。同时，Etest 能帮助每个产品的易用性测试节约大量的人力时间成本和差旅产生的费用。

　　年初的，让客户现场拜访和调研的活动都无法正常开展，而 Etest 恰好解决了这个问题。我们通过 Etest 完成了超过 100 名用户的远程测试，了产品体验改进工作的持续开展。

　　从 2016 年初探 NPS，到 2018 年开始深耕易用性，到 2020 年，基于 UES 的云产品数字化管理系统初步建成和工具化，我们从一个开始到另一个开始，此时在做的工作很多，彼时要做的工作更多。但我们依然在思考，下一个「更大的问题」是什么？

　　最初，我们希望度量「云产品」的用户体验，未来我们能否度量「产品」的用户体验？最初，我们希望解决「阿里云设计师」的问题，未来我们能否解决「设计师」的问题？或者更远一点。

　　既然云计算把计算资源云化，让千百万没有能力建设数据中心的企业获得弹性的海量资源；若设计也可以云化、体验可以度量，那我们是否能让千百万没有设计能力和团队的企业，能更低成本地获得好的用户体验，进而提升整个社会的平均产品设计水平？

　　我们正在推进 UES 模型的进一步迭代完善，并将在 2020 年内全面 Etest 工具，目前产品核心功能刚刚孵化成型，还在持续生长和进化，以让我们有能力服务于阿里云体系外更广泛的应用场景。

　　云计算行业有 33 项国家标准，却没有一个设计标准；而过去一年，阿里云设计中心起草并发布了 2 项云产品体验度量的国家团体标准：《云计算软件产品易用性度量方法》团体标准和《云计算软件产品使用体验度量模型及方法》团体标准。

　　形成标准的目的，是把我们一整套的体验度量和实践经验，「开源」给整个行业，这样才能激发出更多的团体标准、企业标准、国家标准，进而促进设计产业的工程化发展。

　　·面向生态伙伴，通过输出行业标准，为阿里云产品和解决方案提升专业度和信任，为生态伙伴提效赋能。

　　以上这些，似乎是远方遥不可及的终点，但也是作为设计师，支撑我们在体验度量这条上，求索和探寻至今，最初的起点和初心。体验的量化与管理，是我们为了构建云上美好生态的方法与工具，我们起步于此、于此，也不会止步于此。