自KPI、OKR、AB实验等理念流入互联网后，长期以来业内的行事准则都是“数据导向”，想必日常工作中你也经常被产品规劝“哎呀～这样做数据一定会好的，不要在乎这些体验细节”，或者你也有过试图说服产品“体验好的话数据就会好呀”，但往往有些时候在项目规划和设计阶段自信满满地认为可以带来数据收益的项目，上线后却不理想，这是为什么呢？本期，我们来说一说项目上线后数据复盘和体感差异的原因。

我们先厘清几个概念，体验好、口碑好和数据好。在这里我们暂且先定义「体验好」为项目执行者认为的好体验，诸如减少一步操作、更容易获取关键信息等业内理论上认为的体验好；「口碑好」是项目实际上线后用户的正向反馈；「数据好」是项目上线后观测指标达到或超出预期。如果照这么理解的话，我们通常的思路是「体验好」带来「口碑好」，「体验好」和「口碑好」共同带来「数据好」。

接下来我们通过几个案例来详细讲讲实际发生的，不符合模型的情况

#1
口碑差，数据好

写这个议题的时候，首先映入脑海中案例就是19年订阅号的一次改版，改版的主要优化点是把原先进入时为账号列表改为进入文章信息流，如下图所示：

从产品设计思路上来讲，用户进入是来消费文章的，原方案用户需要先选账号（文章来源），再选择想要阅读的文章，改版后直接把文章呈现在用户面前，属于设计思路中常见的“减少一步”带来的“体验优化”。然而项目上线后却遭到用户的强烈不满，用户意见诸如：“越改越乱”、“我现在都不知道哪些公众号有多少条消息没看”、“逼着我取消了好几个公众号”，当然，其中也不乏一些赞美之词，但不习惯/不喜欢/体验差的声量还是占据了反馈的绝大部分。在这样的骂声中产品还是坚持这样的方案，想必数据应该给了产品相当大的正向反馈。这是一个理论上体验好，实际上口碑差但数据好的案例。

我们将用户反馈进行一些归类处理，就能发现这次数据复盘与体感差异不符的原因。负反馈的用户大多是有深度阅读习惯的用户，习惯是先寻找今日想钻研的领域（对应某个账号），然后一次性地认真阅读吸收文章，改版后对这类用户来说，首页的劣质内容抢占了太多视线，导致寻找合意的文章变得困难。

假设一下你是一个历史系的学生，你每天会去学校图书馆里的历史区阅读相关书籍，但你也喜欢看杂志和小说，历史书读累了偶尔也会逛逛其他图书区。现在图书馆突然跟你说，反正你来这里都是看书的，我发现你会看历史书、杂志和小说，我把所有的杂志小说都和历史书混在一起给你，省的你在这些区里走来走去的，你会因为图书馆让你少走了几步而感谢它吗？显然不会，这样你每天读书之前就得先把历史书筛选出来，而筛选历史书的成本远比多走几步路的成本大得多。

当然，肯定不是所有人去图书馆都是去读专业书的，也不是所有使用该功能的用户都有深度消费习惯，但是用户对功能的依赖程度不同，导致用户愿意为功能发声的意愿也不同，当深度用户的体验折损远远大于非深度用户的体验升级，带来的必然是负反馈强势碾压正反馈。
**

而为什么数据会好呢？深度文章的生产和消费成本远远大于非深度文章（成本可以理解为需要付出的时间&需要掌握的知识储备），原来先找账号后找文章的方式，用户会主动去寻找深度文章来阅读，而现在是非深度文章占据了首页百分七八十的版面，假设你每天花100分钟阅读，阅读一篇深度文章需要25分钟，阅读一篇非深度文章需要5分钟，那么改版前你每天可以阅读4篇文章，改版后你每天可以阅读20篇文章，数据这不就上去了？
再举例假设，全校1000个学生，只有50个学生每天泡馆，200个学生经常去，其他学生比较少只看一类书，甚至有的同学不爱看专业书，觉得去图书馆麻烦就不常去。但是图书馆改版后，所有书你随便抓一本就可以开始看，50个每天泡馆的学生不爱去了，200个经常去的学生里100也不爱去100个觉得差不多，但是剩下750个学生里有600开始抽空去图书馆看一看了，这图书馆的生意不也好起来了。

#2

体验好，数据差

我在几年前做过一款国外产品，针对的是非发达国家地区的摩的市场，可以简单理解为国外打摩的软件，用户在软件上呼叫摩的后，摩的师傅来接送你，你需要在软件上输入摩的师傅的号码完成旅程并付款。简单流程示意如下图。

当时二维码已经在国内盛行起来了，国内用户已经习惯了使用二维码做任何事，包括付款。我们认为使用二维码会比输入一串数字来说更简便，体验更好，所以决定把输入「摩的的编码」这一步优化为「扫描摩的上的二维码」，并向摩的师傅们发放了专属的二维码贴纸。我们自信满满，觉得这样的优化一定能够带来用户体验的升级，拉新促活不在话下。然而结果却背道而驰，改版后平台成单量显著下降了。我们不得已做了一次当地用户调研和访谈。

原来，因为当地经济情况和技术水平都较落后，二维码对当地人来说十分陌生，人们很难下决定通过这样陌生又迅速的行为去执行付款操作。用户对二维码表现出的强烈不安全、不信任感直接影响了用户放弃成单付费。相反，输入数字串（俗称PIN码）虽然流程相对繁琐，但对于付款这种慎重的行为，恰好留足了时间做思考和决定。

与此相似的案例在国内产品上我又碰到了一次，这次是开设房间时需要对房间设置权限，起初我们的版本是作为选择项，用户开房时可以选择所有人可加入或者只有朋友能加入。有一次，我们觉得这样的设计似乎有些繁琐，只需要一个权限开关就可以了，打开开关就是仅朋友能加入，关闭开关就是所有人都可以加入（这层含义较隐晦，需要用户额外去思考和理解），我们又一次自信满满地上线了。结果又一次与预期背道而驰。

第一个例子与第二个例子有一个相似之处，是对用户来说，这都是一个“谨慎的操作”，对于“谨慎的操作”，传统理论上那些「体验好」的方法（更快一点，更简单一点）不太受用，这些「体验好」的设计仅仅只是从行动上帮用户减少了一两步，却没办法帮助用户减少执行行动前的思考。举个例子，你本来需要亲自开飞机空投炸弹，优化到你只需要按一个按钮就可以发射炸弹，对你投炸弹这个行为的影响大吗？不大，因为「要不要投炸弹」在行动前的思考远远复杂于「投炸弹」这个行为。反而可能因为我们有时间在飞机上了解清楚“炸弹”，而没办法在按钮上对“炸弹”有理解，而导致面对着按钮犹犹豫豫，最终放弃。对于复杂且谨慎的行为，设计清楚（帮助用户在思考节省时间）远比设计简单（行动简单了但思考不会简单）来得更重要。

#3

体验不好，数据好

-“我在这里放个按钮/入口！”
-“这里不符合使用场景呀。”
-“我知道，但这里流量大（os：我需要流量把我的功能戴起来）”
-“……”
-“按钮/入口要设计得大一点，再大一点，颜色要鲜艳的，最好是大红色，能来点动效就更棒了”

不知道这样的对话大家熟不熟悉，我早期的职业生涯中经常能遇到这样的项目需求。但往往这样又大又红的设计还总能拿到很好的数据供人吹嘘，明明用过的人都觉得这样的设计体验很不好，为什么却在数据的驱使下越来越猖狂呢？

以上图的例子做展开，在这样的需求下，我们可能会被迫作出这样的设计：

上线后，项目负责人发了一封邮件：需求上线后「算命」功能使用pv/uv上涨显著，证明这是一个合理的需求，非常好的设计，我们要朝着这个方向持续优化！

——但你真的觉得这是一个合理的需求、好的设计吗？

这就是典型的把数据当目标，以片面下结论的情况。
首先我们必须明确一点，做需求做设计都是为了更好的体验或服务新的产品阶段，数据只是辅助我们判断有没有达成目标的工具，切莫盲目服务数据。其次，在做需求做设计的时候应有全局观。就以上述所举例子展开，需求的目标应该是在用户想算命的场景提供算命服务，如果我们判断消息页是用户想要算命的场景，那么我们上线后观测的数据除了算命功能的pv/uv，还需要补充退出率，以及顶部新增算命入口后，对聊天页的折损数据（聊天pv/uv，收发消息数…），把这些考虑进去我们很可能得到不一样的数据结论：

看完真实的复盘后，首先应该能判断消息页不是用户想算命的场景，此时如果你的产品策略不是把这个软件转型成算命软件就可以下掉这里的入口了；如果你正要转型算命软件，非常需要消息页来带量，那么你也能看出来在这里加入口对聊天体验的折损有多大，此时你就得思考一下，「带起来的量」值不值得聊天功能「折损的体验」？
如果不值得，你也可以开始考虑换种方式带量了；如果值得，那继续做大做强就没什么问题了，祝福这个产品成为算命一霸。

总结

项目上线后数据复盘与体验有差异是很常见的，包括但不限于上面所述案例表现出来的原因。总之，还是要牢记数据是工具，不是目标，如果发现数据复盘结果与预期有不符，可以尝试：给用户分层，更细致化地分析用户行为；通过用户调研了解用户真正的使用场景和流程，真正帮用户解决难点而不是“伪体验好”；以及，用更全面的视角、结合更多信息来看待项目是否达成目标。“数据说谎”的现象还有很多，将来再继续讨论。