因为是全面揭秘，所以文章很长，请耐心阅读。
作为一个体验设计师，我们会面临很多问题：复杂的产品需求、纠缠的技术逻辑、难以决策的设计方案、难以计量的设计价值。
而对于面对横跨 IaaS, PaaS, SaaS 几百款产品的阿里云设计师，问题更具挑战性，但也更具备机会。我们面临着庞大的产品体系，也就意味着充足的实践空间；我们面对着复杂的设计问题，也就意味着全面的经验沉淀。因此，
如何在支撑业务的同时创造机会，让设计在行业中释放出更大的能量和价值，就成为了我们的使命。
我们意识到，对于一个复杂的产品系统，体验设计师不应仅是体验的微观设计者，也应是体验的宏观管理者。但体验是一个过于宽泛和宏大的词，而我们专注于其中和设计师最紧密也最攸关的部分：产品的使用体验，即用户在产品使用场景中完成期望目标时所产生的体验。这是用户和产品直接接触的部分，也是最有感知的部分。
而这篇文章，就是为您分享阿里云设计中心建立的
阿里云产品使用体验度量系统 - UES。
UES（User Experience System）是阿里云设计中心通过多年设计实践中沉淀下来的云产品使用体验度量系统，它不仅是一套方法论，更是一套可运行的体系，由三大部分有机构成：
1、一个包含五大维度的 UES 体验度量模型。
2、一个体验问题从发现到闭环的体验管理机制。
3、一个易用性测试和数字化管理的体验工具集。
通过 UES，我们度量、我们监测、我们改进。我们希望打造云计算领域第一个系统化、工具化的产品使用体验管理体系，并致力于将它开放给更多行业的设计师所用。
但罗马不是一天建成的，凭空出现的大厦要么是海市蜃楼，要么是空中楼阁，而对于任何不断进化的复杂系统，科学的推理过程，往往比暂时的结果更有价值。因此这回，我们不直接给你结果，而是把故事从头说起。
我们如何管理体验？现代管理学之父，彼得·德鲁克说：「如果你不能很好地度量它，也就无法有效地管理它。」
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调用是否快捷，这些或主观或客观的因素都会综合影响用户体验。
