【转载】物流的场景化设计

移动互联网的普及、消费升级以及懒人经济的兴起等因素,为即时配送带来海量用户。新零售经济在中国的快速发展,也萌生了一些新型的场景,来自新型超市的订单增长迅速。但不管如何发展,对于物流设计而言,就是解决新增场景下骑士的触点问题。面对复杂多样的场景,我认为物流的设计更适合称作「场景化设计」。我们可以通过分析场景要素来定义设计的基本原则,通过发现特殊场景挖掘新的机会点。接下来,我来介绍一下在配送过程中运用场景化设计的例子。

案例1:蜂鸟众包卡片信息改版

在18年底我们对「蜂鸟众包」App的主流程做了一次改版。对于一款工具类产品来说,使用效率是我们最基本的设计原则。从下图我们可以看到,配送整个流程由3个大场景组成,也就是配送的3大任务:抢单、取货和送货。因为即时配送对配送时间要求极高,所以如何通过设计降低配送时长是设计的价值所在。在这3个场景中,骑士面对的任务和关注的信息是完全不同的,对于不同场景下的订单卡片信息进行针对性地设计可以有效提升骑士的配送效率。通过对场景的拆解和重组,我们最终把整个配送过程中骑士的行为抽象为两种,一种是「决策」,一种是「专注」,所有的研究和设计都是围绕这两种行为进行的。

首先,我们以发问卷的方式,通过收集骑士对订单卡片信息的关注程度来判断他们产生决策时所关注信息的优先级。为了保证最后结果的有效性和准确性,针对3个场景我们分别设立两个问题:一个是让骑士直观地选出他认为最重要的信息,另一个是挖掘骑士产生行为的动机来源。我们分别来看下这3个场景:

第一个场景:抢单

通过第一个问题「在抢单时,您主要根据哪些信息来判断是否要抢该单?」,我们得到骑士抢单时,最关心剩余时间、订单方向和取送距离,对于小费、预订单等信息考虑较少,但在之前的版本中,小费和预订单的信息层级却很高。第二个问题「以下订单同时出现在抢单列表,您最先抢哪种单?」,从结果我们可以发现,骑士心中对订单是有要求、有选择的。内心最真实的需求是希望抢到位置更好、时间更充裕的订单。

用问卷收集骑士对订单卡片信息的关注程度

两个问题从不同的角度相互映证,基本确定了骑士在抢单时最关注的是订单的配送难度而非价格。在这次优化中,我们通过加强文字对比使信息层级更清晰;强化地址信息、弱化价格和预订信息,突出抢单的决策信息;去除了圆角卡片和阴影效果,降低代码绘制特殊效果产生的性能问题;通过压缩模块间的间距,提升屏效。

第二个场景:取货

通过数据可以发现,在待取货页面,骑士关注剩余时间是为了避免迟到,关注备注信息是为了看有没有特别需要注意的,以免造成后续不必要的麻烦。而问到「什么时候会看待取货列表」时,看订单流水号、顾客备注、剩余时间占据了前几位。因为取货时,场景发生了变化:到达商家处,需要凭流水号取餐,所以流水号信息变得异常重要。

用问卷收集骑士在取货场景中对信息的关注程度

在这次问卷过程中,我们还发现了一个有趣的问题。在待取货卡片中,我们原本认为骑士取货主要看商家地址信息,但我们收到问卷后却很意外地发现,在取货时,选择送餐地址的比例远远高于商家地址。于是我们进行了线下访谈,得到的答案是:路上是在看商家地址,但取货时需要核对送餐地址,以免拿错,造成严重的后果。通过这个事情,我想说的是,用研是设计的第三只眼,要用。

在取货场景的卡片设计中,我们强化了订单流水号方便骑士快速寻找商品;强化备注内容方便快速查看特殊要求;去除了抢单时的标签,剔除干扰信息,提升阅读效果。

第三个场景:送货

这个场景和取货场景比较类似,骑士同样关注剩余时间、送餐地址,不同的是送达前的必备操作换成了「联系顾客」。

用问卷收集骑士在送货场景中对信息的关注程度

通过对3个场景的分析,可以看到不同场景下骑士的关注点是完全不同的,信息的展示方式也就有所不同,但都是在坚持「效率优先」的设计原则。其实,除了这3个场景,还有帮买帮送订单的场景,决策信息和取货方式也是不同的。针对这样的场景,在细节上也做了区分,这里就不做赘述。另外,我还想说设计改版不一定要大刀阔斧,更多是对细节的打磨。

上述项目主要是应用场景化设计提升基础体验的例子,接下来再来看一下通过发现特殊场景挖掘机会点的例子。

案例2:滑动确认

在骑士配送的过程中,订单卡片页作为 App 主流程页面,它的操作非常频繁。我们发现部分骑士因为一些个人的操作习惯,极易误触操作按钮。虽然为了防止误触,做了二次确认弹窗,骑士可以关闭弹窗,但是在抢单过程中时间稍纵即逝,多一次关闭操作,极大地降低了骑士抢单的效率,对心理也有一定影响。其次,在送达场景下,如果不小心又误触了弹窗的确认键,这个操作是不可逆的,将导致「提前点击确认送达」,可能造成用户的投诉和相应的处罚。虽然可以通过申诉去解决问题,但是如何判断行为的真实性,又给审核造成了一定的难度,而且申诉需要时间,这也增加了骑士的申诉成本。

这样的高频场景在其他产品中是很少见的,在考虑如何设计时我们想到了 iPhone 的滑动接听,适当提高操作按钮的门槛,避免触碰造成的直接响应。同时为了满足不同骑士的需求,我们增加了设置选项,把选择权交到骑士手中。

案例3:离线送达

在17年初有条微博非常火,讲的是一个骑士小哥送餐时,订单即将超时,在电梯里急哭的场景。看到这样的故事,大家在表示同情的同时也会指责平台对于骑士送餐超时的处罚过于严格。但严格的制度和高效率本身就存在一定的矛盾性,作为设计师,我们必须面对矛盾和约束,没有约束的设计又怎么能在商业体系中体现价值呢?

举一个在约束下设计的例子。相信大家都遇到过打电话时进了电梯,电话突然没信号的情况。我们在以往的反馈中也收到了很多骑士说在电梯里断网,无法点击「确认送达」,导致订单超时,要花大量时间进行申诉,申诉还可能不成功,给他们带来了很大的困扰。按照以往我们的思考逻辑会是「电梯没网我们也没有办法」,但是以场景化思维来考虑的话就不一样了。打电话是即时通话,一旦无信号,打电话这个行为就中断了,而点击「确认送达」这个行为是整个配送完成后进行的一次中断行为,只不过给这个中断行为增加了一个「截止时间」,而这个「截止时间」是可以通过技术手段进行延迟的。所以我们只要把电梯没网的这段时间掐掉就好。

和技术同学多次沟通后,他们建议在无网络时若骑士点击「确认送达」,通过打点的方式记录打点时的地理坐标和打点时间,当网络恢复时判断地理坐标的有效性,然后自动确认送达。地理坐标打点能保证骑士是在送餐点执行操作,避免骑士的作弊行为。功能上线后有非常好的效果:

1、每天挽回1.5万单的超时单;

2、降低了骑士对该问题的申诉成本和客服成本;

3、体验的提升让骑士对平台更有信心。

上面两个例子是两个简单的场景,还有很多场景化设计的例子,就不在这里一一介绍了。除了在界面上的应用,还有对细分场景的挖掘。在整个配送过程中,从取货到送货,最难的是最后送餐给用户的这几百米距离,如刚才说的电梯,在中午高峰期可能等一趟电梯就要花去好几分钟;对于地形复杂的学校公寓,找到最终位置也是骑士送餐的一大痛点;还有部分高档小区,不让骑士骑电动车进去,需要步行找到送餐的楼栋。这些无疑大大降低了骑士送餐的效率,影响他们的收入。这其中有很多场景可以通过场景细分的方式来解决,如使用送餐机器人、园区无人车、无人柜还有物业大妈来完成最后这几百米配送。

我们也正在做这样的事情,送餐机器人、无人车已经在部分楼宇和园区进行试运行。相信在不久的未来,当你收外卖时将会看到一个饿了么送餐机器人,如果你在电梯上遇到它,也请大家给它让个位置。

最后

一切产品都是基于场景进行设计的,想要做好产品要从研究场景出发。同时,更多的场景也代表了更多的机会,设计师要尽量避免给自己设边界。设计的价值不应该只停留在界面上,要去挖掘整个链路的服务系统,通过用户的使用场景研究人与人、人与物之间的触点,去发现更多的机会点,而这些机会点才是设计价值的体现。

那么,你所做的产品又有哪些机会点呢?

作者 | 吴磊

来源丨饿了么UED


分享到:


相關文章: