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

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

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

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

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

2.1打车软件解决的问题

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

打车软件的出现给乘客带来的改变体现在用户使用出租车的流程上，流程比较如下：

从中可以看出来，使用打车软件使用的过程中，解决了两大问题：

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

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

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

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

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

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

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

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

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

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

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

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

三、产品界面分析（专车功能界面不分析）

3.1  app主要界面分析

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

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

用户点击通过调整自己的标记点更改打车的起点，打车的重点通过输入地址解决，并且在输入栏下方增加了两个用户会经常使用地点（家、公司），非常贴心的细节设计。

当用户输入地址后，会在地图上标识进行再次确认，后通过输入一些细节上的内容提升用户感知，点击确认发送收集信息，貌似是在这个时候用户才知道自己的请求有多少司机会接收到，司机响应后，通过电话联系，确认信息。手机上使用的内容告一段落。

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

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

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

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

总的说来，微信公众号是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端，如果对于时效性的要求不是很高，则这样的方式是要比快递更加快捷的（现快递行业的同城快递服务的速度可以做到一天内，有些需要两天才能完成）。

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

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