案例复盘 | O2O配送项目中我踩过的那些坑

我是创始人李岩:很抱歉!给自己产品做个广告,点击进来看看。  

想成为一条优秀产品狗,除了要掌握撕逼的技巧,还要有优雅的复盘姿势。在成为一条优秀产品狗的道路上,每做完一个项目,我总会花上一点时间,静静地回想那些踩过的坑,那不就是产品狗的修行之路么·····

案例复盘 | O2O配送项目中我踩过的那些坑

公司的项目是一个O2O的电商平台,我负责的项目是用户与商家之间的桥梁—-配送系统。这个系统的主要用户角色是配送员和运营调度人员,so产品也分为配送员app及后端的运营调度系统。话不多说,先上菜,哦不,先上坑!

效率与体验的天平:强制更新机制

第一个版本考虑到app为内部员工使用,以及尽快上线的原则,没有设计强制更新策略。当迭代了两个小版本后发现,各个版本都有人在使用,甚至有较大功能缺陷的版本也有配送员在使用。发现这个问题后,我们紧急上了强制更新功能,为了这个有强制更新功能的版本及时覆盖所有配送员,整个团队也花了不少时间和精力。

填完这个坑,总算是明白了为什么前辈们总是语重心长的说“任何一款app一定要考虑好更新策略”。虽然做产品经理,要尊从二八原则,但并不是完全不考虑小部分的情况,因为没有哪个公司的执行力能做到100%。强制更新的用户体验虽然差,但是对一个内部员工用的产品来说,效率比体验重要的多。即使是用户app,也因该预留强制更新功能,出于用户体验考虑你可能永远都不会用,但是以防万一总是好的。

当然咯,很多朋友会有疑问,iOS强制更新,怎么通过App Store审核?哈哈,方法总比困难多嘛~出于职业精神,我就不在公共场合讨论BUG啦(严肃脸)!有兴趣可以私聊探讨哈。

善意的小欺骗,让世界更和谐

配送员app抢单列表中,配送员可以点击抢单按钮进行抢单。但是,会有多种情况导致抢单失败,比如:

  • 点击抢单时,订单已经被别人抢走
  • 点击抢单时,订单已经超时(系统有自动派单机制,订单在x分钟内没人抢单判定为超时,系统会自动派单)。

对于这样的情况,我在第一个版本分别做了2种不同的提示:

  • 订单已被抢
  • 订单已超时

本以为给出了明确的提示,万事OK了。但是,上线后反馈却很不好:

明明已经超时了,为什么还要显示在页面上让我们抢,抢又抢不到!

确实,这样的做法很不好。配送是一个对效率要求很高的环节,在这样的反复抢单失败中,严重损害了配送员抢单的积极性。

不得已,只能在待抢单列表中增加了定时刷新的机制,每隔1分钟刷新列表。这样可以过滤掉部分已经被抢或已经超时的订单,但还是有部分订单因为超时而抢单失败。最后,没办法,只能做了一个小小的欺骗:将订单已超时和订单已被抢的提示都统一成了“手慢了,订单已被抢”。瞬间问题就解决了,再也没有听到有配送员抱怨了,世界又一下子和谐了!

从心理学来说: 人们在归因的时候,更容易得出自己想得到的结论,而不一定是真实的结论。并且出于心理上的自我保护,人们会将导致失败的外界原因放大,而将自己个人的原因淡化。 所以,当因为订单超时导致抢单失败时,配送员会抱怨产品的设计问题(外部因素)。但是同样的结果(问题本质并没有得到改善);“欺骗”他是因为自己手速慢了,导致订单被抢,却没人再抱怨了(个人因素)。不但没有配送员抱怨了,反而看到订单的时候都及时去抢单了,不再挑三拣四,订单处理的整体效率还得到了提升!

填完这个坑,终于领悟,做产品,不仅要有很高的理性思维,也要有很强的感性思维。有时候,通过理性思维很难解决或解决成本很高的问题,换个维度,通过感性思维,说不定就不费吹灰之力。

设计是为了更好地传达信息,不要为了设计而设计

第一个版本的调度系统首页,我做了一个精美的欢迎页。一开始使用的同事们觉得还不错,但是过了几天,大家就审美疲劳了。因为同事们每天要登录很多次,去查看配送系统中的各项数据,欢迎页除了一开始的新鲜,对效率的提升毫无帮助。

认识到这个问题后,第二个版本优化时,我将欢迎页改为一个仪表盘。将工作中的配送员、待取货的订单数、待送货的订单数、报错订单数等重要数据在仪表盘实时展现出来。这样一来,工作人员一登录系统,就可以直观看到他们最想看到的重要数据,而不是一张“精美”的欢迎页,还要再经过几次点击,才能看到他们想看到的数据。

所以,我们在设计产品时,需要 时刻提醒自己,产品的用户是谁。 后端产品的用户是公司内部的同事,相比于美观,他们更需要的是效率。如金字塔原理一样,结论先行、重要的结果先行,登录后最先展现的是重要的数据,这对效率的提升就很有帮助。就如原研哉所说“设计的目的是为了更好的传达信息”,永远不要仅为了美观而设计。

没有绝对的平等,只有相对的公平

在设计智能派单算法时,一开始,为了体现公平,每个配送员被系统分配到订单的可能性只取决于配送员当前位置、订单路线、订单承诺送达的时间、配送员当前手上配送中的订单情况等客观因素。但是后来发现,这样一来配送员的配送速度、配送满意度等个性化指标没法贯彻落实,因为在派单机制中,没有将这些作为考虑因素。

后来在版本优化时,在智能派单算法中增加了配送员速度、满意度等个性指标对派单概率的影响。就这样在智能派单机制中遵从了森林法则,配送速度快的、满意度高的、超时率低的配送员被派单的可能性更大,相应的绩效工资也更高。增加了个性化指标对派单概率的影响后,解决了为了平等而一刀切的情况,形成了良性竞争,对整个配送团队的效率带来了很大的提升。

很多时候,公平不是平等,平等是没有条件的盲目平均,而公平是有前置条件的平等。平等滋生迂腐和低效,而相对的公平能带来良性竞争和高效。我们在设计产品时要避免平等,而是要用公平去设计规则,来达到产品目标。

复杂的问题,也能用最简单的基本原理来解决

一开始,设计调度管理系统的权限时,只设计了账号和权限2个维度。但是,在实际使用过程中发现这样很不方便,当要增加一个新同事的账号时,需要在好几十种权限中勾选出他需要的权限。不仅过程十分麻烦,还会出现多勾选了不该赋予的高级权限,或少勾选了账号需要的权限等差错。

得知了这样的情况后,在后来改版时,我将权限分了3个维度:账号、角色、权限。这样,先对不同的角色赋予不同的权限,如客服、客服主管、客服总监、调度员、配送总监等角色。当新同事加入时,只要将该同事的账号与对应的角色关联就OK,不再需要勾选很多权限,大大提高了权限管理的效率,降低了出错率。而且,当大要开通Boss的账号时,只需要将客服总监、配送总监等高级角色都赋予Boss账号即可。

系统的权限管理,可以类比到公司的组织结构管理上:员工由经理管,经理由总监管,而Boss只要管理各业务部门的总监就ok了。正如《简约至上》中所说,组织是简化设计的重要策略之一。将繁杂散乱的功能或元素,根据其特性组织分类,形成一个树形结构,这时候我们就更容易看清问题的本质。一但抓住问题的本质,复杂的问题往往就能迎刃而解。

篇幅原因,就先分享这么几个我踩过的坑吧,希望我的前车之覆,能为后车之鉴。

作为一条产品狗,我还在不断挖坑和填坑的道路上前进。复盘的目的只是为了不掉进同一个坑两次,未来还有更多的坑在等着我!但,那又怎样,万物皆有裂痕,那是光照进来的地方!

 

本文由 @胡小Q 原创发布于人人都是产品经理。未经许可,禁止转载

随意打赏

提交建议
微信扫一扫,分享给好友吧。