滴滴的产品坑我-技术圈

昨天经历了一次不太好的产品体验，虽然从设计逻辑上没毛病，但我还是想吐槽一下滴滴的产品。

事情是这样的。

昨天下午我出去打球，把车开到洗车店放那洗车，自己骑了个电动自行车去球馆，路程大概也就 10 分钟。

去时我骑的是一个叫「小遛共享」的电动自行车产品，花费 2 元，全程没毛病。

打完球准备去店里取车，于是我准备继续骑电动自行车过去，看到路边摆放了一台比较新的滴滴青桔电动自行车，于是扫码了。

扫完后先是进行人脸认证，然后弹出个框让我选择目的地，我没太注意对话框的提示信息，然后直接选择了跳过。

在我当时的认知里我只是原路返回，所以基于上一次的体验，各种情况都是在预期中的。

可当我骑到一半时，车辆就报警说我即将超出运营区并让我尽快返回，如果不返回就会断电。

起初我没太注意，因为之前骑别的车也遇到过这样的情况，可能是贴着运营区会触发这个警报，于是我继续往前骑行。

可还没骑出几百米，车辆突然断电了。

车速慢下来，我几次尝试拧动电门，还是无果，无奈只能停下来拿出手机查看，结果提示我超出运营区，并且让我选择是否恢复供电骑回运营区。

我有两个选择，一个是一分钟内恢复供电骑回去，另一个是就地停下，但需要支付 40 块钱的调度费。

我一想，40 块钱这么贵，那就硬着头皮骑回去吧。

骑到运营区最近的停车点大概有 500 米，停车，支付 2.5 元。

好嘛！既没给我送到目的地，也多跑了冤枉路，还照常收了我钱。哎，这次体验真是糟糕透了。

没办法，我又继续找了一辆之前来时的电动自行车骑回去，又花了 2 块钱。

回来之后我针对两款产品做了个对比，发现了一些问题。

首先，造成我两次骑行体验不同的主要原因是因为两款产品对运营区的划定范围不同。

滴滴的划定范围正好在我的出发地和目的地之间，而我骑到断电点之后不得不再把车骑到最近的换车点还掉。

我不知道这个运营区的划定是基于什么逻辑，但按照实际场景来看，这种划定肯定是有问题的。

因为这条路是一条环湖路，对于短途出行来说至少也是两公里以上，而这条线正好划分在一个路口，对于正常场景下的目的地选定是没有什么参考性的。

然后我又想起来扫码时弹出的那个对话框，当时提示让我选择目的地，可能也就是为了确保我在运营区内还车。

我又试着打开选择目的地的界面，是搜索模式，而非地图选定模式。

也就是说，你必须精确知道你的目的地才能确定是否在运营区内。

打车和骑行的场景还是有些区别，打车有精确目的地，而骑行的目的地范围没那么可控，而且还要考虑还车点，所以这种设计就很不友好。

不过归根结底还是在运营区的划定上，相比之下，另一款产品做得就好一些。

整个红线以上的区域都在运营区，也囊括了整个环湖路，对于这个片区的骑行需求是都可以满足的。

以前我也是用这款产品，基本每次都没出什么意外，可无奈支持一次滴滴就被坑了。

从产品角度来说，滴滴的设计在逻辑上没问题，但在体验节点很容易形成 bad case，我就是其中一个。

可能这种例子发生的概率并不大，但只要发生一例，基本上就会对用户造成很不好的印象。

如果下次有两辆车可选，我肯定选择后者。

体验就是感受，感受来自于现实反馈。

从运营角度来说，区域划定不能是随意标记，应该根据用户骑行数据做综合研判，起点和终点密集区、常规路线统计、频率等等，这些都可以作为运营区划定的依据。

此外，对于处在运营区边缘的骑行需求，在产品上的提示可以做强一些，这样也不至于用户忽略而造成不好体验。

从用户角度来说，只会关注你是否把我送到了目的地，送到了服务才完成，服务完成才付款。

但拿我这次的体验来看，目的地没送到，服务没完成，但我还是付了款，这就挺坑。

产品逻辑和功能上的闭环是完成了，运营闭环也完成了，但用户体验闭环缺口了。

这倒是能给做产品的同学一些启发，不要只关注软件层面的设计是否完整，多结合真实场景考虑体验闭环是否完整。

真实的产品，一定是运行在真实的世界里，而不是在流程图和代码里。

共勉！

················· 唐韧出品 ·················

安可时刻

思考题：如果你是滴滴的产品经理，针对这个问题会如何解决？

今天，与 75752 位读者一起见证彼此成长

后台回复“w”，可加我个人微信