您好!
欢迎来到京东云开发者社区
登录
首页
博文
课程
大赛
工具
用户中心
开源
首页
博文
课程
大赛
工具
开源
更多
用户中心
开发者社区
>
博文
>
细分场景下设计赋能仓储体验
分享
打开微信扫码分享
点击前往QQ分享
点击前往微博分享
点击复制链接
细分场景下设计赋能仓储体验
自猿其说Tech
2021-09-23
IP归属:未知
36080浏览
视觉设计
![](//img1.jcloudcs.com/developer.jdcloud.com/349afa01-e2f0-4ff6-8a43-ea4295a52acb20210923153647.jpg) ### 1 前言 WMS系统是智能仓库管理系统(Warehouse Management System) 的缩写,可以实现完善的企业仓储信息管理,提高仓储物流配送效率,统筹仓库的内部员工与资源,协同作业,节省人力和时间,从而帮助仓库操作人员高效的完成订单履行。而WMS6.0 APP端与WMS PC端相配合,可以将在库、入库、出库、上架、生产管理、物料管理等仓库内的作业流程装载到移动设备中,以此带来更加便捷的全方位管理。 ### 2 背景 #### 2.1 京喜通是什么? 【京喜通(新通路)】是京东旗下的一个商流品牌,与京喜拼拼社区团购业务并行。所谓的商流是指物品在流通中发生形态变化的过程,即由货币形态转化为商品形态,以及由商品形态转化为货币形态的过程;随着买卖关系的发生,商品所有权发生转移。 #### 2.2 京喜通和京喜拼拼有什么不同? ![](//img1.jcloudcs.com/developer.jdcloud.com/0bf955aa-24bb-41ea-bd38-0f6f6a4ddff020210923153722.png) 不同仓的备注说明:共享仓(一个实际存储货物的仓库,供应商将原始商品给到共享仓库中进行生产)-分拣仓(共享仓给到分拣仓,对商品进行二次生产,进行分拣动作;按照网格站、直发团等维度进行分拣)-网格站(末端的配送,由网格站的司机或者其他的承运商进行配送)-团长(按照不同区域划分的自提点)-C端用户(客户)。 ### 3 业务场景与流程分析 作为一名B端的设计师,更多的是需要深入业务场景探究用户在作业过程中的痛点,进而解决痛点以提升用户体验。在设计开始之前先进行业务场景梳理,发现可能会影响用户在作业流程中高效完成工作的问题,再对此利用设计策略解决问题。 #### 3.1 新通路业务场景与流程概览 ![](//img1.jcloudcs.com/developer.jdcloud.com/d85310cd-41d9-49e4-8b48-e49d4351011d20210923154119.png) #### 3.2 新通路仓收货交接/分播流程拆解 本次设计的主要内容是收货与分播两个场景下的APP功能模块。核心设计目标是于在提高用户的操作效率,同时保证操作容错率,提升用户体验。因此,在设计中需要对用户的每一步操作尽可能前置引导、操作过程中实时反馈。 通过下图所示收货交接流程可以看到,用户在待收货环节中会有两类作业场景,第一类为扫描–校验-异常-上传-完成-扫描(异常流程),第二类为扫描-检验-完成-扫描(正常流程)。两种场景影响用户作业效率的就是异常的流程。通过调研发现,实际场景中出现异常的流程频率不低,所以在包裹扫描确认的流程中要更多的考虑出现异常的流程,同时还要保证收货员操作的效率。 而在分播的流程中,扫描完包裹号后系统反馈的格口号展示方式则是影响用户操作的主要因素,怎么保证用户看得清反馈结果、不需要记、且能方便操作是首要考虑因素,也是本次设计的发力点。 ![](//img1.jcloudcs.com/developer.jdcloud.com/05d5a999-25f9-4480-ba9e-16984f0454bf20210923154146.png) ### 4 基于业务场景的问题解决&设计方案 B端的产品注重效率,那我们在提供解决方案时是不是只需要考虑效率,而弱化用户在操作中的体验呢?如果完全注重收货场景中要尽可能的“快”,就会有以下方案的产生。用户操作路径简而言之就是扫描-判断是否异常-扫描下一个包裹。具体拆解开来看,三个主要的动作体现为: 1)从系统推送的待收货列表中找到需要收货的任务集合单,浏览完该任务单下的包裹数、商品数后点击收货按钮跳,转至包裹收货操作页面,此时用户需要进行的操作是点击“包裹号扫描框”。 2)将手中的设备对准包裹号进行扫描,扫描完成的瞬间系统自动对其进行校验,此任务单下包裹号是否与扫描的包裹号相匹配;相匹配后弹出“扫描成功”toast。 3)高亮当前扫描数据,该包裹数据在没有破损的情况下,用户可以点击继续扫描,继续下一个包裹。 ![](//img1.jcloudcs.com/developer.jdcloud.com/677910dc-522d-42de-ac3e-f8d89ec2814220210923154227.png) 不难看出,该交互方案带来的效果就是“快”,而在快之余也带来了另外一个情况,该集合单下如果破损出现频率高,而用户在扫描过程中又追求“快”,就会不可避免的导致用户点了继续扫描之后才想到没有进行破损上报,那此时这个已经扫描完的包裹数据已经移动到已收货列表中,且在已收货列表中只能查看展示情况,无法再对此条包裹数据进行操作,对用户侧来说容错率极低。 我们再来看看仓库中一线用户的调研情况,仓储中的一线人员呈现出:学历水平不高,对IT软件的操作并不熟悉,对新事物接受的程度慢。他们对系统的期望在于:有明确的业务流程和规范指引,有更多的防呆设计,即使是新手用户也不容易犯错。产品的易用性要好,容易上手且要有实时有反馈,增加容错机会,即使操作失误也可以进行二次操作。 那么,如何增加用户容错机制?关键就在于增加任务中间状态,清楚显示该任务所处不同阶段,且可以对其更改。我们先来看一个WMS5.0 PC端的界面(下图为WMS 5.0系统-PC新老界面)。 在WMS系统中不管是迭代后的界面还是老版的界面中都保留了一个单据流转的状态,如图中所示,在一个一单多件的订单中,复核员操作完其中的一个订单数据后该笔订单由待复核状态更改已复核状态,但同时已经复核完的该商品支持重新复核。即使复核员操作失误后,该笔订单依旧支持重新操作,对于员工的误操作可以有很好的解决。 ![](//img1.jcloudcs.com/developer.jdcloud.com/c5aa9f35-6318-4d31-b300-28db6726548020210923154247.png) 借鉴WMS5.0的设计巧思,我们能不能将此应用到京喜通的项目设计中呢? 答案当然是肯定的,我们可以把WMS5.0 PC端的设计思路融入到移动端中。具体而言,一方面在保证收货快的情况下考虑用户在作业过程中可能有误操作的情况,对于扫描包裹的任务增加中间状态;另一方面减少用户认知负担,对使用过WMS系统的一线人员来说会有一种熟悉感,从而减少培训成本和用户学习成本。具体的设计方案体现在三个层面: 1)划分区域,对每个区域的使用有明确指导 ![](//img1.jcloudcs.com/developer.jdcloud.com/c547c77b-d716-47f8-88ce-66be528cd7c820210923154317.png) 参考WMS5.0 PC端设计思路,将收货交接主页面划分区域,按照【点击操作区】、【任务进行中】、【待收货】、【按钮区】进行划分;同时对用户最需要关注的两个区域【任务进行中】、【待收货】在标题下增加说明,告知用户怎样进行操作以及在面对异常包裹情况时应该进行什么操作。进行中的任务区域在未进行操作时以场景化的插画加操作说明引导用户,同时将提示语句链接到扫描动作,方便用户快速点击进行扫描动作。 2)增加容错机会,减少用户订单误操作 ![](//img1.jcloudcs.com/developer.jdcloud.com/a626f3e9-9d1f-47e0-bd55-622b67e7435320210923154343.png) 区域划分后,用户此时的操作路径为:扫描包裹-成功反馈-继续扫描下一个包裹-全部任务扫描完成-全选任务确认收货。与上面追求“快”的方案相对比可以看到用户在此的路径多了一步(全选、确认收货),但是增加了出错后允许在此更改的区域,从而大大增加用户操作的容错率。同时,用户如果在现场发现剩余包裹中有异常的情况,可以不用扫描包裹号,直接全选待收货列表中的包裹任务号进行破损/缺货登记,以缩短用户操作路径。 3)及时反馈,减少用户记忆负担 在仓库的作业中除收货交接外,还有一个重要的工作就是分播。在分播的作业中,分播员需要按照包裹或商品维度分播,具体需要用户操作的路径为:点击按包裹分播三级入口-进入按包裹分播页-点击包裹号扫描-进入扫描页面-扫描后反馈应该分播格口的结果-按照反馈的格口进行分播。 ![](//img1.jcloudcs.com/developer.jdcloud.com/ea67af9c-78c9-4114-af5b-ecf53c58f67e20210923154405.jpg) 此时问题就出现了,我们应该用什么样的反馈结果告知用户?如上图所示,扫描完的瞬间将系统判断的应放入格口号结果,以弹窗的形式反馈给用户,那用户需要做的就是记住这个格口号,点击确认后再去找到对应的格口号扫描、放入包裹。粗看似乎没有什么问题,但是在分播的场景中,格口号的位数长短不一,有的格口号字母与数字混杂,且前文中有提到仓库的一线操作的整体文化素养不高,他们对系统的期望在于有明确的业务流程和规范指引,那无疑在记住一串格口号的步骤上会对他们的记忆产生负担。 ![](//img1.jcloudcs.com/developer.jdcloud.com/0b8b7f7b-77e5-4fca-be26-7e03dbbf066e20210923154425.png) 在考虑到上述问题后,关于扫描后应放入的格口号结果应该更换展示方式,尽可能的展示在一个页面中,减轻用户的记忆负担。以此为设计思路就产生了上图的设计方案,扫描完包裹号后将反馈结果展示到当前页面中,提高格口号展示的层级;同时将光标自动定位到格口号扫描框中,用户此时需要做的就是看到明显的格口号提示,走到对应的格口号前扫描,扫描成功后该包裹分播成功,从而减少中间记忆的步骤。同时,在下方的区域中系统实施刷新数据,告知用户目前应该分播多少件 、实际分播多少件。一句话概括,就是把复杂的事情交给后台,把最简单最清晰的操作留给用户。 ### 5 总结 对业务需求的100%支持是设计师的本职工作,而设计想要提升自己的价值、产生更大的影响力,不能只沉浸在产品传达的业务需求里。对于B 端的设计师来说,要更加深度的钻研业务理解能力与体验思维,深入到具体的业务场景之后发现、收集影响用户体验的问题,进而推导出产品的可发力点,抓住并完善这些发力点,提高体验设计师的价值。 ------------ ###### 自猿其说Tech-JDL京东物流技术发展部 ###### 作者:用户体验设计部 苗剑宇
原创文章,需联系作者,授权转载
上一篇:鸿蒙App-开发从环境搭建到“Hello Harmony”
下一篇:ClickHouse技术研究及语法简介
相关文章
UE Design | 交互设计三板斧:思维、方法、工具(基础篇)
Airbnb:用设计建立情感链接
Apple:设计改变世界
自猿其说Tech
文章数
426
阅读量
2149964
作者其他文章
01
深入JDK中的Optional
本文将从Optional所解决的问题开始,逐层解剖,由浅入深,文中会出现Optioanl方法之间的对比,实践,误用情况分析,优缺点等。与大家一起,对这项Java8中的新特性,进行理解和深入。
01
Taro小程序跨端开发入门实战
为了让小程序开发更简单,更高效,我们采用 Taro 作为首选框架,我们将使用 Taro 的实践经验整理了出来,主要内容围绕着什么是 Taro,为什么用 Taro,以及 Taro 如何使用(正确使用的姿势),还有 Taro 背后的一些设计思想来进行展开,让大家能够对 Taro 有个完整的认识。
01
Flutter For Web实践
Flutter For Web 已经发布一年多时间,它的发布意味着我们可以真正地使用一套代码、一套资源部署整个大前端系统(包括:iOS、Android、Web)。渠道研发组经过一段时间的探索,使用Flutter For Web技术开发了移动端可视化编程平台—Flutter乐高,在这里希望和大家分享下使用Flutter For Web实践过程和踩坑实践
01
配运基础数据缓存瘦身实践
在基础数据的常规能力当中,数据的存取是最基础也是最重要的能力,为了整体提高数据的读取能力,缓存技术在基础数据的场景中得到了广泛的使用,下面会重点展示一下配运组近期针对数据缓存做的瘦身实践。
自猿其说Tech
文章数
426
阅读量
2149964
作者其他文章
01
深入JDK中的Optional
01
Taro小程序跨端开发入门实战
01
Flutter For Web实践
01
配运基础数据缓存瘦身实践
添加企业微信
获取1V1专业服务
扫码关注
京东云开发者公众号