批量导入是B端后台产品中常用的一大功能,看起来简单但是实际上做起来却能够发现里面的坑有很多。作者结合自己的实战经验,与大家分享自己当时从0到1的设计过程,希望对你有所帮助。

b端产品设计与实现总结(B端产品设计批量导入)(1)

批量导入是B端后台产品中非常常见的功能,乍看简单,但实际做起来才发现里面的坑着实不少。笔者根据自己的工作经历,记录整理了当时从0到1的设计过程。内容较长,耐心看完,相信你一定会有所收获!

一、业务分析

在开始任何B端产品的功能设计前,都需要先分析这个功能对应的业务场景以及想解决的业务问题。

批量导入也不例外,一般导入功能都出现在需要单次录入大批量数据的后台产品中。根据不同的场景会有不同的应用,需要结合用户特征来一起分析,它们共同决定了导入功能的软件功能流程和基本逻辑,例如:

  1. 导入的数据是“新增”还是“覆盖”?(即系统中已有数据的情况下,本次导入是在其后添加数据,还是完全覆盖系统已有的数据)
  2. 存在错误数据时,是忽略错误数据允许正常数据导入,还是全部打回重新导入?
  3. 错误数据如何提示和处理,是在线修改,还是导出excel让客户修改后重新导入?
  4. ······

这些都是在业务分析阶段就需要思考的事情!

二、导入流程

导入功能大致可以分为3个环节

  1. 导入指引:让用户了解怎样使用导入功能,并给出一份模板文件;
  2. 导入文件:上传文件,并校验错误数据;
  3. 结果反馈:让用户知道本次导入的结果&影响。

其中2是最麻烦最复杂的一环,因为除了常规的文件类型和数据格式校验外,部分B端产品可能还会有一些业务上的限制,需要考虑到导入的数据与现有的业务规则是否冲突,如果存在冲突,要以何种形式告知用户哪些数据异常、要如何处理。

三、功能设计

3.1导入指引

3.1.1导入指引

如果导入过程并不复杂,只需要给出下载模板和上传文件的入口即可;如果流程比较长,需要给出一条明确的步骤指引。

b端产品设计与实现总结(B端产品设计批量导入)(2)

3.1.2模板说明

对于一些重要的系统要求或者是不易察觉的设置,需要在表头上进行说明,引导用户正确的填写数据。

b端产品设计与实现总结(B端产品设计批量导入)(3)

3.2导入文件

3.2.1 导入进度

根据导入数据的规模和校验规则的复杂程度,需要考虑不同的上传进度提示。(这些最好提前与研发人员沟通好)

  • 如果一般情况下上传数据少,校验规则也比较简单,耗时短,可以给一个轻量的加载图标;
  • 如果单次导入的数据量大,或者校验规则比较复杂,需要较长的时间,可以给一个上传进度条。在这种情况下,导入任务可以设置成异步处理,即允许用户关闭当前导入窗口,使用软件的其他功能模块。

b端产品设计与实现总结(B端产品设计批量导入)(4)

3.2.2 文件解析和数据逐行校验

一般导入文件的校验分为两个过程:

1)文件格式校验

在写入数据前,首先会校验文件的基本格式是否符合规范,如果不符合则需提示用户检查上传的文件并重新上传。一般会有如下规则:

  • 文件类型:支持的文件类型,如excel文件;
  • 文件大小:是否超出规定的文件大小,如2M;
  • 表头:是否与模板一致;
  • 行数:是否超过规定的上传上限,比如最多允许导入1000行记录,但上传的文件有2000条记录

2)数据内容校验

文件校验通过后,就开始校验逐行表格中的数据内容,一般包括数据格式和业务规则的检验:

  • 数据格式:字段的数据类型、长度,比如某个数量字段,用户填了文字;
  • 业务规则:记录重复、不同字段之间的运算关系、主从逻辑判断等;(比较复杂,会在文章末尾中的案例中提供示例参考)

3.3 导入结果反馈

1)导入结果

反馈用户本次导入的结果状态。

  • 一般“覆盖”导入(即导入的数据会覆盖系统原有数据),对于错误数据,都是全部拦截并进行报错提示;
  • “新增”导入(即导入的数据会在系统原有数据基础上进行新增),一般都只允许正常数据导入,错误数据到出修改,这样可以方便用户快速定位到错误的字段上。

b端产品设计与实现总结(B端产品设计批量导入)(5)

2)错误数据修改

导入失败的数据可以支持单独导出,并在excel中对异常字段进行特别标注,也需附上“错误原因”。(也有文章提过部分情况下可以让用户在线修改,但个人认为这种方式并不好,因为对于由同一个错误引起的大量异常数据,修改效率很低。如果考虑批量编辑功能,开发成本又会变得很高)

3)导入历史(非必须)

部分特殊情况还需要记录导入历史,方便后续查看。

b端产品设计与实现总结(B端产品设计批量导入)(6)

四、分析案例

4.1 产品介绍

一款面向小微企业&个体工商户的ERP进销存管理软件,帮助他们实现业务的数字化管理。(说人话就是,倒买倒卖的中间商每天向哪个供应商买了哪些商品?又向哪个客户卖了哪些商品?仓库里现在又还有哪些货、数量多少?······

成千上万个商品在不同时间、不同客户、不同供应商中积累的价格、数量、金额等信息是海量的,光靠脑子不可能记得住,更不用说去分析一个周期内的销售额、利润!因此软件就是帮助这些中间商记录商品流通过程中的信息数据,更好地掌握生意状况)

4.2 需求背景

我是一名批发商,上次向某个供应商订了一批货,这次供应商把货送了过来,还附了一张单据(可能是电子单据,也可能是纸质单据,不同供应商给的单据格式也不一样,如下图所示),你确认没问题后,把这批货搬进仓库,然后把这个单据录到系统中,一个个选择商品肯定太麻烦了,于是你希望有一个导入功能,帮你把这些数据批量处理掉。

b端产品设计与实现总结(B端产品设计批量导入)(7)

b端产品设计与实现总结(B端产品设计批量导入)(8)

4.3 业务背景

这里提两个比较重要的概念,方便读者更好的理解下面的分析过程。

1)商品唯一性标识

商品条码一般是商品的唯一标识,由商品国际物品编码协会赋予,包含该物品的生产国、制造厂家、商品名称、生产日期、类别、日期等许多信息,在商品流通有广泛的应用。(简单来说就是你去便利店买东西结账,店员用扫码枪“嘀”的那块地方,如下图)

但是对于部分行业,流通的商品大多是非标品,例如茶叶、部分食品、五金件等,也没有条码的概念,只能通过一定的规则(通常是商品名称)去标识一个唯一的商品。

而我们软件定位是泛行业的软件,所以商品条码是商品最高级的唯一标识,却又不是一个必要信息。除此之外,商品名称&规格组合也是一个商品的唯一标识,不可重复。

b端产品设计与实现总结(B端产品设计批量导入)(9)

2)单位

商品单位容易理解,计量商品的标准量,如个、件、箱、米等。值得注意的是,部分商品在实际业务中可能同时存在多个单位,例如300ml罐装的可乐,1“瓶”3元,论“箱”(1箱=24瓶)销售时,1“箱”70元,即同一商品不同单位之间存在换算关系,所以这些商品在商品管理上略微复杂,导入功能设计上也需要考虑到这种情况。

4.4 分析过程

1)用户分析

在过往的用户调研中,我们发现用户大多是四十左右的中年人,文化水平普遍偏低,对于大篇幅的文字说明都不太敏感,可能导入出错的概率会比较高。因此除了功能框架层设计上要简单清晰,还要强化对异常情况的处理提示,让用户一眼就知道导入失败原因在哪以及如何处理。

2)业务场景分析

进货场景下,可能同时会进一些新商品和旧商品(即软件中没有/已有的商品资料),进新商品会新建商品资料,进旧商品会更新库存数量,综合考虑决定“商品名称”和“数量”为必填字段,其他为非必填字段;另外导入数据规模上,产品介绍有提到软件面向的是小微企业主,他们的进货规模根据调研结果,单次大多不超过100个sku,所以导入限制在200~1000行数据就足够了。

3)可能出错情况

由于新旧商品同时存在,因此要考虑的难点除了旧商品与已有商品资料的冲突,还有建立新商品资料的业务规则冲突。需要分别穷尽所有的出错情况,并根据出错场景,来决定哪些需要软件自动处理这些错误,哪些需要导出让用户确认修改这些错误。

分析到这里,差不多一个完整的导入功能流程就呼之欲出了。

4.6 功能流程图

b端产品设计与实现总结(B端产品设计批量导入)(10)

4.7 原型设计&说明

这里就不贴原型了,网上资源多的是。主要讲讲其中的核心部分:数据内容的逐行校验与提示。

由于公司保密制度规定非常严格,无法把PRD全部贴上来,这里简单提几个可能的业务规则校验供大家参考:

  • 不同供应商品名:系统商品资料存在这个条码,但对应的商品名称不同(比如一罐可口可乐,供应商A叫“可口可乐”,你录到系统里也命名为“可口可乐”,但你这次又从供应商B那里进了这个商品,他给你的单据上显示名称为“可口可乐300ml”)
  • 旧商品新单位:商品条码、名称与系统一致,但该商品没有此单位
  • 运算关系冲突:多个字段之间存在运算关系,但用户上传的数据不符合计算逻辑,比如单价*数量≠金额
  • ······

值得注意的是,上面提到的业务规则校验,并不是所有都要当错误处理,有些可以让程序自动处理,提高用户的产品体验。

b端产品设计与实现总结(B端产品设计批量导入)(11)

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

题图来自 unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

,