如何证明设计价值？帮你快速掌握数据分析的基础逻辑

经常能听到设计师大谈特谈数据分析，一般讲的是漏斗分析，或者分析留存、PV/UV 之类的分析方法和细节，偶尔有些设计团队分享谷歌的 GSM 模型，但是很少听人讲数据分析的基础逻辑。这周我正好事情很多，就和大家简短的分享一下。

对于设计来讲，数据分析就 4 步：

• 制定指标：知道要去分析什么
• 衡量指标：什么是符合预期、什么是正常波动、什么是异常波动
• 拆解分析：假如数据不符合预期/出现异常波动，找到关键场景
• 分析原因：内部/外部原因

制定目标

项目目标：也就是谷歌 GSM 里的“Goal”。项目开始时，你就应该了解：这个项目的业务目的是什么？是提升老用户的平台粘性还是拉新促活？是提升熟练用户的操作效率从而提升平台体验，还是帮助新用户更好的学会使用产品从而降低平台运营成本？项目目标是整个设计项目的根本评判标准，虽然一般不是设计定的，但我们可以在开工之前问一嘴。

设计目标：大部分情况下，设计目标和项目目标是两个不同的目标，设计目标往往只看行为指标（PV/UV/时长等等）和态度指标（满意度/NPS 等等）。

设计目标可以是项目目标的一部分，但是因为项目目标经常包含和行为/态度数据（也就是 PV/UV/满意度）无关的滞后业务指标（比如 GMV），这种业务指标对设计没什么指导价值，也很难证明设计对业务指标有直接影响，所以一般不建议把项目目标直接作为设计目标。

衡量指标

现在你已经有了自己的设计目标——比如你的项目满意度是3.5，那3.5是好还是差？这是需要定义的。互联网设计是一种带点创意的、可证伪的实证研究，为了让我们这个设计可证伪，我们需要划出那条证明/证伪的界限。一般而言有三种办法：

纵向趋势比较：我们可以和上一个时间周期做对比（比如本月和上个月的满意度对比，这叫环比）；或者和一个更大的时间周期中相同的节点做对比（比如今年 1 月和去年 1 月的满意度对比，这叫同比）

横向比较：和竞品或者和平台其他模块比较，比如虽然我们的功能满意度只有 2，但是竞品是 1，说明总体我们解决的比他们稍微好些。

基线比较：有些量表（比如 NPS、SUS）自带了推荐的基线值，低于基线（比如 NPS 的 7 分）可以说明体验就是不太好。

拆解分析

讲这一块之前我们先举个例子，北京某大学有两个学院，经济学院和教育学院。广东/天津两地各有 700 个学生报考了这个大学，其中广东省有 380 人高中，而天津只有 260 个人考中了，假如你来做这个分析，现在能得出结论：广东省的录取率比天津省高吗？

不能。

假如我们以学院-省份两个维度去拆解数据，可能会发现：经济学是当年大热门专业，录取门槛极高，而教育学院没招满，录取分数线比较低。广东省报考某大学的学生报教育学院的比较多，而天津报考某大学的学生报经济学院的多。这么一算，反而在两个院中，天津学生的录取率都比广东学生高

这件事情说明，我们需要探索、分析所有可能对总体情况造成影响的场景或者指标，否则分析结果就会和事实产生偏差。以满意度为例，有几种拆解维度：

基于时间的：缩小分析的时间单位，是否在某一周内满意度骤降，导致一个月内平均满意度都有下跌？

基于人口统计学的：不同年龄段/性别/地区/语言的用户，是否在满意度上有差异？是否有明显不满意的群体？

基于用户技能/行为习惯的：新老用户、小白/专家用户、不同用户角色、不同诉求的用户是否在满意度上有差异？

基于任务环节的：不同任务环节、甚至不同页面，是否在满意度上有差异？

分析原因

拆解不同维度分析后，我们基本可以定位到具体影响设计目标的关键问题点：比如一部分老用户的满意度下降了，或者 1-2 月间的 PV 大幅下降导致整体指标受影响。最后，我们需要为这些现象找到原因。

有时原因是周期性的、不可避免的，比如一般改版后老用户都需要一点时间去适应新的设计方案，这会导致短期内满意度降低，但 2 个月内会有慢慢回升。又或者节日/突发性事件都会对某些产品/设计产生影响。有时原因是外部的：比如虽然我们没有做什么事情，但是竞品上线了新功能，或者因为政策局势的变化引起了变化。

当然，更多的时候原因是内部的、和设计相关的，比如设计中遗留的可用性问题或者部分边缘场景没有被支持到。为了挖掘出这些原因，往往我们需要和用户实地访谈，或者至少打打电话。因为问卷、取数的结论比较浮于表面，只能给到浅层的概念，而深刻的洞见、真实的反馈，只能在人和人沟通的时候渐渐表露出来。

欢迎关注作者微信公众号：「白话说交互」