批量导入是B端后台产品中非常常见的功能，乍看大略，但实际做起来才创造里面的坑其实不少。笔者根据自己的事情经历，记录整理了当时从0到1的设计过程。内容较长，耐心看完，相信你一定会有所收成！
一、业务剖析
在开始任何B端产品的功能设计前，都须要先剖析这个功能对应的业务场景以及想办理的业务问题。
批量导入也不例外，一样平常导入功能都涌如今须要单次录入大批量数据的后台产品中。根据不同的场景会有不同的运用，须要结合用户特色来一起剖析，它们共同决定了导入功能的软件功能流程和基本逻辑，例如：
这些都是在业务剖析阶段就须要思考的事情！
二、导入流程
导入功能大致可以分为3个环节
导入指引：让用户理解若何利用导入功能，并给出一份模板文件；导入文件：上传文件，并校验缺点数据；结果反馈：让用户知道本次导入的结果&影响。个中2是最麻烦最繁芜的一环，由于除了常规的文件类型和数据格式校验外，部分B端产品可能还会有一些业务上的限定，须要考虑到导入的数据与现有的业务规则是否冲突，如果存在冲突，要以何种形式奉告用户哪些数据非常、要如何处理。
三、功能设计3.1导入指引
3.1.1导入指引
如果导入过程并不繁芜，只须要给出***模板和上传文件的入口即可；如果流程比较长，须要给出一条明确的步骤指引。
3.1.2模板解释
对付一些主要的系统哀求或者是不易察觉的设置，须要在表头上进行解释，勾引用户精确的填写数据。
3.2导入文件
3.2.1 导入进度
根据导入数据的规模和校验规则的繁芜程度，须要考虑不同的上传进度提示。（这些最好提前与研发职员沟通好）
如果一样平常情形下上传数据少，校验规则也比较大略，耗时短，可以给一个轻量的加载图标；如果单次导入的数据量大，或者校验规则比较繁芜，须要较长的韶光，可以给一个上传进度条。在这种情形下，导入任务可以设置成异步处理，即许可用户关闭当前导入窗口，利用软件的其他功能模块。3.2.2 文件解析和数据逐行校验
一样平常导入文件的校验分为两个过程：
1）文件格式校验
在写入数据前，首先会校验文件的基本格式是否符合规范，如果不符合则需提示用户检讨上传的文件并重新上传。一样平常会有如下规则：
文件类型：支持的文件类型，如excel文件；文件大小：是否超出规定的文件大小，如2M；表头：是否与模板同等；行数：是否超过规定的上传上限，比如最多许可导入1000行记录，但上传的文件有2000条记录2）数据内容校验
文件校验通过后，就开始校验逐行表格中的数据内容，一样平常包括数据格式和业务规则的考验：
数据格式：字段的数据类型、长度，比如某个数量字段，用户填了笔墨；业务规则：记录重复、不同字段之间的运算关系、主从逻辑判断等；（比较繁芜，会在文章末端中的案例中供应示例参考）3.3 导入结果反馈1）导入结果
反馈用户本次导入的结果状态。
一样平常“覆盖”导入（即导入的数据会覆盖系统原有数据），对付缺点数据，都是全部拦截并进行报错提示；“新增”导入（即导入的数据会在系统原有数据根本上进行新增），一样平常都只许可正常数据导入，缺点数据到出修正，这样可以方便用户快速定位到缺点的字段上。2）缺点数据修正
导入失落败的数据可以支持单独导出，并在excel中对非常字段进行特殊标注，也需附上“缺点缘故原由”。（也有文章提过部分情形下可以让用户在线修正，但个人认为这种办法并不好，由于对付由同一个缺点引起的大量非常数据，修正效率很低。如果考虑批量编辑功能，开拓本钱又会变得很高）
3）导入历史（非必须）
部分分外情形还须要记录导入历史，方便后续查看。
四、剖析案例4.1 产品先容
一款面向小微企业&个体工商户的ERP进销存管理软件，帮助他们实现业务的数字化管理。（说人话便是，倒买倒卖的中间商每天向哪个供应商买了哪些商品？又向哪个客户卖了哪些商品？仓库里现在又还有哪些货、数量多少？······
成千上万个商品在不同韶光、不同客户、不同供应商中积累的价格、数量、金额等信息是海量的，光靠脑筋不可能记得住，更不用说去剖析一个周期内的发卖额、利润！
因此软件便是帮助这些中间商记录商品流利过程中的信息数据，更好地节制买卖状况）
4.2 需求背景
我是一名批发商，上次向某个供应商订了一批货，这次供应商把货送了过来，还附了一张单据（可能是电子单据，也可能是纸质单据，不同供应商给的单据格式也不一样，如下图所示），你确认没问题后，把这批货搬进仓库，然后把这个单据录到系统中，一个个选择商品肯定太麻烦了，于是你希望有一个导入功能，帮你把这些数据批量处理掉。
4.3 业务背景
这里提两个比较主要的观点，方便读者更好的理解下面的剖析过程。
1）商品唯一性标识
商品条码一样平常是商品的唯一标识，由商品国际物品编码协会授予，包含该物品的生产国、制造厂家、商品名称、生产日期、种别、日期等许多信息，在商品流利有广泛的运用。（大略来说便是你去便利店买东西结账，店员用扫码枪“嘀”的那块地方，如下图）
但是对付部分行业，流利的商品大多是非标品，例如茶叶、部分食品、五金件等，也没有条码的观点，只能通过一定的规则（常日是商品名称）去标识一个唯一的商品。
而我们软件定位是泛行业的软件，以是商品条码是商品最高级的唯一标识，却又不是一个必要信息。除此之外，商品名称&规格组合也是一个商品的唯一标识，不可重复。
2）单位
商品单位随意马虎理解，计量商品的标准量，如个、件、箱、米等。值得把稳的是，部分商品在实际业务中可能同时存在多个单位，例如300ml罐装的可乐，1“瓶”3元，论“箱”（1箱=24瓶）发卖时，1“箱”70元，即同一商品不同单位之间存在换算关系，以是这些商品在商品管理上略微繁芜，导入功能设计上也须要考虑到这种情形。
4.4 剖析过程
1）用户剖析
在过往的用户调研中，我们创造用户大多是四十旁边的中年人，文化水平普遍偏低，对付大篇幅的笔墨解释都不太敏感，可能导入出错的概率会比较高。因此除了功能框架层设计上要大略清晰，还要强化对非常情形的处理提示，让用户一眼就知道导入失落败缘故原由在哪以及如何处理。
2）业务场景剖析
进货场景下，可能同时会进一些新商品和旧商品（即软件中没有/已有的商品资料），进新商品会新建商品资料，进旧商品会更新库存数量，综合考虑决定“商品名称”和“数量”为必填字段，其他为非必填字段；其余导入数据规模上，产品先容有提到软件面向的是小微企业主，他们的进货规模根据调研结果，单次大多不超过100个sku，以是导入限定在200~1000行数据就足够了。
3）可能出错情形
由于新旧商品同时存在，因此要考虑的难点除了旧商品与已有商品资料的冲突，还有建立新商品资料的业务规则冲突。须要分别穷尽所有的出错情形，并根据出错场景，来决定哪些须要软件自动处理这些缺点，哪些须要导出让用户确认修正这些缺点。
剖析到这里，差不多一个完全的导入功能流程就呼之欲出了。
4.6 功能流程图
4.7 原型设计&解释这里就不贴原型了，网上资源多的是。紧张讲讲个中的核心部分：数据内容的逐行校验与提示。
由于公司保密制度规定非常严格，无法把PRD全部贴上来，这里大略提几个可能的业务规则校验供大家参考：
不同供应商品名：系统商品资料存在这个条码，但对应的商品名称不同（比如一罐适口可乐，供应商A叫“适口可乐”，你录到系统里也命名为“适口可乐”，但你这次又从供应商B那里进了这个商品，他给你的单据上显示名称为“适口可乐300ml”）旧商品新单位：商品条码、名称与系统同等，但该商品没有此单位运算关系冲突：多个字段之间存在运算关系，但用户上传的数据不符合打算逻辑，比如单价数量≠金额······值得把稳的是，上面提到的业务规则校验，并不是所有都要当缺点处理，有些可以让程序自动处理，提高用户的产品体验。
本文由 @飞鱼 原创发布于大家都是产品经理，未经容许，禁止转载
题图来自 unsplash，基于 CC0 协议
该文不雅观点仅代表作者本人，大家都是产品经理平台仅供应信息存储空间做事。
