百木园
自KPI、OKR、AB实验等理念流入互联网后，长期以来业内的行事准则都是“数据导向”，想必日常工作中你也经常被产品规劝“哎呀～这样做数据一定会好的，不要在乎这些体验细节”，或者你也有过试图说服产品“体验好的话数据就会好呀”。
但往往有些时候，在项目规划和设计阶段自信满满地认为可以带来数据收益的项目，上线后却不理想，这是为什么呢？本期，我们来说一说项目上线后数据复盘和体感差异的原因。
我们先厘清几个概念，体验好、口碑好和数据好。
在这里我们暂且先定义「体验好」为项目执行者认为的好体验，诸如减少一步操作、更容易获取关键信息等业内理论上认为的体验好；「口碑好」是项目实际上线后用户的正向反馈；「数据好」是项目上线后观测指标达到或超出预期。
如果照这么理解的话，我们通常的思路是「体验好」带来「口碑好」，「体验好」和「口碑好」共同带来「数据好」。
接下来我们通过几个案例来详细讲讲实际发生的，不符合模型的情况
01 口碑差，数据好
写这个议题的时候，首先映入脑海中案例就是19年订阅号的一次改版，改版的主要优化点是把原先进入时为账号列表改为进入文章信息流，如下图所示：
从产品设计思路上来讲，用户进入是来消费文章的，原方案用户需要先选账号（文章来源），再选择想要阅读的文章，改版后直接把文章呈现在用户面前，属于设计思路中常见的“减少一步”带来的“体验优化”。
然而项目上线后却遭到用户的强烈不满，用户意见诸如：“越改越乱”“我现在都不知道哪些公众号有多少条消息没看”“逼着我取消了好几个公众号”，当然，其中也不乏一些赞美之词，但不习惯/不喜欢/体验差的声量还是占据了反馈的绝大部分。
在这样的骂声中产品还是坚持这样的方案，想必数据应该给了产品相当大的正向反馈。这是一个理论上体验好，实际上口碑差但数据好的案例。
我们将用户反馈进行一些归类处理，就能发现这次数据复盘与体感差异不符的原因。
负反馈的用户大多是有深度阅读习惯的用户，习惯是先寻找今日想钻研的领域（对应某个账号），然后一次性地认真阅读吸收文章，改版后对这类用户来说，首页的劣质内容抢占了太多视线，导致寻找合意的文章变得困难。
假设一下你是一个历史系的学生，你每天会去学校图书馆里的历史区阅读相关书籍，但你也喜欢看杂志和小说，历史书读累了偶尔也会逛逛其他图书区。
现在图书馆突然跟你说，反正你来这里都是看书的，我发现你会看历史书、杂志和小说，我把所有的杂志小说都和历史书混在一起给你，省的你在这些区里走来走去的，你会因为图书馆让你少走了几步而感谢它吗？显然不会，这样你每天读书之前就得先把历史书筛选出来，而筛选历史书的成本远比多走几步路的成本大得多。
当然，肯定不是所有人去图书馆都是去读专业书的，也不是所有使用该功能的用户都有深度消费习惯，但是用户对功能的依赖程度不同，导致用户愿意为功能发声的意愿也不同.
当深度用户的体验折损远远大于非深度用户的体验升级，带来的必然是负反馈强势碾压正反馈。
而为什么数据会好呢？深度文章的生产和消费成本远远大于非深度文章（成本可以理解为需要付出的时间&需要掌握的知识储备），原来先找账号后找文章的方式，用户会主动去寻找深度文章来阅读。
而现在是非深度文章占据了首页百分七八十的版面，假设你每天花100分钟阅读，阅读一篇深度文章需要25分钟，阅读一篇非深度文章需要5分钟，那么改版前你每天可以阅读4篇文章，改版后你每天可以阅读20篇文章，数据这不就上去了？
再举例假设，全校1000个学生，只有50个学生每天泡馆，200个学生经常去，其他学生比较少只看一类书，甚至有的同学不爱看专业书，觉得去图书馆麻烦就不常去。
但是图书馆改版后，所有书你随便抓一本就可以开始看，50个每天泡馆的学生不爱去了，200个经常去的学生里100也不爱去100个觉得差不多，但是剩下750个学生里有600开始抽空去图书馆看一看了，这图书馆的生意不也好起来了。
02 体验好，数据差
我在几年前做过一款国外产品，针对的是非发达国家地区的摩的市场，可以简单理解为国外打摩的软件，用户在软件上呼叫摩的后，摩的师傅来接送你，你需要在软件上输入摩的师傅的号码完成旅程并付款，简单流程示意如下图：
当时二维码已经在国内盛行起来了，国内用户已经习惯了使用二维码做任何事，包括付款。我们认为使用二维码会比输入一串数字来说更简便，体验更好，所以决定把输入「摩的的编码」这一步优化为「扫描摩的上的二维码」，并向摩的师傅们发放了专属的二维码贴纸。
我们自信满满，觉得这样的优化一定能够带来用户体验的升级，拉新促活不在话下。然而结果却背道而驰，改版后平台成单量显著下降了，我们不得已做了一次当地用户调研和访谈。
原来，因为当地经济情况和技术水平都较落后，二维码对当地人来说十分陌生，人们很难下决定通过这样陌生又迅速的行为去执行付款操作。用户对二维码表现出的强烈不安全、不信任感直接影响了用户放弃成单付费。
相反，输入数字串（俗称PIN码）虽然流程相对繁琐，但对于付款这种慎重的行为，恰好留足了时间做思考和决定。
与此相似的案例在国内产品上我又碰到了一次，这次是开设房间时需要对房间设置权限，起初我们的版本是作为选择项，用户开房时可以选择所有人可加入或者只有朋友能加入。
有一次，我们觉得这样的设计似乎有些繁琐，只需要一个权限开关就可以了，打开开关就是仅朋友能加入，关闭开关就是所有人都可以加入（这层含义较隐晦，需要用户额外去思考和理解），我们又一次自信满满地上线了，结果又一次与预期背道而驰。
第一个例子与第二个例子有一个相似之处，是对用户来说，这都是一个“谨慎的操作”，对于“谨慎的操作”，传统理论上那些「体验好」的方法（更快一点，更简单一点）不太受用，这些「体验好」的设计仅仅只是从行动上帮用户减少了一两步，却没办法帮助用户减少执行行动前的思考。
举个例子，你本来需要亲自开飞机空投炸弹，优化到你只需要按一个按钮就可以发射炸弹，对你投炸弹这个行为的影响大吗？不大，因为「要不要投炸弹」在行动前的思考远远复杂于「投炸弹」这个行为。
反而可能因为我们有时间在飞机上了解清楚“炸弹”，而没办法在按钮上对“炸弹”有理解，而导致面对着按钮犹犹豫豫，最终放弃。对于复杂且谨慎的行为，设计清楚（帮助用户在思考节省时间）远比设计简单（行动简单了但思考不会简单）来得更重要。
03 体验不好，数据好
- “我在这里放个按钮/入口！”
- “这里不符合使用场景呀”
- “我知道，但这里流量大（os：我需要流量把我的功能戴起来）”
- “按钮/入口要设计得大一点，再大一点，颜色要鲜艳的，最好是大红色，能来点动效就更棒了”
不知道这样的对话大家熟不熟悉，我早期的职业生涯中经常能遇到这样的项目需求。但往往这样又大又红的设计还总能拿到很好的数据供人吹嘘，明明用过的人都觉得这样的设计体验很不好，为什么却在数据的驱使下越来越猖狂呢？
以上图的例子做展开，在这样的需求下，我们可能会被迫作出这样的设计：
上线后，项目负责人发了一封邮件：需求上线后「算命」功能使用pv/uv上涨显著，证明这是一个合理的需求，非常好的设计，我们要朝着这个方向持续优化！
但你真的觉得这是一个合理的需求、好的设计吗？
这就是典型的把数据当目标，以片面下结论的情况。
首先我们必须明确一点，做需求做设计都是为了更好的体验或服务新的产品阶段，数据只是辅助我们判断有没有达成目标的工具，切莫盲目服务数据。
其次，在做需求做设计的时候应有全局观。就以上述所举例子展开，需求的目标应该是在用户想算命的场景提供算命服务，如果我们判断消息页是用户想要算命的场景，那么我们上线后观测的数据除了算命功能的pv/uv，还需要补充退出率，以及顶部新增算命入口后，对聊天页的折损数据（聊天pv/uv，收发消息数……），把这些考虑进去我们很可能得到不一样的数据结论：
看完真实的复盘后，首先应该能判断消息页不是用户想算命的场景，此时如果你的产品策略不是把这个软件转型成算命软件，就可以下掉这里的入口了。
如果你正要转型算命软件，非常需要消息页来带量，那么你也能看出来在这里加入口对聊天体验的折损有多大，此时你就得思考一下，「带起来的量」值不值得聊天功能「折损的体验」？
如果不值得，你也可以开始考虑换种方式带量了；如果值得，那继续做大做强就没什么问题了，祝福这个产品成为算命一霸。
04 总结
项目上线后数据复盘与体验有差异是很常见的，包括但不限于上面所述案例表现出来的原因。
总之，还是要牢记数据是工具，不是目标，如果发现数据复盘结果与预期有不符，可以尝试：给用户分层，更细致化地分析用户行为；通过用户调研了解用户真正的使用场景和流程，真正帮用户解决难点而不是“伪体验好”；以及，用更全面的视角、结合更多信息来看待项目是否达成目标。
“数据说谎”的现象还有很多，将来再继续讨论。
给作者点赞，鼓励TA抓紧创作！
来源：http://www.woshipm.com/pd/5411043.html
本站部分图文来源于网络，如有侵权请联系删除。