技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> 用户研究 --> 情景反射陷阱

情景反射陷阱

浏览:1700次  出处信息
情景这个词,很多人称之为场景,都是一个意思。我喜欢用“情景”,是因为场景的语感更偏重环境描述,而情景则附带有该环境下的直观感受这层意思。

    最近一年,我带的几个项目有得有失,大都踩到了同一颗地雷,即“情景反射陷阱”。这枚生造词的意思是,当用户接触到产品的时候印象尚可,但一旦关闭窗口,就很难想到再回来使用,缺乏刺激用户“再去用那款产品”的条件反射情景。

    原因有二。

    首先,用户对产品的印象还不够深刻,容易遗忘。有可能是需求的原因,也有可能是产品魅力不足的原因。

    其次,使用户产生回访冲动的情景,其触发频度太低,从接触产品到触发情景的间隔太长,已经淡忘了这款产品的存在。

    拿摄影做例子。来我们的摄影社区浏览的用户大都觉得不错,尤其在摄影作品的展示上水准不俗。只是关闭窗口后,什么样的情景才能触发用户的回访冲动,打开浏览器回到摄影社区呢?很难。“浏览摄影作品”对大多数人并非强需求,摆在眼前就看呗,看不到也没有遗憾。而对于摄影爱好者来说,更在意的是人和人之间的互动要素,仅仅展示的话,已有太多习惯使用的替代品,未必非此不可。

    因此,在缺乏外部推广位的前提下,仅有漂亮的展示效果并不能托起社区的成功。在这里“外部推广位”就是触发大众脸用户回访的情景,触发摄影爱好者回访的情景则是,我发的片子有谁来评论?我关注的牛人(小镇)最近有什么好片?社区里又出现了什么热门话题?此时公共展示页无足轻重,人与人之间的关系与交流成为了用户焦点。

    再说说爱拍。从单一城市入驻商家的数量、质量和展示效果来说,爱拍都是天津的NO.1,甚至是全国的NO.1。但我遭遇的问题是,结婚是一个非常低频度的用户行为。推广导入爱拍的用户群,他们正准备结婚,正打算拍婚纱照的概率不高于0.5%,随便看两眼当然就走掉了。等到需求冒出来的时候,已经相隔了很久的时间,还能记起来爱拍吗?很难,他们多半直接Baidu去了。所以公司推广渠道的转化效果比本地化社区弱很多,流量优势完全发挥不出来。

    同样的情景也发生在这个领域的成功者身上,但成功者的优势是,结婚资讯完美融合进了本地化社区。常泡论坛的用户更容易接触到、并且牢牢记住篱笆还有个结婚频道,19楼还有婚姻课,天津百丽吧还有婚嫁栏目。当他们出现需求的时候,很顺畅地从自己常泡的一个社区版面跳到另一个版面,从而避开了我的困境――品牌记忆模糊,回访路径断裂。后来我改变了战法,通过一些方式精准锁定近期有消费意向的用户群,定期发“本季精选促销活动”的邮件过去,把打折信息作为触发回访的情景。但这令运营模式愈发复杂,太复杂了终归不是好事。

    以上两个亲身经历的例子,说明“条件反射情景”是产品模型中非常重要的一个环节,甚至与“用户需求”等量身齐。产品必须能满足用户需求,用户在产生需求的时候还得想起来这款产品,二者缺一不可。

    2008年的时候,我带的部门设计化妆品库改版,女人频道提出,希望能把单纯的化妆品资料库升级为点评社区――以UrCosme作为样例。我观察了一下,发现一个很朴实的道理,即女人换化妆品的频度很低,单件购买周期平均在3-6个月,因此大部分用户对“点评社区”的参与频度是不高的。几个月用一次的点评产品,完全谈不上社区黏性,又没什么值得炫耀的心得发现,便难以保障内容产出的数量与质量。UrCosme为此用了大量的产品设计技巧来增强感染力,其成本是“女人频道化妆品库”这个级别的项目支付不了的,最终只能和女人论坛美容版联动来弥补。

    另一个类似的例子是旅游社区――旅游是门大生意,可中国没一个成功的旅游社区。我猜,原因就是踏中了“情景反射陷阱”。爱旅游的人虽多,但愿意长期泡某个旅游产品的人却很少,通常只是在计划旅游的时候过去找找资料。而这个“计划旅游”的间隔,一年最多两三次,意味着旅游产品更像是一个偶尔访问的工具箱、资料库,很难沉淀忠诚用户。可缺少忠诚用户的内容产出,流动用户又是为何而来呢?

    苦也。

    在旅游产品中,我关注的是两款:穷游网与蚂蜂窝。穷游的特色是境外游咨询,蚂蜂的特色是路书下载。它们的条件反射情景很相似,“查找旅游实用资讯”,以此满足流动用户的强需求,再引导其中一小部分人留下有价值的内容。其运营思路和更成功的大众点评网基本一致,区别在于找馆子吃饭的频度比旅游高,提升了回访、发表与互动的黏性,流量更大内容更丰富,自然风生水起。

    想明白了这个道理,以后开新项目会少吃很多的亏。

    前些日子,我想做一款“记录梦”的APP(私人性质),问@师母 的意见。师母表示反对,理由是一个人值得记录的梦是很少的。早上起床迷迷糊糊,还得立刻拿起手机,打开APP把梦记下来,否则洗把脸估计就忘光了。结果下载APP以后,可能隔半个月才能触发一次回访情景,这时多半已经忘掉了它的存在。我一听觉得有道理,遂打消此念。

    对于快速拿起快速放下的APP来说,半个月不使用,几乎已经判了它的死刑。除非被特殊情景下的强需求触发,比如翻译或手电,又或者“爱说话的汤姆猫”――我每次遇到亲戚家的小孩子都会拿出来逗他们,反而不压箱底。但“记录梦”看上去并不是这样的强需求(对大多数人来说)。故而做下一个APP的时候,我时刻都在问自己,用户在怎样的情景下有可能产生使用需求?出现这种情景的频度是多少?情景发生时用户是否容易想到这款应用?建立相应的条件反射,比单纯的发现需求满足需求更加微妙。

    水手辛巴德,这是你需要重视的问题。

建议继续学习:

  1. JavaScript性能陷阱    (阅读:3139)
  2. Java陷阱(2010版)    (阅读:3194)
  3. PHP数据类型隐性转换的陷阱    (阅读:2951)
  4. 移动互联网系统架构十大陷阱    (阅读:2762)
  5. 类型转换-无处不在的陷阱    (阅读:2244)
  6. cPickle序列化自定义类实例时的陷阱    (阅读:1728)
  7. JavaScript 中的陷阱    (阅读:1818)
  8. 可能被你忽略的 JavaScript 代码陷阱    (阅读:1712)
  9. 情景依赖性    (阅读:1503)
QQ技术交流群:445447336,欢迎加入!
扫一扫订阅我的微信号:IT技术博客大学习
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1