谈谈产品与运营之
以前周鸿祎讲过很多次关于用户感知的话题。一个产品,不管你用了怎样的技术,怎样的实现架构,怎样的流程逻辑,最终表现给用户的,其实是用户感知,也许你做的很简单,但用户感知很饱满;也许你做的很复杂,但用户感知不足,这些都是产品运营中需要面对的问题。
当然,这个话题可能容易跑偏,好比如何通过诱导用户感知,让用户体验一些其实并不存在的技术。
一个灰色产业的例子是这样的,警告,你的电脑/手机中病毒了! 请立即下载查杀工具!
然后下载后显示已经检索了多少多少文件,查杀了多少多少病毒,然后要求驻留内存随时防护你的电脑/手机,那么你觉得这个东西好啊,你看其他软件都没报警,就它最可靠,于是保存手机自动启动,那么,它干嘛了呢?好像也没干啥坏事,就是做一点广告劫持,把你日常行为的浏览记录全部加个尾巴,把淘宝的流量卖给淘宝,百度的流量卖给百度,亚马逊的流量卖给亚马逊,偷偷从你身上赚了佣金,你还一无所知的以为这是个安适工具。
这是灰产里典型误导用户感知的案例。
周鸿祎也提过一个例子,就是 360 路由器的例子,你说你用了新技术,隐藏天线,也可以实现很好的信号传播,用户一看没天线,就觉得这个东西信号必定不行,然后去买四个天线的路由器去。所以不管用了什么技术,先装上四个天线,这是无条件顺从用户感知的案例。
我做线下技术产品沟通分享,包孕我上次网课,关于需求界限的话题,其中提到一个典型的案例,淘宝的搜索结果,你去翻页,你翻不过 100 页的,阿谁搜索结果的数字,无论淘宝,百度,还是谷歌,如果是很小的数字,是精确的;如果是个很大的数字,是估算出来的。那这个例子我举完,线下分享我就问过在场的童鞋,大家都逛过淘宝对分歧错误,谁知道淘宝不能翻超过 100 页的?每个人都逛过淘宝,我不讲出来,没人知道不能翻超过 100 页。
说明什么?用户对超过 100 页翻页需求是无感知的。用户对搜索结果数字估算是无感知的。当年我做CNZZ的时候,有几十万站长在使用,覆盖每天几十亿pageview,我对网站的来路信息,受访信息都没有做完整保存,都只保存了前 1000 条,没有一个站长为这个问题来投诉,或者提出质疑过,说明什么?不影响用户感知。
这就是为什么我提需求界限这个概念,不影响用户感知的情况下,可以做很多裁剪来节省技术成本。你看,大翻页是个连百度,谷歌,淘宝都解决不了的问题,并且也是个用户感知完全不影响的问题,这个例子足够明确了。
(多说一句,我做分享的时候发现,很多技术人员还不知道为什么大翻页是个效率上很难优化技术问题。我觉得这个也可以作为技术面试题了。)
产品研发经常容易陷入的两个极端误区
第一种是技术配景的创业者容易犯的错误,就是技术架构是咋样,产品就长成啥样。我的技术结构和数据结构是这样这样的,所以我页面的功能就是这样这样的。
前段时间我就批评我们团队的办理后台,我说做的根本不是办理者应该看到的,完全就是数据结构的映射,我说你直接给我一个phpmyadmin就好了,你都不消开发了。
第二种是一些技术入门级的公司容易犯的错误,就是产品目标是啥样,技术架构就啥样。 因为我要做功能a,b,c,d,e,所以我的代码和数据结构就完全忠实的根据这个功能设计来写。
这是啥问题呢?没有考虑复用性,耦合性,对扩展性没概念,对可能的需求变换没概念,对业务发展和运营没概念。前期做好看上去还行,后面想做个活动,想搞个新特性,啥都要重新来弄。
这个话题可能扯的有点远,但是这就是所谓架构师的作用和意义。
产品经理的目标,就是用户感知,我要的功能,特性,用户预期是什么,用户的交互反馈是什么,前面的东西,必需紧密围绕用户感知来做,不能说技术架构长啥样,我就做成啥样,当然,有些事情可以沟通,怎么沟通,在尽可能满足用户感知的情况下,如何降低技术成本,提高研发效率,这是可以沟通协商的。
而技术架构的工作就是,在尽可能满足用户感知的前提下,有效降低技术成本,以及提高对未来业务和运营的兼容性,当然,这两者可能有一点冲突,但并不是完全冲突。
所以一个界面视图里,可能存在多个技术结构的杂糅,或者同一个数据结构里的内容可能会按照条件差别,表现在差别角色的差别场景里,这都不是问题,产品架构和技术架构,自己不存在一定的关联。最典型的是搜索引擎,一个搜索框,后面是极为复杂和庞大的技术架构,,但给用户的感知是非常简单和明确的。你想要的是什么,我如何尽可能达到你的预期。
那么,很多创业者,也在寻求,如何用低成本满足用户感知。说白了,很多就是“让用户以为”。