|
|
以前周鸿祎讲过很多次关于用户感知的话题。一个产品，不管你用了怎样的技术，怎样的实现架构，怎样的流程逻辑，最终体现给用户的，其实是用户感知。也许你做的很简单，但用户感知很饱满。也许你做的很复杂，但用户感知不足，这些都是产品运营中需要面对的问题。
当然，这个话题可能容易跑偏，比如如何通过诱导用户感知，让用户体验一些其实并不存在的技术。
一个灰色产业的例子是这样的：警告!你的电脑/手机中病毒了! 请立即下载查杀工具!
然后下载后显示已经检索了多少文件，查杀了多少病毒，要求驻留内存随时防护你的电脑/手机。
那么你觉得这个东西好啊，你看其他软件都没报警，就它最可靠。于是保留手机自动启动，它干嘛了呢?好像也没干啥坏事，就是做一点广告劫持，把你日常行为的浏览记录全部加个尾巴，把淘宝的流量卖给淘宝，百度的流量卖给百度，亚马逊的流量卖给亚马逊，偷偷从你身上赚了佣金，你还一无所知，以为这是个安全工具。
这是灰产里典型误导用户感知的案例。
周鸿祎也提过一个例子，就是360路由器。你说你用了新技术，隐藏天线，也可以实现很好的信号传播。用户一看没天线，就觉得这个东西信号肯定不行，然后去买四个天线的路由器去。所以不管用了什么技术，先装上四个天线，这是无条件顺从用户感知的案例。
我做线下技术产品沟通分享，关于需求边界的话题，其中提到一个典型的案例：淘宝的搜索结果，你去翻页，你翻不过100页的。那个搜索结果的数字，无论淘宝、百度，还是谷歌，如果是很小的数字，是精确的;如果是个很大的数字，是估算出来的。
那这个例子我举完，线下分享我就问过在场的童鞋，大家都逛过淘宝对不对，谁知道淘宝不能翻超过100页的?每个人都逛过淘宝，我不讲出来，没人知道不能翻超过100页。
说明什么?用户对超过100页翻页需求是无感知的，用户对搜索结果数字估算是无感知的。当年我做CNZZ的时候，有几十万站长在使用，覆盖每天几十亿pageview。我对网站的来路信息、受访信息都没有做完整保留，都只保留了前1000条，没有一个站长为这个问题来投诉，或者提出质疑过，说明什么?不影响用户感知。
这就是为什么我提需求边界这个概念，不影响用户感知的情况下，可以做很多裁剪来节省技术成本。你看，大翻页是个连百度、谷歌、淘宝都解决不了的问题，而且也是个用户感知完全不受影响的问题，这个例子足够明确了。
(多说一句，我做分享的时候发现，很多技术人员还不知道为什么大翻页是个效率上很难优化的技术问题。我觉得这个也可以作为技术面试题了。)
产品研发经常容易陷入的两个极端误区：
第一种是技术背景创业者容易犯的错误，就是技术架构是咋样，产品就长成啥样。我的技术结构和数据结构是这样的，所以我页面的功能就是这样的。
前段时间我就批评我们团队的管理后台，我说做的根本不是管理者应该看到的，完全就是数据结构的映射，我说你直接给我一个phpMyAdmin就好了，你都不用开发了。
第二种是一些技术入门级的公司容易犯的错误，就是产品目标是啥样，技术架构就啥样。 因为我要做各种功能，所以我的代码和数据结构就完全忠实地按照这个功能设计来写。
这是啥问题呢?没有考虑复用性、耦合性，对扩展性没概念，对可能的需求变更没概念，对业务发展和运营没概念。前期做好，看上去还行，后面想做个活动，想搞个新特性，啥都要重新来弄。
这个话题可能扯得有点远，但是这就是所谓架构师的作用和意义。
产品经理的目标，就是用户感知。我要的功能、特性，用户预期是什么，用户的交互反馈是什么，前面的东西，必须紧密围绕用户感知来做，不能说技术架构长啥样，我就做成啥样。当然，有些事情可以沟通。在尽可能满足用户感知的情况下，如何降低技术成本，提高研发效率，这是可以沟通协商的。
而技术架构的工作，就是在尽可能满足用户感知的前提下，有效降低技术成本，以及提高对未来业务和运营的兼容性。当然，这两者可能有一点冲突，但并不是完全冲突。
所以一个界面视图里，可能存在多个技术结构的杂糅，或者同一个数据结构里的内容可能会根据条件不同，体现在不同角色的不同场景里。这都不是问题，产品架构和技术架构，本身不存在必然的关联。最典型的是搜索引擎，一个搜索框，后面是极为复杂和庞大的技术架构，但给用户的感知是非常简单和明确的——你想要的是什么，我如何尽可能达到你的预期。
那么，很多创业者也在寻求，如何用低成本满足用户感知。说白了，做法就是“让用户以为”。
以前被用烂的招，很多美女马甲不断地在社交网络里活跃，其实是机器人。更早没有机器人的时候，就是男生在里面操作，不说别人，当年马化腾为了OICQ的活跃，自己不也干过这事么。
现在很多约炮平台不还是用这招骗钱么，而且居然很有用。前段时间我看到网上几篇爆料文，我知道这东西有人赚钱，但真没想到居然还有这么多人会受骗。
另一种是游戏里，比如棋牌或其他游戏，也会存在一些机器人。在用户活跃度不高的情况下，满足玩家对战的需求，但有些机器人太傻，很容易被玩家看穿。
说个成功案例，当时贪吃蛇大作战刚开始是没有联机版的，但是大部分玩家都以为自己是跟联机的人作战。而且比联机的效果还好，因为不卡啊。
低成本满足用户感知，有些东西确实不太好，比如误导用户相信一些不正确的东西，或者让用户为“看上去价值很高，而实际上价值很低”的东西付出更高的成本。
但有些娱乐的场景，其实也算不上多大罪过。比如游戏里，用数值PK来模拟实时PK，技术成本低，效果做得足够好，满足玩家的诉求也没什么不好的(当然，一些深度玩家肯定会发现这个问题，并追寻更好的产品，但浅度玩家市场也是存在的哦)。
另外能正确理解用户感知的边界，也就是需求边界，可以节省很多无用功，这个就不赘述了。
用户感知和用户预期，在某些场景可能是一回事，某些场景可能会有一些区别。用户在有些场景是无预期的，这时候他感知的是什么?咬文嚼字的事情就不多说了，希望以上的案例和概念能帮助产品、运营人员更好地设计产品，以及与研发更有效率地沟通。
|
|
发表于 2017-11-6 00:14:32