如何用数据考核设计效果？来看阿里的实战经验（附独家模型）

看到这个题目，也许很多设计师会感到眼前一黑…… 笔者也不希望各位是被老板们强制要求数据化考核，才来这里寻找答案的。如果你是基层的设计师和设计主管，本文内容应该可以给你带来很多启发；如果你是数十名设计师的主管，并且可以调动更多开发、算法、运营等资源，那么你可能更应该做的无疑是自主发起业务型产品的创建，并直接获取业务结果。

好了，言归正传。

让数据的分析和验证贯穿于整个体验设计工作过程，可以促进设计师客观地洞察用户的行为和需求，全面地审视用户体验和业务价值的关系，从而用更加严谨的设计方案、推进方案、验证结果、迭代优化，最终更好地造福用户、服务公司。

范围

• 数据验证主要针对设计工作能起到重要作用的产品/项目。例如有些技术类项目，比如通过算法优化提升推荐精度，如果相关界面的调整较少，并且是同步上线，这种情况下设计能起到的作用就很有限，可以不做设计的数据验证。
• 对于品牌设计和处在实验/孵化阶段的创新性项目，不适合采用数据来度量。
• 数据只是分析验证设计结果的工具之一，可以结合其它方法同步进行，核心目的都是为了不断提升用户体验。

流程

设计的数据验证并不应该仅仅在研发阶段进行数据埋点、在项目收尾时回收查看一下数据即可，而是要将数据的收集、整理、分析和运用贯穿于整个项目流程和设计过程，与产品迭代同步，让数据助力用户体验的进化。

1. 项目规划阶段

设计师要在此阶段就着手汇总和分析相关历史数据，如果现有数据不足以辅助当前设计判断、不足以对比验证后续设计结果，需要在这个阶段进行快速的定性/定量调研。如果设计师的工作与项目其他角色关系绑定得比较紧密，应预先在规划阶段与关键角色（通常是产品经理、项目经理、运营）沟通，针对数据指标达成共识。

2. 设计阶段

设计师要将产品的用户体验目标和公司的业务目标有机结合，而不是只考虑用户的痛点和需求、忽略业务诉求，在此基础上，结合前期汇总的数据推导出的设计判断，产出完整的设计方案。

3. 开发落地阶段

跟据资源情况（包括开发、时间成本），推进设计方案落地；如果上一步产出的整体方案能够全部落地最好，如果受业务优先级和资源所限，就要因地制宜，将方案拆解开、按重要性逐步落地；同时要在开发阶段及时给出具体数据埋点需求、跟进埋点。

4. 产品上线阶段

及时整理分析数据，验证设计结果；同时思考优化空间和具体方案，为项目下一期方案的快速产出和推进做准备。

以我们公司内部的研发效能工具首页改版为例：

设计团队首先收集首页的热力图数据、对用户进行问卷调研，然后跟据这些数据分析用户需求和使用习惯；

因为该产品 面向集团所有岗位，所以设计师邀请了 PD、开发、设计师、前端各岗位的员工和管理者进行焦点小组和共建设计，辅助确定新首页包含的模块、产出方案；

开发过程中，设计与前端沟通对新版进行埋点；

新版上线一段时间后，回收埋点数据并进行新的一轮的问卷投放，然后对比数据结果：用户对新增模块的满意度高于旧模块的满意度，删除某些模块后并未引起用户反弹，新增的模块点击量和点击率非常理想，新版首页的访问量和访问率有明显提升。但新增的项目卡片的筛选和排序规则存在较多争议，后续进行了多轮优化。

注：因为本产品的用户量较大、用户群稳定，点击热力图的结果也很稳定，且 CNZZ 不支持多日的汇总热力图，因此这里取了某天的热力图。

通用模型和指标

这里介绍业内通用的数据模型和指标供参考。

结合产品阶段和项目情况，通过数据模型来选取考量维度和具体指标，可以确保数据更加专业、全面。在实践中，可采用业界通用的模型，也可以跟据自身业务的特点，针对性地创建新的数据模型。如果项目规模小、周期短，度量的数据维度通常会比较单一，可以不进行多维度量。

1. HEART模型

来自 Google 的 HEART 模型是设计验证中最通用的模型，包含五个维度：

愉悦度的数据通常通过问卷调研、舆情分析的方式获得，其它维度的数据通常需要做数据埋点。另外相关答疑数量、专家走查结果、启发性评估量表等介于定性定量之间的数据也可以纳入参考和验证。

在实践中，要跟据业务的具体情况选取，不需要强制 5 个维度全部采用。

例如下表中，上下两个项目分别采用了 H、E、A、R、T 和 H、E、A、R 的维度进行结果考核，同时增加了「页面设计品质得分」的新维度，通过专家评分获取：

2. AARRR 和 RARRA 模型

AARRR 漏斗模型包含了用户进入商业平台会经历的五个环节：

例如文档工具语雀的数据大盘包含了全部用户和新用户的留存数据表，但「新用户」的定义是首次访问的用户而非新注册的用户：

AARRR 漏斗模型的五个环节的排序是从用户从传统的认知到转化的时间维度排序的，但从营销成本和增长策略的角度，留住和盘活现有用户，比用户拉新更加重要、ROI 也更高，因此从重要性和优先级的角度衍生出了 RARRA 模型。两个模型本质上都是围绕增长的五个环节，这五个方面存在着彼此循环、彼此成就的关系，重视留存并不表示从此放弃变现和拉新，关键是跟据实际的产品阶段、数据现状、资源成本，明确工作的重心。

因为涉及商业产品的变现和传播，这两个模型涵盖的岗位角色和数据范围更广，其中渠道环节与 BD、运营的工作十分密切，传播环节与运营、创意设计工作息息相关。体验设计师的工作主要涉及用户行为相关数据指标，同时应该加强对于商业逻辑的理解和相关数据的分析，以更好地通过设计辅助产品实现增长。

3. TECH模型

TECH 模型是蚂蚁金融科技-体验技术部为企业级产品设计的体验度量体系。

TECH 模型衍生自经典的 HEART 模型。对于企业级产品、特别是工具型产品来说，产品的选择通常由企业/组织的管理层统一决定，而非具体的产品使用者，因此接受度、留存率往往不能客观衡量这些产品的体验质量；同时，企业产品通常专业性非常强，为实现提升效率这一核心目标，产品体验的清晰度至关重要。因此，在 HEART 模型的基础上去掉了A（接受度）、R（留存率），新增了C（Clarity，清晰度）指标，诞生了 TECH 模型：

4. GSM 模型

如何从数据维度和设计目标推导出具体的数据指标？如果缺少这方面的经验和思路，可以将维度与 GSM（目标—表现—指标）结合，通过系统的思考过程来筛选合理的数据指标。下表是一些 HEART 与 GSM 结合的简单举例，具体的 GSM 要跟据实际产品和项目情况而定。

5. 数据维度选择表

下表帮助你跟据产品的类型和成长阶段选择适合的数据维度，总体分为用户行为、心理感受两大类数据类型，其中「清晰度」即用户对产品的快速认知和理解的程度。

数据相关的工作必须经过思考，苏格拉底曾经说过：「未经审视的人生不值得一过。」同样，未经审视的数据经不起推敲。下图提供的是可选维度和指标，具体取用哪些，需要分析产品和项目的自身情况、以及设计的具体目标和方案。

6. 数据指标缩写表

7. 应用举例：B 类产品增长数据

为辅助设计师展开增长设计实践，笔者根据上面介绍的通过模型和指标，针对 B 类产品的业务场景，拟定了 RARRA 模型各维度的核心数据指标。项目实践中，具体指标要跟据产品和项目的设计目标做取舍，可以同时结合上面介绍的 GSM 模型来进一步拆解。

增长设计中数据获取的难点：初创期的产品度过最初 0 到 1 的阶段之后，会存在很多可能性，增长实验空间较大，但用户基数少、缺少健全的数据埋点，往往需要通过少量用户的访谈和测试获得数据；成熟期的产品、特别是成熟的商业化产品，各维度的数据比较全面，但增长空间和机会很有限，需要不断从细节或细分领域挖掘。

8. 注意事项

关于数据指标的选择和运用，需要注意以下两点：

跟据设计目标推导具体指标的过程中，需要充分考虑客观情况。

比如「诊断工具」项目中，设计方目标是帮助用户快速发现功能、查看诊断结果，并建立使用习惯，因此打开率可以作为考核指标；但是用户打开之后是否采纳并不是设计的主要目标，因为这在很大程度上取决于算法精度。如果诊断结果采纳后的操作流程非常繁琐，设计师可以将「让用户高效完成操作」作为目标，进而将流程完成度、完成时间纳入设计验证指标。

其它因素的客观分析。

一个产品的上线，离不开产品经理、设计、运营、前端、开发、算法、测试等各个角色的共同协作，因此即便我们选择了设计工作影响最大的数据指标来验证结果，也不能完全排除其他角色的因素。所以设计师需要客观分析其它因素的影响、解析这些因素所占的影响比重，而不是大包大揽把所有功劳都算到自己名下。

举个简单的例子，设计师准备通过部分界面的改版提高某个模块的使用率，改版如果选在运营比较平稳的阶段上线，获得的结果中设计占的影响必然比较大，反之如果选在运营进行推广活动的阶段上线，就较难区分结果中设计和运营的影响比例。

数据陷阱

数据分析一旦运用自如之后，更要注意不能自作聪明，切忌拿一些缺乏说服力的数据忽悠同事，这样只能适得其反。容易出现陷阱包括：

1. 不客观、不全面

在设计中纳入数据分析和验证，目的是为了让设计师能深入思考业务和用户体验的关系、客观地验证设计效果，因此采用的数据本身必须客观、全面。

举个例子，某设计师说，我改进了某产品的某功能的体验，但是我这个产品的用户基数较小，使用某功能的频率也有限，设计优化之后，因为基数不大，每天的结果数据波动很大，所以我随机抽取改进前的某天和改进后的某天的数据进行对比，作为验证结果的依据。面对这样的阐述，有人相信他真的是「随机」抽取某天的数据吗？即便真的是随机抽取，同样没有说服力。如果因为随机性较强造成每日数据波动大，可以采用 30 日的平均数，做前后对比。

2. 自说自话

就是自己又是运动员、又是裁判，什么都是自己说了算。举个例子，某设计师设计了某个新功能并推进上线，之后评测同事的评测结果是有 35% 的用户采用了新功能之后，效果有提高…… 也就是 65% 的用户用了新功能之后效果或者不变、或者反而下降了。这个时候设计师回答得非常巧妙—— 我的目标不是提升数据，而是保证一定的使用率。如果公司的盈利就是来自用户效果，那么这位设计师的新产品难道不是适得其反了吗？

所以，需要如前所述，在项目规划阶段就要和合作方就数据指标达成一致。

3. 忽视客观条件

举个例子，某产品在上线了设计师发起和设计的新功能之后，新功能使用量与日俱增，使用率屡创新高（具体数据暂不列出），说明设计师为业务创造了重大价值。这种表述方式在项目战报中经常出现，它们通常会有意无意的忽略一个客观条件，就是业务自身的发展情况。在这个案例中，之所以使用量和使用率大大提高，一个客观条件是此产品正处在新用户激增的过程中，造成新功能的数据水涨船高，同时运营针对新用户推广新功能的工作也起到了重要作用。

再举个真实案例，某同事为了验证全行业营销推广平台中自动化推广（通过算法实现自动匹配等功能）的效果，注册了新用户之后，在一周之内，同时进行人工操作和自动化操作，结果是一周之后的推广结果数据对比发现，自动化操作的效果确实高于他人工操作的效果，以此证明自动化是一个成功的功能。

这个案例的漏洞很多，最明显的就是：这位同事人工操作水平如何？如果他是资深用户，人工推广不如自动推广效果好，只可以部分证明自动化推广在该行业中的价值（营销推广在行业间存在较大差异），但如果他本身就是个菜鸟，就是输给了机器算法也无法证明什么。

以上都是真实案例，现在解析起来似乎都是低级错误，但是彼时提出时未必会立刻发现问题所在。因此设计师需要在平时加强数据方面的实践，提升专业性和敏感度。

总结

• 设计的数据分析验证，不仅仅是在研发阶段进行数据埋点、在项目收尾时回收查看即可，而是让数据的收集、整理、分析和运用贯穿整个项目过程的始终，与产品一起不断迭代进行。
• 用于验证结果的数据指标一般不需太多，但前期用于理清情况、辅助判断的数据往往要更多。
• 所有涉及数据的工作，都必须经过针对性的分析和思考，不存在「一招鲜吃遍天」，也不存在「即插即用」。本文能够给大家指导和启发，但不能代替大家思考和行动。
• 所有的数据都存在一定误差，只有通过不断自我拷问的数据，才能经得起别人的拷问。
• 数据指标的核心目的不应仅仅是考核工作结果，而是促进设计师深入洞察用户行为和需求、全面审视业务价值和体验设计的关系，从而更加客观、实际、严谨地设计和推进方案，最终更好的造福用户、服务公司。