滴滴打车产品分析-罗文峰.pdf

第 1 页 滴滴打车产品分析 作者：罗文峰 邮件：simon.wf.luo 第 2 页 目录页 第 2 页 1 概要 2功能对比 3交互分析 4改进建议 分析目的 产品概况 分析结论 第 3 页 1 概要-分析目的 目的 了解熟悉打车应用的市场状况 分析主流打车应用的核心功能 分析主流打车应用的交互流程 针对滴滴打车，提出改进建议 第 4 页 目录页 第 4 页 1 概要 2功能对比 3交互分析 4改进建议 分析目的 产品概况 分析结论 第 5 页 1 概要-产品概况 滴滴打车 终端：IPhone 5 系统：IOS 7.1 App版本：3.0 产品定位 快捷、方便的打车应用。 乘客可以轻松发单，随时随地打车； 司机可以降低空驶率，轻轻松松多赚钱。 目标人群 有打车需求的智能手机用户； 出租车司机。 用户痛点 乘客：打车难； 司机：空驶率高。 核心需求 乘客：快捷、方便地打到车； 司机：接到合适的订单，避免空驶。 运营策略 免费叫车，不收调度费； 只与正规出租车/商务用车中介合作，乘车 体验与日常打车一致； 加价叫车，用车高峰期提高接单概率； 移动支付，方便用户交付车费，避免找零； 红包补贴，培养用户使用习惯。 竞争对手 打车应用：快的打车等 商用叫车：Uber、易到用车、一号专车等 租车：神州租车等 拼车：AA拼车等 代驾：e代驾、第一代驾等 电召台：各种官方背景的电召台 第 6 页 目录页 第 6 页 1 概要 2功能对比 3交互分析 4改进建议 分析目的 产品概况 分析结论 第 7 页 1 概要-结论 功能 打车应用的功能基本一致，同质化程度比较高。 滴滴的差异化是可以预定商务车型，扩展了产品的应用场景。 交互 整体流程简洁，车型切换方便快捷，内容布局合理、信息强弱得当。 一键叫车使用成本高。 乘客上车后的支付流程不够清晰，分支流程过多，容易造成用户移动支付的比例下降。 微信支付时没有留出口，会让部分用户进入死胡同，成本过高。 确认订单时，改动起终点比较困难，特别是终点无法改动，操作成本过高。 改进 【文字叫车】在地图上显示终点和车费 【文字叫车】搜索页suggestion和一键叫车 【支付方式】信用卡支付车费 【订单管理】已支付订单无需再出现支付button 【支付方式】弱化现金支付、强化微信支付 【文字叫车】允许用户修改终点 【微信支付】留出口，避免死胡同 【交互规范】不填写表单时button不可点击、更大的日期选择控件 【积分商城】增加积分商城，提供更多激励机制 第 8 页 目录页 第 8 页 1 概要 2功能对比 3交互分析 4改进建议 竞品选择 功能对照 模块分析 第 9 页 2 功能对比-竞品选择 打车应用市场占有率-双寡头 根据市场占有率，选择产品定位相似的【快的打车】和【滴滴打车】为主要 竞品，分析两者的异同，为滴滴打车的差异化提供建议。 *数据来源：艾媒咨询2014年上半年中国打车应用市场研究报告 第 10 页 目录页 第 10 页 1 概要 2功能对比 3交互分析 4改进建议 竞品选择 功能对照 模块分析 第 11 页 2 功能对比-功能对照 功能模块功能点快的打车滴滴打车 叫车 实时语音叫车有有 实时文字叫车有有 预约叫车有，支持预约2天有，支持预约3天 可选调度费用有有 留言交流支持给司机发语音消息支持文字留言（捎话），默认提 供最常用的7句话 POI历史记录有有 一键打车有，支持3个地点有，支持2个地点 POI收藏有无 商务专车无有 功能对照表 对比乘客版的滴滴打车和快的打车，暂不考虑司机版。 第 12 页 2 功能对比-功能对照 功能模块功能点快的打车滴滴打车 评价分享 服务打分 有有 文字点评 无有 投诉 有有 分享 有，朋友圈和新浪微博有，微信好友和朋友圈 订单管理 查看订单 有有 删除订单 无有 支付 有有 评价 有，24小时内可追加，超过24 小时默认好评 有，24小时内可追加 打电话 有，24小时内有，24小时内 投诉 无有 第 13 页 2 功能对比-功能对照 功能模块功能点快的打车滴滴打车 支付 第三方支付 有，支付宝有，微信支付 红包/代金券 有有 账户余额支付 无有 地图 显示出租车 有有 查看司机信息 无有 地图选择起点 有无 定位 有有 地图拖拉 有有 第 14 页 2 功能对比-功能对照 功能模块功能点快的打车滴滴打车 积分管理 兑换优惠券 有无 浏览优惠券 有无 账户等级 有，等级高则积分多无 其他 注册登录 有有 开发票 无有 应用推荐 有无 绑定常用地址 有有 通知朋友 有有 第 15 页 目录页 第 15 页 1 概要 2功能对比 3交互分析 4改进建议 竞品选择 功能对照 模块分析 第 16 页 2 功能对比-模块分析 叫车模块 车型-滴滴支持更多车型 快的打车：支持出租车。 滴滴打车：支持出租车和商务 专车。 总结：在用户端，滴滴支持更 多的车型，既有便宜快捷的出 租车，也有高端商务的多种车 型供用户选择，满足不同层次/ 不同收入用户的打车需求，同 时解决了新APP获取用户的难 题。 滴滴车型快的车型 第 17 页 2 功能对比-模块分析 叫车模块 叫车方式-平分秋色 快的打车：支持实时语音/文字 叫车，支持预约文字叫车。 滴滴打车：支持实时语音/文字 叫车，支持预约文字叫车。 总结：叫车方式上，都支持实 时和预约两种方式；实时叫车 的输入方式上，支持语音和文 字叫车，方便用户选择。 滴滴叫车快的叫车 第 18 页 2 功能对比-模块分析 叫车模块 抢单逻辑-滴滴更加公平有效 快的打车：订单根据离用户的距离下发，距离近的司机先收到订单 ；根据司机抢单的先后顺序，决定最终的订单归属。 滴滴打车：订单根据离用户的距离下发，距离近的司机先收到订单 ；抢单算法更加公平，第一个司机抢单后的N秒内，其他司机也可 以抢单，根据所有抢单司机距离用户的距离等参数决定最终的订单 归属。 总结：抢单逻辑上，滴滴更加公平：1）对司机，不需要再拼手机 、拼网速、拼手速，降低了司机的使用成本，提高调度效率；2） 对乘客，虽然接单时间延长，但接单司机距离更近，能更快地上车 ，比之前，整体等待时间缩短。 第 19 页 2 功能对比-模块分析 叫车模块 搜索功能-快的更好用 快的打车：支持历史记录、搜 索建议，支持对历史终点的收 藏。 滴滴打车：支持历史记录、搜 索建议。 总结：搜索功能，滴滴和快的 都不够好用，都有改进空间。 滴滴搜索快的搜索 第 20 页 滴滴评价 快的评价 2 功能对比-模块分析 评价分享模块 评价-滴滴的评价更全面 快的打车：支持赞和踩，只能在【我 未上车】里投诉。 滴滴打车：支持5分制打分，支持文字 点评；既可以在【我的订单】里投诉 司机，也可以在【未上车】里投诉。 总结：滴滴的评价方式更加全面，既 有打分也有文字点评，能帮住用户更 好地辨别司机的服务。滴滴的投诉功 能有两个入口：【我的订单】和【未 上车】，投诉更加方便。 第 21 页 2 功能对比-模块分析 评价分享模块 分享-各有特点 快的打车：支持分享到微博和 朋友圈。 滴滴打车：支持分享到微信好 友和朋友圈。 总结：因为两家运营策略不同 ，所以分享功能的使用情况也 不同。快的的分享更多是晒单 ，用户频次少动力低；滴滴的 分享更多是发红包，用户分享 的频次多动力高。 滴滴分享 第 22 页 2 功能对比-模块分析 订单管理模块 查看和编辑-滴滴功能更全 快的打车：支持查看订单。 滴滴打车：支持查看和删除订 单，会自动对订单分类（已完 成和未完成）。 总结：嘀嘀打车的订单管理功 能更加全面，不仅仅可以查看 ，而且可以删除订单。 快的订单管理滴滴订单管理 第 23 页 2 功能对比-模块分析 订单管理模块 订单内操作-平分秋色 快的打车：支持评价（24小时）、 分享、支付和打电话给司机（ 24 小时）;与打车流程中的支付页面 一致。 滴滴打车：支持评价、投诉、支付 和打电话给司机（ 24小时）。 总结：在订单内的操作，快的和滴 滴并没有太大差别；滴滴订单管理 中的支付功能，即使已经成功用微 信支付过车费，仍会出现且可以支 付，不够合理。 快的订单管理滴滴订单管理 第 24 页 2 功能对比-模块分析 支付模块 支付方式-平分秋色 快的打车：支付宝和现金支付 。 滴滴打车：微信支付和现金支 付。 总结：在支付方式上，快的和 滴滴都是采用第三方支付和现 金支付结合的方式。不过，在 支付流程上，快的对第三方支 付更加强调，对现金支付更加 弱化。 快的支付滴滴支付 第 25 页 2 功能对比-模块分析 地图模块 地图功能-快的更实用 快的打车：除支持拖拉、定位、查看地 图上的出租车位置外，还支持在地图上 选择起点。 滴滴打车：除支持拖拉、定位、查看地 图上的出租车位置外，还支持在地图上 看司机信息和评价。 总结：滴滴的查看地图上的司机信息， 对用户意义不大，在用户和司机间建立 连接之前，用户没有查看其信息和评价 的需求。快的打车的地图选择出发点功 能比较实用。 快的地图选点滴滴查看司机 第 26 页 2 功能对比-模块分析 激励体系 激励方式-快的更全面 快的打车：有积分功能，积分可以兑换 多种代金券。 滴滴打车：打车赠红包。 总结：快的打车的激励方式更加全面， 有积分体系作为支撑，可以兑换多种代 金券，老用户的奖励更加丰厚，目的是 提高老用户活跃度，与O2O结合扩展 打车应用的使用场景。滴滴打车的激励 体系主要是靠分享红包，主要目的是拉 新用户。 快的地图选点滴滴查看司机 第 27 页 2 功能对比-模块分析 总结 整体：打车应用的叫车、订单管理、评价分享等功能基本一致，同质化程度比较高 ，同时两家都在努力做差异化。 快的打车：差异化：积分商城，可以通过积分兑换多种代金券，甚至可以订酒店、 换电影票，结合O2O领域，扩展打车应用的使用场景。进一步发展，可以根据收集 的用户目的地数据，为用户推荐附近的宾馆、饭店、电影院等，产生更大的想象空 间。 滴滴打车：差异化：商务车型，可以在滴滴打车里预定豪华专车（快的是将同类业 务单独做APP），既满足不同层次用户的打车需求，提高打车成功率，同时又解决 了新APP获取用户的难题。未来，可以进一步抢夺商务用车的市场。 第 28 页 目录页 第 28 页 1 概要 2功能对比 3交互分析 4改进建议 主导航 主流程 第 29 页 3 交互分析-主导航 滴滴打车 左侧抽屉式导航主页面底部滑动切换 快的打车 左侧抽屉式导航主页面 第 30 页 3 交互分析-主导航 导航方式-抽屉式（sidebar） 从主导航方式来看，滴滴打车和快的打车非常相似，均为抽屉式导航，左侧为主功能 列表，用户可以方便的切换。 抽屉式导航的优势 节省了下方标签导航栏的空间，有助于在一屏里显示更多的内容。 扩展性好，可以在抽屉里方便地添加新功能。 适用场景 以内容/信息流为核心的应用。 只有一个核心主流程的应用。 第 31 页 目录页 第 31 页 1 概要 2功能对比 3交互分析 4改进建议 主导航 主流程 第 32 页 3 交互分析-主流程 产品主流程 对于打车应用，最主要的功能是打车，主流程大致是：乘客叫车-确认订单-司机接 单-乘客上车-乘客支付路费-乘客评价分享，形成一个O2O的闭环。 分析内容 本部分主要从以下几点来进行分析： 内容布局 流程逻辑 操作效率 操作成本 第 33 页 3 交互分析-主流程 滴滴打车-乘客叫车-主页 内容布局 布局 中间是地图，定位用户的位置、显示 周围车辆、显示叫车的起点。 底部集中了全部操作，包括叫车终点 、语音/文字切换、预约叫车、车型选 择。 整体布局清晰明了，主要操作放在底 部，用户的操作效率更高，且能单手 操作。 强弱 强展现的有：语音叫车、文字叫车、 起点。 强弱对比，滴滴偏向引导用户使用语 音叫车功能。 第 34 页 3 交互分析-主流程 滴滴打车-乘客叫车-主页 操作效率 有两个功能可能会出现低效率： 1）（与快的对比）滴滴打车的视觉设计 ，区分度偏弱，部分button不易识别， 在户外的强光、拥挤人流等场景下可能 造成用户的操作效率降低。 2）语音叫车功能，在户外噪音较大的场 景下，录音效果很差，司机较难识别。 第 35 页 3 交互分析-主流程 滴滴打车-乘客叫车-录音页 内容布局 布局 顶部是提示文案（随时间变化，会有倒计时提醒）；中间是操作，包 括取消录音、一键叫车button；底部是语音叫车的button。 录音放在中间位置，可以避免用户误操作将录音取消；一键叫车位置 靠下，路径更短，符合菲兹定律。 强弱 强展现的有：录音、语音叫车；提示用户关注核心流程。 操作成本 一键叫车的成本偏高。滴滴打车无法在文字叫车时一键叫车，需要用 户按住语音叫车的button进入语音模式，然后滑动到回家/公司 button。 涉及到两个高成本的场景： 1）用户进入了文字叫车模式，发现没法一键叫车，需要退回主页，切 换到语音叫车模式； 2）用户在语音叫车模式，主要场景是贴近手机开始说话，不容易发现 这两个button，且滑动的操作成本偏高。 第 36 页 3 交互分析-主流程 滴滴打车-乘客叫车-搜索页 内容布局 布局 图1：顶部是搜索栏；中间是历史终点，包括成功 和关闭订单的终点、搜索过的地点，默认将用户 设置的公司和家的地址排在最前，然后是是按照 时间由近到远排列的订单终点、搜索过的地点。 图2：顶部是搜索栏，用户每输入一个字就发起一 次搜索；中间是搜索结果，搜索结果以纯文字显 示，包括POI名和地址（著名POI无地址）。 强弱 页面整体没有明显的强弱对比，搜索button和搜 索栏稍强。 操作效率 用户有许多历史终点的场景，操作效率会降低。 对历史终点，用户无法做排序干预，且搜索结果 页中如果出现了历史终点，没有做排序提前处理 ，因此时间久的历史终点不容易曝光。 图1图2 第 37 页 3 交互分析-主流程 滴滴打车-乘客叫车-预约页 内容布局 布局 顶部是状态栏；中间由上到下是预约时间，预约城市、起点、终点，调度 费和捎话，最下是确认发送。 强弱 强展现的有：确认发送button、起点、终点、调度费、捎话。 整体上，调度费、捎话的视觉效果略强，建议弱化处理。 操作效率 两个场景下会出现低效率： 1）确认发送button视觉效果较强，吸引用户点击。button在不填写内容 时也可以点击，然后弹出alert提示用户，此场景下，操作效率会降低。 2）预约时间的界面太小，只能看到最多3个时间，不利于用户挑选，在用 户想预约距离较远的时间段时，操作效率会降低。 第 38 页 3 交互分析-主流程 滴滴打车-确认订单 内容布局 布局 图1：中间是地图，显示用户位置、订单的起点 和终点；底部是操作，包括车型切换、调度费 、捎话、确认发送。 图2：中间是地图，显示用户位置、语音；底部 是操作，包括车型切换、调度费、捎话、确认 发送。 操作成本 有两个高成本的地方： 1）文字叫车情况下，终点不可更改，点击订单 的起终点只能更改起点，如果想更改终点需要 退回到主页重新叫车。 2）用户在订单确认界面可以进行车型切换，语 音模式也能切换到【专车】，可是主页上选专 车时不提供语音叫车模式，需要确认语音订单 是否能识别。 图1图2 第 39 页 3 交互分析-主流程 滴滴打车-司机接单 内容布局 布局 顶部是取消叫车；中间是地图，显示用户位置 、通知车辆数、等待时间、周围出租车；底部 是操作，包括调度费、捎话。 强弱 强展现的有：调度费和捎话。 弱展现的有：取消叫车。 强弱对比，弱化取消订单功能，提高转化率。 本步的主要逻辑在司机端。 第 40 页 3 交互分析-主流程 滴滴打车-乘客上车 内容布局 布局 顶部是状态显示和未上车，然后显示司机信息、电话、状态；中间显示 车距离用户的位置、预计到达时间；底部是操作，包括支付和到达。 强弱 强展现的有：电话、支付、到达。 弱展现的有：未上车。 强弱对比，弱化分支流程，强化主流程。 操作效率 滴滴省略了乘客确认上车这个步骤，由司机端来确认，降低了乘客的使 用成本。 第 41 页 3 交互分析-主流程 滴滴打车-乘客支付路费 流程逻辑 前几步的主流程是：乘客叫车-确认订单-司机接单-乘客上车，在 这一步流程发生分支：微信支付车费，or现金支付然后下车。在用户 看来，这一步不够直观，【支付】【到达】两个button不能体现出背 后的逻辑，只会让用户困惑。 操作效率 在这里，支付和到达是两个地位等同的流程，没有恰当地引导时，用户 不知道该点哪个，强迫用户思考： 1）是先点支付再点到达？ 2）是先点到达再点支付？ 3）是二选一，只能点一个？该点哪个？ 4）是先选哪个都可以，最后流程都会涉及到吗？ 分支路径太多会出现操作效率降低的情况。 操作成本 【支付】：先微信支付后评价；【到达】：先评价，可选微信支付。 发生误操作后，用户的操作成本不高。 第 42 页 3 交互分析-主流程 滴滴打车-乘客支付路费 内容布局 布局 图1：顶部是状态显示和未上车，然后 显示司机信息、电话；中间显示微信支 付的金额；底部是关闭操作。 图2：顶部是状态显示，中间是车费输 入框和支付button。 强弱 强展现的有：电话、关闭、支付。 弱展现的有：未上车。 操作成本 图2微信支付时没有返回和现金支付的 出口，如果用户临时改变意图想用现金 支付，或者误操作进入这一步，想退回 上一步只能关掉APP重新打开，进入死 胡同，操作成本过高。 图1图2 第 43 页 3 交互分析-主流程 滴滴打车-乘客评价分享 内容布局 布局 图1：顶部是状态显示和投诉，然后显示司 机信息、电话；中间显示支付的金额，对 司机的评价；底部是发红包分享。 图2：顶部是状态显示，中间是评价星级和 点评内容，然后是提交评价button。 强弱 强展现的有：电话、分享、评价。 弱展现的有：投诉。 图1图2 第 44 页 3 交互分析-主流程 总结 优点 1）整体流程简洁，省去了用户确认上车的步骤，将用户的操作成本降低。 2）车型切换方便快捷，调度费、捎话功能简洁实用，没有加入不实用的司机乘客聊天功能。 3）内容布局合理、信息强弱得当。 改进点 1）一键叫车使用成本高。 2）支付流程不够清晰，分支流程过多，容易造成用户移动支付的比例下降。 3）微信支付时没有留出口，会让部分用户进入死胡同，成本过高。 4）确认订单时，改动起终点比较困难，特别是终点无法改动，操作成本过高。 5）整体视觉区分度偏弱，不利于室外移动场合的使用。 第 45 页 目录页 第 45 页 1 概要 2功能对比 3交互分析 4改进建议 功能 交互 第 46 页 4 改进建议 根据以上3个部分的分析，现在对滴滴打车提出一些改进建议，希望滴滴打车越办越好。 【因为我没法了解到滴滴打车的市场背景、运营数据、KPI、现在遭遇的问题、全部目标 用户的情况、产品规划、资源配置，所以我的判断很可能是错误的。所以，以下的建议， 多集中于界面交互和简单的功能，不会有运营策略、发展战略相关的建议。建议仅供参考 。】 第 47 页 4 改进建议-功能 【文字叫车】在地图上显示终点和车费 痛点 1）搜索结果时只给出POI名称和地址，用户无法完全确定终点是否正确，可能会选择错误的地点。 2） 【出租车】没法看到预估车费，不能确认打车的预算。 3）以上2点，导致如果用户对地点不熟悉，就不敢打车。 现在是如何解决的 暂时是通过和第三方地图APP合作来满足的： 1）从打车APP发起叫车的用户往往熟悉终点的位置。 2）从地图APP发起叫车的用户往往不熟悉终点位置。 问题 这种方案受限于地图合作方的资源与产品设计： 1）可能无法与用户群最广泛的地图合作。 2）地图可能不会把打车放在有利位置，没有足够的流量导入。 第 48 页 4 改进建议-功能 【文字叫车】在地图上显示终点和车费 解决方案 【出租车】文字叫车模式中，用户在搜索结 果页点击POI后，跳转到地图显示相应POI 点的位置，同时给出预估车费，用户可以方 便地修改起终点位置。 点击原型图中的起点或者终点进入搜索页， 可以修改起终点位置。 需求 这种方案，可以部分满足类似地图APP中的 打车需求，切更多的用户。 收益 1）影响所有使用【出租车】文字叫车的用 户，更好的叫车体验。 2）为滴滴打车带来更多的应用场景（即使 地点不熟悉，也可以打车）。 优先级 中。 第 49 页 4 改进建议-功能 【文字叫车】搜索页suggestion和一键叫车 痛点 1）用户在文字叫车时，无法发起一键叫车。 2）搜索页显示的历史终点，用户无法对POI点进行顺序调整，历史终点特别多的用户无法很好地查 找。 3）搜索结果页对排序的优化不够好。 现在是如何解决的 文字叫车的用户比例较少，滴滴更倾向于让用户语音叫车，这一块暂时没有优化： 1）如果想一键叫车，去语音模式发起。 2）用户需要忍受文字叫车的低效率。 问题 文字叫车对司机更友好，叫车成功率更高，值得优化。 一键叫车只在语音模式下存在的设计不够合理，利用率较低。 第 50 页 4 改进建议-功能 【文字叫车】搜索页suggestion和一键叫车 解决方案 文字叫车模式中，搜索页显示3个一键打车 的button（增加常用）和历史终点，用户可 以收藏历史终点，收藏的点会被置顶。 搜索结果页，如果有历史终点被召回，历史 终点需要排在最前面，其他召回的POI往后 排。 需求 经常使用文字叫车的人、历史地点较多的人 ，对文字叫车的功能优化有需求。 收益 1）影响所有使用文字叫车的用户，更高的 效率。 2）提升一键打车的使用率。 优先级 高。 第 51 页 4 改进建议-功能 【支付方式】信用卡支付车费 痛点 打车的主流程是：乘客叫车-确认订单-司机接单-乘客上车-乘客支付路费-乘客评价分享， 仍旧太长，需要用户参与的地方太多。 支付环节是微信支付和现金，仍有优化的余地。 现在是如何解决的 乘客只能使用2种支付方式： 1）微信支付。 2）现金。 问题 现金携带不方便，且需要找零。 微信支付太麻烦，需要输入车费、输入密码，且需要保值微信的余额或银行卡里有足够的钱。 第 52 页 4 改进建议-功能 【支付方式】信用卡支付车费 解决方案 允许用户绑定信用卡，利用信用卡来支付车费。 乘客确认订单后，系统预估车费，然后扣除120%的信用额度。 车费由司机在司机端输入，用户只需要在用户端进行确认即可扣费，剩余部分退回给乘客。 需求 所有使用信用卡的用户都会有此类需求。 收益 缩短支付流程，提高效率。 优先级 低。 第 53 页 4 改进建议-功能 【积分商城】增加积分商城，提供更多激励机制 问题 快的打车的积分系统，能很好地激励老用户，滴滴暂时无此模块。 解决方案 增加积分商城，提供各种团购和优惠券的兑换。 收益 提高用户粘性。 优先级 中。 第 54 页 4 改进建议-功能 【订单管理】已支付订单无需再出现支付button 问题 已支付车费的订单，进入订单管理页面时， 微信支付仍然可以点击，仍可以支付车费， 不够合理。 解决方案 对于已经成功支付的用户，显示成功支付的 车费金额。 优先级 低。 第 55 页 4 改进建议-功