zoukankan      html  css  js  c++  java
  • 移动用户体验到底该怎么做?一天推送N条消息只能叫骚扰

        来源:http://www.fortunechina.com/column/c/2015-07/13/content_243795.htm

       移动互联网时代真的来了。2015年上半年,天猫、京东的移动交易占比均超过了50%,唯品会则更加神奇的超过了80%,同时关于生活周边的移动应 用不断的涌现,在你能想象到的生活各个细分领域都有优秀的APP,我们的生活更加方便快捷和智能化,移动互联网真正改变了这个世界。而移动互联网的商业模 式设计核心就是用户体验,这是因为用户在手机上的使用习惯与PC上完全不同:用户在使用手机时方式是碎片化的,使用时间更短(一般不超过5分钟),使用频 次更高(一般每日达到几十次),如何设计用户体验就成了移动互联网项目的关键命题。

        什么是用户体验?好的用户体验只有一个检验标准,即是否用适合的方式解决了用户的痛点。这里我们重点要分析两个关键点:一是找到并解决用户的痛点,二是用适合的方式为用户解决。

        什么是用户痛点?是性价比更高的商品吗?并不是。任何价格的商品都有其对等价值,也即有其对应的用户群体,用性价比更好的商品可以获得更多的用户,但往往不能让用户满意。

        那么是更快速更便捷的服务方式吗?也不够。比如O2O送外卖,只是用A方式代替B方式,用户其实需要的不是更快更便捷的获得,而是要吃到更好的外卖,同时用户还损失了外出逛街的体验价值。

        用户的痛点是基于用户本身行为属性的提升,解决用户在生活中无法克服的问题。比如最近大家都在谈的Uber,在笔者看来,就是一个典型的能解决打车用户痛点的APP产品,它有以下几个特点:

        1. 价格认可;几天前北京晚上下很大的雨,我和朋友二人都被困在新中关购物中心,我用 Uber叫车,当时显示的是正常价格的2.7倍,我虽觉得稍贵,但由于晚上还约了别人,着急赶过去,就按这个价格叫了车。而我同学觉得再等等,可能等雨小 了,倍率会降低。但不巧的是之后雨越下越大,一直没有停,而我的同学最终以3.9倍的价格打车回了酒店。其定价是以用户的用车需求量来确定倍率价格,用价 格杠杆来满足不同急迫程度的用户需求,同时也使司机也获得更高的收入。

        2. 权益认可;在用户接受了其价格体系后,Uber会通过就近派单的形式(而不是抢单)让司机去服务用户,并且用户在下单的时候,无需指明目的地,就算是用户去附近1公里的地方,司机也不得拒绝,这个形式避免了司机拒载,保护了用户的打车权益。

        接下来我们再说什么是适合的方式?所谓的适合的方式是指,要恰好在用户的需求时点上为其提供所需的商品和服务,过早、过晚、过度高 频、过度低频都不是最适合的方式。这方面比较典型的案例是大姨吗APP,对此类APP来说,适合的方式是按月计算时间,在女性用户生理期为其提供所需的服 务,而这一切是基于对用户注册时所填入的信息进行分析计算的结果。但目前市面上众多APP的商业模式太急功近利,一方面是做不到也不想做基于用户的精准行 为分析,另一方面又希望用户能高频地甚至超高频地接受自己的服务,一天中能收到它们至少3条以上的推送消息。这种在营销和运营上都用力过猛的方式,会使消 费者从不断降低对其的好感度,所以就算这些APP的前端UI、交互、功能做的很好,用户也不会认为它是一个优秀的适合自己的APP。

        那么用户体验的精髓是什么?

        首先,它是定位于一个特定人群(而不是全部人群)的特定痛点的工具,既然是个工具,就应该具有被动属性而不是主动属性,当用户有需要的时点能够很好的被使用。

        其次,在你没有足够了解你的用户时,任何主动形式提供的信息都是过度的,都可能被视为骚扰,所以当你要发起一个营销活动或推送时,必需基于数据化的分析以契合用户的需求。

        移动互联网的本质,是让用户拥有更高的选择权,用户很容易使用一个新的应用,也更容易抛弃一个新的应用,移动互联网比拼的是用户体 验,是对用户的了解和对人性的洞查,这才是移动互联网之“道“,而其它的运营、营销、推广、转化、客服等都是在”道”层面下的“术”,用户体验的竞争,从 根本上说是在“道“这个层面上的竞争。最后再重复一次,对用户的了解和对人性的洞查,才是一个移动互联网项目是否真正拥有生命力的决定性因素。

  • 相关阅读:
    【转】编写高质量代码改善C#程序的157个建议——建议147:重构多个相关属性为一个类
    【转】编写高质量代码改善C#程序的157个建议——建议146:只对外公布必要的操作
    【转】编写高质量代码改善C#程序的157个建议——建议145:避免过长的方法和过长的类
    【转】编写高质量代码改善C#程序的157个建议——建议144:一个方法只做一件事
    【转】编写高质量代码改善C#程序的157个建议——建议143:方法抽象级别应在同一层次
    【转】编写高质量代码改善C#程序的157个建议——建议142:总是提供有意义的命名
    【转】编写高质量代码改善C#程序的157个建议——建议141:不知道该不该用大括号时,就用
    【转】编写高质量代码改善C#程序的157个建议——建议140:使用默认的访问修饰符
    【转】编写高质量代码改善C#程序的157个建议——建议139:事件处理器命名采用组合方式
    SpringMVC学习总结(六)——SpringMVC文件上传例子(2)
  • 原文地址:https://www.cnblogs.com/helloworld3/p/4650818.html
Copyright © 2011-2022 走看看