滴滴打车查看车进程为什么一定要是地图?
叫到车以后,我们往往通过查看地图的方式来了解车行进状态,但是地图表达进程的方式带来的往往有以下可能的几种不适感,1.耗费流量2.需要不断去看地图,放大,拖动3.(心理暗示)位置不准确4.等车过程心理被车从开始到到达一直牵制着。可不可以新增一种颜色进程的方式来让用户减轻负重感。比如刚开始的浅绿色慢慢渐变到黄色再到竖红线表示的车到达。
这个题目是个好题目,但是题主的顾虑跟建议我不是很认可。先来分析题主的几个顾虑:
1、耗费流量;
2、需要不断去看地图,放大,拖动;
3、(心理暗示)位置不准确;
4、等车过程心理被车从开始到到达一直牵制着;
滴滴的用户数很大,根据TrustData发布的数据表明,2016年第四季度滴滴的月活(MAU)为3723万,在这3723万的用户中,肯定会有人会像题主说到的问题描述中有顾虑。
引用楼上的话,用户规模大,所遇到的问题也会有各式各样,包括题主的四个顾虑。下面是本人的题主顾虑的分析以及拙见:
1、耗费流量: 测试发现,滴滴会把首次打开的地图缓存在手机里,所以首次打开会消耗较多流量加载地图,后续不会。耗费流量主要是滴滴需要流量跟gps双重定位司机和乘客的位置,形成实时信息。这一层面上其实消耗的流量也不会很多,由于市面上没有人去统计这个,所以没有明确的数据可以说明,我以自身为例子,作为一个没钱买车但是想舒适出行的屌丝,我外出都会选择滴滴,我所能查到的订单详情是从17年的2月份到现在一共三个月的时间,共产生54条订单,即在这三个月时间内我使用了54次滴滴出行,共耗费268M,我们估算个每次出行耗费流量:268/54=4.96M,即从开始叫车到司机接单到到达目的地这一整个流程,我会耗费4.9M的流量。
假设我每月(30天)需出行60次(即上下班,每天两次),那么我每月需在滴滴出行上耗费流量:4.96*60=297.6M。这个对于现在的C端用户持有流量来说是完全可以接受的。还是以我自身为例子,我是电信的校园卡(毕业一年多了依然恬不知耻地用着校园卡),每月流量5G(包含上月结存),用不完继续结存。
当然不可能每个人都会有这么多的流量,但是基于现在三大运营商的提供的流量越来越多且越来越便宜,每个月300M不会在意太多(何况不会真的有人那么土豪上下班都坐滴滴吧...)。
2、需要不断去看地图,放大,拖动: 这个其实问题也不大,滴滴对于司机以及乘客的匹配机制应该是有限定距离,限定距离内(假定3公里以内)在等车过程中看地图需要放大、拖动的次数不会频繁,大部分都是可以直接在地图可视范围内看到车辆的行动,且车辆上方会有距离多少公里可以参考车辆里乘客还有多远。另外除非强迫症或者贼无聊,不然不会不停盯着地图看吧...
3、位置不准确: 可能是定位偏差性导致的心理感觉位置不准确,在周围没有显著建筑的情况下,比如定位成(xx路xx号),是会造成这种心理。这点应该从地图定位上做优化,感觉与题关系不大。
4、等车过程心理被车从开始到到达一直牵制着: 这个楼上的大神也提到了,哪怕做出了与题主所说的调整,该盯着的乘客还是一如既往地会盯着,他不会因为展现的形式不一样了就不盯了。
我个人觉得题主提出的几个顾虑其实都是小众问题,会出现这种问题的人不多。不足为虑。
回到主题:
滴滴打车查看车进程为什么一定要是地图?
我体验过滴滴的拼车功能,感受过司机端是如何进行接单-接客-结单这个流程,我觉得在司机端这点做得很好,司机在接单后无须手动做多余的操作,接单时司机端APP会有语音播报功能,司机点前往后地图有语音播报功能,乘客上车后司机右滑表示接到乘客开始计费并前往目的地,这是地图导航继续语音播报,到达目的地后右滑到达目的地,账单发到乘客端上,形成闭环。这一整个流程里面,语音播报功能是最突出的,它解决了司机开车途中无法过多看手机的问题。那么我们方向思考一下,如果语音播报功能在乘客端呈现会是怎么样的呢?
假设场景:小明跟小红在某广场门口叫了一辆滴滴快车,在确认有司机接单后,他们开始聊天,没有去看车辆的方位到哪了,聊了三分钟后听到手机播报一则语音:您好,您呼叫的车辆(车牌号:粤S xxxxx)距离您还有100米,请注意来往车辆。他们停止专注聊天,在看来往车辆的车牌号,不一会儿,他们就找到了他们呼叫的快车并上车,愉快地回家了。
我觉得查看车过程用地图是没毛病的,这是最直观的,而且我觉得滴滴的查看车进程做的体验做得不错,因此我更倾向于在此基础上,对其进行惊喜型需求的挖掘。以上是本人的一点拙见,欢迎各位大牛交流指导。
文/蔡欣潮 B/C端pm 程序猿安抚师
关键字:产品经理, 产品设计, 地图
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!