一个产品新人如何评价滴滴打车

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

一、出租车及打车应用行业历史背景

出租车行业最早出现的时候,由于车辆较少,经营基本上以电话预定或登门预约为主,人们的对出租车的使用习惯,最早也建立在这样一种“预约—等待—出行”的模式中。然而随着城市扩张和汽车工业的发展,出租车越来越多,电话预约已经不合时宜,人们开始尝试在路边招手叫车,出租车司机为了招揽更多生意,也开始上街“找活”——于是,这种新的用户习惯和商业模式建立起来,并基本上延续到了今天。

由于移动互联网的兴起,O2O发展模式逐渐受到关注,在出租车行业的应用便出现了更加便捷的方式:通过预约叫车的方式解决大城市出现的打车效率问题

世界上最早的一家出租车服务公司是美国的Uber,公司创立初期的目标是“只需按下手机按键便会出现一辆轿车”模式。后因美国运营部门以没有相关出租车公司执照为名处以20000美元罚款,才最后出现了展现在大众面前的Uber,专注于中高端租车市场,愿景为“做每个人的私人司机”。后这种模式引入到中国,专车模式改为出租车模式,第一家公司为摇摇招车,后来随着滴滴打车、快的打车的加入引爆市场,解决了一些现有的难题,同时也带来了新的挑战。此文章分析现有的打车应用流程并通过对行业模式进行分析,以做出对滴滴打车app及微信公众号的改进建议。

二、打车软件解决的问题及流程分析

2.1打车软件解决的问题

在打车软件出现之前,出租车行业,尤其是一线城市,存在了如下几个问题,分两大类说明:
123
打车软件解决了以上提到的问题,这是移动互联网发展对现在生活的改变,新的服务业方式也给用户的使用流程带来了改变,不过凡是改变必有正反两个方向,通过分析业务流程可以略见一二。

2.2乘客使用流程分析

打车软件的出现给乘客带来的改变体现在用户使用出租车的流程上,流程比较如下:
11
从中可以看出来,使用打车软件使用的过程中,解决了两大问题:

l用户侧的打车难与保证打车时效性

l出租车司机侧的招客效率与出租车的运营效率

同时还引入了新的方式如:出租车司机的评分系统、通过增加服务费吸引司机抢单、使用手机付款。

但是,由于新的方式仍在摸索过程中,有些具体问题仍然没有考虑进去:

1、  有的乘客因为居住偏远,使用了打车软件后拒单率极高,换言之出租车司机选择乘客的权利更大,在这一点上的用户感知很差;

2、  由于市场竞争激烈,打车软件使用语音增加一些附加条件时收到限制,如在夏天有些乘客不喜欢没有空调的出租车,但是出租车司机决定是否接单,所以乘客选择出租车的权利下降;

3、  用户使用场景的不明确,如在响应后,出租车司机可能会在相对较长的时间才能接到乘客,导致用户感知下降;

现在在大部分用户使用打车软件的同时,市场上也有着各种层出不同的负面反馈。通过分析流程可以总结出,打车软件是提升了乘客打车时候的交互体验,没有对现有状况进行改善,原有的方式是在大街上挥手,有些司机会看不到,通过新型方式,用户发出的打车请求更加容易被识别到。这一点交互的突破让用户忽略了很多问题:

1、   在发出打车请求后存在两个问题,一是司机选择是否接收乘客的权利更大,在原来的出租车行业的问题如太近或太远的乘客拒载、遇到有些堵车的地方拒载,这样的问题不但没解决,却更加激化了矛盾。二是出租车司机响应后接到乘客的时间不可控,不是一个令乘客有安全感的因素,有些出租车司机可能是搭乘乘客时接了单,所以要过一段很长的时间才能接到下次叫车的乘客。

2、   从某种意义上说,打车软件是增强了司机的安全感而非是乘客的安全感。举例说明,当乘客发出请求后,虽然有很多出租车司机可以接收到消息,但是当一位司机“抢单”成功后,乘客只能默默等待着出租车司机,如果选择取消则会影响乘客的信誉度。再包括到上面说到的司机选择乘客的权利变得更大,脱离了服务业的本质。如果没有更好的流程改进如此不平衡的关系,打车软件的用户体验会下降很快。

3、   乘车费用也可能成为一个新的争议点。据朋友反馈,在偏远地段打车后,出租车司机就不会打表,而是通过报出一个更高价格的方式让乘客选择是否乘车,行业的监管又是另外的一大问题。

以上是由于范围层引发的问题,流程的优化将会在第四部分进行分析并加以解决。

三、产品界面分析(专车功能界面不分析)

3.1  app主要界面分析

因为是工具型app,所以产品设置肯定要围绕它的具体使用场景设计其界面,所以,点击app进入首页中即看到使用者附近出租车数量情况,这表示了使用滴滴打车司机版的出租车有多少在我的周围。非常直观的显示,用户会直接感受到自己如果发出打车请求后会有多少出租车相应、大概多久会打到车。

这也暴露了一个产品设计上投机取巧的点:显示的是出租车的数量,而不是空车数量,用一个错误的表达方式来引发良好的用户体验,虽然大多数用户不会考虑到这样的逻辑,但是在产品设计的严谨性的角度上来说,这是个值得商榷的问题。

用户点击通过调整自己的标记点更改打车的起点,打车的重点通过输入地址解决,并且在输入栏下方增加了两个用户会经常使用地点(家、公司),非常贴心的细节设计。
2
当用户输入地址后,会在地图上标识进行再次确认,后通过输入一些细节上的内容提升用户感知,点击确认发送收集信息,貌似是在这个时候用户才知道自己的请求有多少司机会接收到,司机响应后,通过电话联系,确认信息。手机上使用的内容告一段落。
33

在到达目的地后,可以通过微信支付或者现金付款的方式进行付款,这里不再赘述。以上完成了一个完整的打车流程。

3.2 微信公众号打车界面分析

微信公众号的变化在于使用环境的变化。App是独立封装的,而微信公众号的打的是通过H5来实现的,造成了设计上的些许不同。首先说明,在公众号中输入打车的起点终点不会受理打车请求,而是提供滴滴打车的下载链接,这个的逻辑设计上很绕弯,不过可能是现在最合适的解决方案了吧。

好吧,那点击进入我要打车界面,同app首页一样,不过这次是以数字的方式显示附近有多少出租车,输入目的地后(H5页面没有更多信息的填写界面),点击叫出租车,以广播形式告知以通知的出租车数量。

4

5
总的说来,微信公众号是app的简化版,取消了app的地图显示及“愿等”和“捎话”功能,保留了滴滴打车的最基本功能,可以在用户没有下载滴滴打车时的一个体验版进行试用。在微信的平台上做这样一个产品可以有很好的宣传和推广方式。

3.3 滴滴打车司机界面浅析

因为在打车打的时候看到过界面,而没有进行下载,只能总结在其中出现的问题:

1、乘客的打车请求是时刻发送的,在司机等待请求和已经载客的情况下都有。在后者的使用场景中体现出来其中的弊端,一是时刻有令乘客恼人的声音同时会影响司机的注意力,二是司机可能在载客途中进行响应请求,会增加司机的驾驶安全隐患;

2、接到乘客后,没有任何状态的更改。现在的滴滴打车司机版只是个接收广播的工具,在功能性上设计的还不够全面。

四、产品优化及滴滴打车产品规划建议

4.1产品优化方案

如果要提高用户的使用体验,则需要先从司机版使用场景进行管理,和app上的功能进行改进。先讨论司机版app的改进方案。

  1. 多个司机可以响应一个乘客的打车请求,要求在限定时间内乘客进行选择。这样会增强乘客的选择性,而不是司机主动选择,同时保证乘客有多个备选方案。
  2. 类似于Uber,在接到乘客后,界面上增加接到客人的按钮,改变司机车辆的行驶状态,这样在乘客侧的app上会更直观的显示出附近有多少出租车可坐,而不是没有意义的图片和数字。
  3. 在司机接到客人后,车辆的状态发生改变,只能接收到预约出租车的信息,不能接受实时打车请求广播,在保证了司机接客的连续性的同时,也保证了不会在驾驶过程中的令乘客恼人的广播。
  4. 驾驶过程中,手机app记录行车路线,并且按着当地的计费原则记录行车费用,这样会确保在出租车费用的可靠性,加强监管力度。费用计算完成后,数据发送到乘客的手机上,进行支付,减少支付步骤,缩短了付款的时间。如果是现金付款的话,则没有任何改变。

总结以上内容,在乘客侧得到优化的方面有如下:

1、首页显示空车数量;

2、多个司机可以响应打车请求,但是乘客需要在限定时间内进行选择,否则选择默认选项;

3、乘车过程被记录,费用同样计算,不会产生付款的纠纷;

4、付款界面会自动接收到需要付款的金额,简化了付款流程;

以上内容是在app侧可进行改进的部分,因为微信公众号是内容简化版,则在产品的规划上没有必要增加过多功能,我认为最需要的一个功能是增加文字和语音的自动识别功能。微信公众号通过识别用户发出的文字或语音判断乘客的起点终点,在识别后,跳转到H5界面,进行打车流程操作,这是现有技术可以改进的方面,生硬的提供下载链接怎么样都不美观。

补充一点:当初在市场的推广上,也可能是因为首先要强推到司机端,所以会有些倾向于司机的设计,但是在用户数量上升后,有些资源必定要向乘客倾斜,才能做到用户体验出色。

4.2 滴滴打车产品线规划

现在打车软件的利润来源仍然不明朗,所以只能在提供体验更好的专车服务中进行高价值服务,与租赁公司的利益分配。

其实,由于车辆的机动性,可以做出功能规划可能会有更多,参考uber的发展模式:Uber正在尝试加入配送服务,曾在情人节尝试配送玫瑰花、在33座城市与冰淇淋卡车合作配送甜点和烧烤,2013年10月,部分美国客户甚至可以要求Uber的工作人员把小猫带到自己的办公室或者家里。今年圣诞期间甚至可以配送圣诞树。Uber首席执行官Travis Kalanick表示,他希望Uber能够超越出租车业务,发展成为一个城市的物流公司。

在此仅作一个生活服务的简单分析。现在可能会有更多同城服务的需求,在现在O2O服务的热度上,很多同城服务可以依托出租车,这样一个低成本的方式进行服务。

以同城快递举例,如果某用户有个同城快递需求,此需求的场景为需要快递物品在半天内的时间送到城市的另一端,因为如果自己送过去会耽误来回的时间,但紧急度又没有那么高。用户在某个页面提供一个同城快递的需求,某个出租车司机进行响应,同时将交易记录同步到某个平台进行确认,同时计算出需要的费用,在不占用出租车使用空间的同时还可以进行快递服务,当快递已经被确认接收后进行付款。这样的方式可以增加出租车的使用场景,让出租车司机有了更多收入。此方式同样也试用与O2O中的B端,如果对于时效性的要求不是很高,则这样的方式是要比快递更加快捷的(现快递行业的同城快递服务的速度可以做到一天内,有些需要两天才能完成)。

利用出租车在一个城市内的机动性,进行更多价值的实现,这也许会是一个很好的发展方向吧。

本文为作者张天埜投稿发布,转载请注明来源于人人都是产品并保留本文链接

您的赞赏,是对我创作的最大鼓励。
1人打赏

评论( 8

登录后参与评论
  1. 其实客户并不在在意附近有多少辆出租车,关键是有多少辆空车,有多少辆空车愿意来接乘客

    回复
  2. 请作者先搞清楚,谁是稀缺资源,在出租车里行业里司机是稀缺资源好嘛,司机的体验比乘客重要

    回复
    1. 回复

      司机体验比乘客重要?那按照你的思维,淘宝卖家比买家重要咯,那要买家评价体系干嘛?不建立在用户体验第一为前提的软件,都不会有发展空间。

    2. 回复

      司机和乘客都是用户吧

  3. 貌似上面有提到增加接到乘客按钮,以及跟踪付账。
    已点击“接到乘客”且没有完成付账的那么就是载人状态,仅接受预约;
    没有“接到乘客”车辆就为空

    回复
  4. 对建议不是很认同,我来说说我的个人看法:
    1.信息的展示:显示空车与所有车辆的侧重点不同,而且改进前后并不影响用户打车-等车-上车-下车的过程
    2.在等车的过程中,司机乘客都是爽单的可能,所以只增加乘客的权利对司机的体验是很不妥的,多个司机抢单会打消一些司机的积极性,乘客与司机的权利相当;
    3.打车费用使用定位,如果定位不准或路线不同,会增加乘客与司机冲突,而且对于技术层面也会增加开销,改进方向认可,但方案不认同。
    4.多次数据交换反而延长付费时间。

    回复
  5. 不错,愿景很好,只是有些点在实际中未必可行。如APP如何准确知道车辆空还是载人状态?

    回复
  6. 认同60%

    回复
加载中