批量导入功能设计分析

Recommand
深圳/设计爱好者/3年前/4142浏览
批量导入功能设计分析Recommand

本文主要就批量导入功能各个环节做了详细的分析,并结合所做项目及市面相关产品,给出了一些示例样式作为参考。

文章字数9000+字,29 图,建议配茶饮用~

温馨提示:以下内容主要以实际产品功能设计和网络上的相关文章为参考,以及体验了市场上比较知名的几款产品,包含个人理解与思考,非绝对、非标准。如写有误,欢迎指正~各位大佬如果有好建议,欢迎分享赐教~灰常感谢呀(●ˇ∀ˇ●)

文章有点长,如果不想看那么文字,可以重点关注第五个部分,下面有目录可以检索,感谢你的阅读~

前言

因为实际在做B端产品项目中,有多个产品涉及到了“批量导入”的功能设计,所以就干脆做了一次总结

批量导入功能一般是用来处理大批量数据的有效方法,通常与表格相结合,批量导入按钮入口一般位于表格的左上角或右上角,既然能批量导入,大多数情况下也是支持单条数据手动录入的,所以通常情况下会有批量导入+新增/添加两个按钮组合,根据业务需求,也许还有一些其他的按钮,比如:下载批量导入模板;查看批量导入记录(这两个按钮可以与批量导入按钮放在一起,也可以放在点击批量导入弹窗里面,具体根据需求规范来定);其他操作按钮。

另外,批量导入记录或者导入任务也可以放在单独的菜单里面,但是要定位好导入的数据属于哪个功能模块,并且还要考虑权限的问题,这样用户能够快速的查找。

上图仅为示例图,实际场景为了方便数据的检索与查阅会结合其他的功能设计,比如模糊搜索、高级筛选、标签切换、字段设置等其他操作。

1、批量导入功能设计背景

1.1 产品需求

批量导入功能一般常见于B端产品中,数据层作为B端产品的基础,免不了要处理各类不同的数据,包括日常维护,增删改查,运营管理,分析追踪等。

如果需要快速录入上百条数据,一般有一定经验的同学,立刻会想到批量导入功能。

项目的落地离不开产品、设计、前端、后端的支持,因各方侧重点不同,导致功能实现出来的效果不尽如人意,为确保各产品中的体验保持一致,因此考虑制定统一的解决方案,最终沉淀为规范的设计组件,为各个产品的研发提供有价值有分量的设计支持。避免重复开发,并且能快速实现功能统一。

但值得注意的是,各个产品的需求不一样,批量导入功能交互设计也不尽相同,细节上面会有一些不同,只要是满足需求,遵循设计规范都可。后文中也会提供一些样例可参考。

1.2 运营需求

单一的数据录入功能,不仅影响工作效率与体验感,增加数据录入成本,同时还容易加大数据录入错误几率。
批量导入功能采用Excel批量整理数据,不仅可以快速复制粘贴相同字段,提高多人协作填写效率,还可以及时的对数据进行维护。达到提高效率,降低成本,控制风险的目的。

批量导入对于提高操作效率,降低人力成本,控制录入风险有重大意义。

2、批量导入功能存在的误区

就这个功能本身而言,一般表现出来的逻辑会比较简单:上传文件→弹出一个本地文件选择框→选择文件→完成数据导入

3、常见的数据批量导入场景

但实际上需要根据产品的业务需求场景来考虑数据导入过程中的各个环节,不仅要考虑当前情况,还要考虑未来有没有可能和其他系统产生紧密的联系,否则容易出问题,影响用户操作体验。
常见的数据批量导入场景包含数据批量初始化、数据批量迁移、数据批量维护等。

3.1 数据批量初始化

数据批量初始化:产品系统升级之后,增加一些新的功能,原来线上没有数据,需要批量导入线下整理的Excel数据;

3.2 数据批量迁移

数据批量迁移:产品系统升级之后,需要迁移老系统的大量数据到新系统;

3.3 数据批量维护

数据批量维护:根据业务需求,对原来老系统的一些数据表模板进行了更新,比如增加了新的字段,或者批量增加数据标签,那么就需要下载老系统的数据进行统一更新并重新导入。

4、数据导入过程中遇到的一些问题

00、数据上传采用的是同步处理还是异步处理
01、是否考虑版本和浏览器的兼容性
02、上传文件支持的格式?
03、对上传文件大小是否有限制?
04、是否允许多次上传数据文件?
05、如果多次上传,那么是采用追加还是覆盖
06、上传过程中是否进行数据校验
07、如果导入的数据有部分正确,部分错误,该如何处理?
08、如果数据有误,改如何提示给用户?
09、有问题的数据采用何种方式方便用户再次上传?
10、导入的数据如果与原有数据冲突时,该如何处理?
12、导入的数据该如何展示
13、展示的时候允许用户同步修改吗?
14、是否留有错误报告下载入口?

B端产品复杂多样,所以我们将批量导入各个环节做大致的区分,然后再根据每个环节的特点去细致分析操作过程中可能遇见的问题,这样在以后的设计中,即使业务需求逻辑不同,也能更清晰透彻的理解复用批量导入功能设计。

5、批量导入功能具体分析

功能设计是本篇文章的重点,通过上面的分析,我们应该对批量导入功能设计做全面的思考,对导入前,导入中,导入后三个环节里可能遇见的问题进行提前预设,以便给予用户更好的功能体验,满足用户的核心诉求即便捷性和准确性。

5.1 导入前

第一步 设计数据录入模板

首先需要设计一份数据录入模板,设计前与业务方产品方沟通,确认数据录入模板里面包含的字段,同时制定相关字段维度及录入规则,确定录入数据字段格式及属性,详细告知用户录入规则

将网页表单输入的要求映射到Excel单元格中,并着重考虑数据的完整性和规范性。一份录入规则清晰且容易维护的数据模板,不仅能提高用户填写数据的效率,同时能有效降低后期数据导入错误率。

关于设计数据录入模板的问题我将从以下几个方面详细举例展开说明:具体分析可参考下面不同产品中的导入模板示例图,分别来自飞书、钉钉、有赞。有兴趣的同学可以亲自去体验一下产品。

支持下载上传的模板格式

第一种:.xlsx / .xls 格式模板 支持自由定义
第二种:.csv 格式模板 仅支持文本
这里展开说说关于.xlsx / .xls与.csv的格式区别,主要区别在于分隔符编码。具体总结有三点:
a、csv 是纯文本,体积小,容易导入到各种PC表格及数据库中,方便创建分发读取。
b、xlsx、xls 是二进制的文件,用Excel才能打开。xls是03版Office支持的,xlsx是07版Office文件格式。
c、csv 数据表字段用“半角逗号”隔开,以ascii码编码,每一行数据以回车符隔开,xls、xlsx字段之间的分割符是tab.。
这块内容涉及开发知识,参考网友总结的。

模板的结构样式

结构一般由3部分组成:填写须知、表头、示例数据

(1)填写须知

如飞书管理后台-用户导入模板,填写须知是放在表格第一栏;
如钉钉客户管理-企业客户_导入模板,填写须知放在另外一个sheet中;
如有赞模板-批量导入客户,填写须知是逐条放在表头上方,没有示例数据部分。

实际产品中,建议还是增加示例数据,示例数据尽可能真实,这样能更好的引导用户正确填写录入数据,提高正确率。
还有一些是将各个字段的填写规则备注在各个字段输入框内,这样做的优点是所见即所得,看完一条规则完成一列数据的填写,比较谨慎,不容易出错,缺点是字段填写须知是隐藏的,需要用户定位到输入框内才能看到,影响填写效率。

示例图还做了关于字段值填写失败的校验提示。关于数据验证的类型可以参考腾讯文档使用教程,里面有比较详细的解释说明。

(2)表头

这里主要强调的是表头字段格式。字段数量及具体内容根据业务需求来定,一般为锁定状态不可更改,主要分为必填项和非必填项,必填项一般会用特别标注出来。

如飞书管理后台-用户导入模板,必填项是用暗红色背景,同时在填写须知里面说明“标红字段为必填项,黑色字段为选填项”;
如钉钉客户管理-企业客户_导入模板,必填项字段文字标为红色,同时在填写须知里面说明“必填性:Excel中“红色”字段为必填字段,“黑色”字段为选填字段,是否必填是由管理员的表单设置决定的”;
还有一些其他的必填样式,比如“*”号,文字标注必填等等。样式没有限制,只要能清晰的标明必填选填满足用户填写诉求就可以。


对于一些关键字段要设置明确的填写规则,以引导用户高效无误的录入相关数据。如手机号字段必须是11位数字,性别必须是男、女中的一个值;

有一些字段需要精确到最小颗粒度,比如日期是用年月日YYYY-MM-DD,还是年月YYYY-MM,所在地址是用国家-省份-城市,还是直接用城市,这些都是要在填写须知里面写清楚。
如果是多个字段尽量不要混在一列中,否则校验数据的时候,需要先将数据拆分,才能对单个数据进行校验,增加数据校验的复杂度。如国家、省份、城市应该分成3列,而不是一列。

一些特殊字段需要用到逗号,分号,括号等不同的符号,而中英文的符号在代码中表现不同,为了更好的识别校验,最好还是明确输入语言。如飞书管理后台-用户导入模板中”部门负责人:请填入「是」、「否」,若不填则默认为「否」,若归属于多个部门请用英文“undefined”隔开;”这里就强调了要用英文逗号隔开。


对于固定选项的字段,根据业务场景特定设置的一些字段,提供选择,而非输入,这样有利于用户快速操作,比如飞书用户导入模板里面有一项是填写人员类型,在须知里面已经说明“人员类型:请从下列选项中选填一个选项:「正式」、「实习」、「外包」、「劳务」、「顾问」,若不填则默认为「正式」;”那么在模板中就可以提前设置选项,用户录入数据的时候直接选择就可以了,如下图:

控制表格数据量大小

文件大小看校验能力以及等待时长,目前对于上传数据条数接口没有限制,服务器有限制

为了节省服务器的空间和提高文件传输的速度,需要限制上传文件的大小,建议不要过大。

有一些模板在填写须知里,告知相关规则,如建议最多导入5000条数据,数据量过大影响导入速度;

如果需要限制文件大小,则要在页面上明确告知用户,如“当前版本单次最多只允许上传5000条数据且文件大小不超过100M”。

这些规则将关联后面数据校验。

模板版本

这里想说明的版本问题,主要有两点:

第一点是版本的兼容性
因为用户使用的软件有差异,所以应该考虑各个软件版本间的兼容性。例如Office与WPS办公软件,理应支持各版本xls、xlsx格式的Excel表,一般在操作过程中,大多数人喜欢另存文件,根据本地所使用的软件不同,格式也会有差别。

第二点是模板版本迭代
因为随着企业的发展,产品会进行迭代升级,功能也会相应的出现新增或删减,这个时候如果关联的字段数据发生了变化,就需要前后端对数据模板进行重新设置,为了更好的查阅历史变更记录,需要对模板版本进行存储,并提供最新的模板给用户下载,同时也要以书面形式告知用户模板版本更新了,防止用户依然用本地存储的旧模板。

模板文件命名

命名虽然是很小的一件事,但却是很关键的一件事,清晰易辨识的文件名能够被用户快速找到,并且在上传文件的时候不易出错。

最终使用模板的不一定是专业的业务人员,B端产品很多时候是多个业务系统相互关联的,而且后期维护的时候还涉及到运营人员,所以相关规则一定要提前设置好,这样可以在产品上线后省去很多麻烦,也不易被用户挑战。

导入模板是前端导入创建数据,后端分发数据的基础,所以上面用比较大的篇幅来分析讲解数据导入模板的设计。

第二步 数据创建规则

其次是确定数据创建的规则,这些规则的制定也需要与业务产品方沟通,同时需要考虑前后端的数据处理逻辑,必要时也需要前后端研发人员一起参与制定。创建规则主要包含数据的处理、校验、创建,下面我们就这三个方面进行具体说明。

数据处理

为了能顺利的创建数据,在提供了批量导入功能后,需要提供相应的数据处理功能。
根据后端响应时间,处理的方式有同步和异步两种同步和异步是开发技术中的两个概念,计算机通过解析和运行程序完成相应的操作。
虽然同步或者异步处理是数据导入时应该考虑的,但是我个人认为在了解业务需求及后台系统性能的情况下,应该提前确定好数据处理方式,以便产品设计给出最优解决方案。

同步处理

同步处理是按顺序处理,前端发起请求后,后端必须即刻响应,即时返回结果。且同一时间只执行一个简单任务,任务处理完后再执行第二个任务,同步处理适用于数据量较少时,后台校验的逻辑简单的任务。导入结果一般是在任务结束后同步返回给用户。

操作路径:用户在前端发起批量导入的请求 → 后端接收请求并处理 → 一定时间内返回处理结果 → 前端用户查看结果

优点:请求任务流程单一有序,响应时间短,用户能及时的看到结果。

缺点:如果数据量过大,导致用户等待时间过长,很有可能因为响应超时而导入失败,给用户带来负面感受,达不到用户预期;如果用户不小心关闭了页面,处理会中断,从体验上对用户不够友好。

例如创客贴里面的上传素材,TDesign中关于如何设计高频任务中的批量文件导入示例。

异步处理

异步处理是并行处理,前端发起请求后,后端先接收请求,可以在系统空闲时间处理。且同时可以处理多个任务,适用于数据量大,校验复杂,系统关联逻辑比较多的批量导入任务。导入结果一般是在单个任务或全部任务完成后以msg的形式通知用户。

操作路径:用户在前端发起批量导入的请求 → 后端接收请求 → 等待空闲时间处理 → 返回处理结果(无时间限制) → 前端用户查看结果

优点:后端处理请求的过程中,用户可关闭当前页面,去做其他事情,避免用户长时间等待;后端返回结果的时间没有限制,还能降低导入失败的概率,用户体验更好。

缺点:因用户在导入后不能马上看到结果,不能及时的修改错误数据,影响数据的快速有效创建。ps:如果对创建数据时间等完全没要求,这也算不得缺点hhhh~

例如多麦营销系统,从下图可以看出,有专门的任务列表菜单,可以随时查看导入进度,有问题的数据也会被详细记录,并提供失败报告下载功能入口。

一些企业使用像企业微信、钉钉、飞书等一些第三方平台,导入结果也会以通知消息的形式发送给用户。

比如导入成功:
【XX后台系统】您“2021-07-29 19:16:39”提交的“批量导入企业客户”任务已完成,共100条数据,100条导入成功。查看详情>

比如导入失败:
【XX后台系统】您“2021-07-29 19:16:39”提交的“批量导入企业客户”任务已完成,共100条数据,35条导入失败。查看详情>

数据校验

数据能够被创建是需要遵循一定的校验规则的,不管是批量导入表格还是单条数据录入,校验规则必须保持一致。值得注意的是数据的追加、覆盖、删除等规则都需要写在填写须知里面告知用户,对于一些必填项但遇到无法提供字段值的情况应告知用户填写“-”或者“/”等类似符号,如果用户不填写空着,系统将会校验失败。

用户的核心诉求是快速将数据录入系统,那么我们的解决方案应充分围绕核心需求来设计。

数据批量导入时需要遵循以下几个校验规则:

通用校验规则

校验类型包含:必填校验、格式校验、范围校验

必填校验是指校验表头字段标记“*”必填星号或者背景标红(颜色自定义)的字段,字段值填写是否为空。

格式校验是指校验表头字段为日期、时间、ID、身份证号、手机号、金额、数量、链接等具有一定特殊格式的字段,字段值是否填写正确。如国内手机号仅允许填写11位,如果填写的手机号少于或多余11为,那么就会校验失败。

范围校验是指校验表头字段为时间范围、字数限制、字段取值等具有一定限制区间的字段,字段值是否填写正确。如公司今年需要招聘实习生,那么毕业时间就应该限制在2022年-2023年之间,如果填写的时间不在这个取值范围,那么就会校验失败。

有一些特殊的字段,字段逻辑比较复杂,校验顺序应该是必填校验→格式校验→数据重复校验。

特殊校验规则

数据导入时,如何报错?

用户在导入的时候无法保证录入的数据百分百正确,如果其中部分数据正确,部分数据错误,通常有两种处理方法:

第一种是数据校验有误时,不允许被导入
数据之间是相互关联的,单条数据的异常会影响其他待导入的数据,那么就应该终止导入。

第二种是允许导入校验正确的数据,错误数据提供可修改入口,用户修改后重新创建
提供错误数据修改的方式常见的有两种,如下图所示:

方式一:在显示导入结果的时候返回一个excel失败/错误报告,供用户下载。产品需提前设计错误报告表格格式。
需要注意的是通常错误报告表格最后一栏会标注数据导入失败的原因,全部修改后可重新导入。失败原因那一栏可以不要求删除,但要与开发说明,读取数据的时候失败原因那一栏不读取。当一条数据有多个错误,需要用中文逗号隔开“,”。如:手机号错误,毕业日期超出规定范围,毕业状态不存在。

这种方式的优势是可以处理大批量的数据,当错误数据较多时,方便用户一次性修改错误的数据。

缺点是对于用户而言操作步骤较复杂,需要用户下载错误报告,再进行修改。这里可能存在重新导入后还是有问题的情况,那就需要重复多次下载错误报告,直至数据完全正确后导入成功。

方式二:是指用户导入数据表格后,表格里面的内容会显示在前端页面,错误数据标红显示。用户可直接在线上进行编辑,修改错误数据并重新创建。这里需要注意的是上图弹窗里面的数据校验规则同导入模板中的字段数据校验规则是一致的

这种方式的优势在于用户导入的数据量较少且不复杂的时候修改起来更方便,不需要下载错误报告线下进行修改再重新导入,可以直接在列表页面上编辑修改。

缺点在于不适用于数据量较大错误想较多的场景,让用户单个数据进行在线修改没有直接下载错误报告excel表格来的简单。对于开发来说,这种方式工作量大,如果项目上线紧急,不建议使用此方案。

除了以上两种,还有可能会出现像“网络问题”“服务器问题”“系统性能问题”等情况,出现以上任意情况也会导致导入出错,但其处理方法是一样的,那就是重试重新发起数据导入任务。

数据创建

前面已经讲了数据的处理和校验,即导入前根据业务需求确定好数据导入的方式及校验规则。接下来要讲数据的创建,这里涉及到新旧数据,数据的多次导入问题,数据导入后并不是一成不变的,根据项目迭代或是字段更新,数据再次导入的时候需要采取相对应的处理措施。

这里列举了两个常见的问题,如下:

数据导入时,是追加还是覆盖?

追加:不管系统里面有没有旧数据,也不管新导入的数据和旧数据有没有冲突,每次重新导入数据时,系统将保留旧数据,并创建新数据。
追加的优势:避免了复杂的导入规则,不要求数据具有唯一性,对系统环境要求低。
追加的劣势:因为是追加,意味着不能通过批量导入的方式修改已创建的数据,只能做单条数据的修改。比较耗时耗力,不适用于数据量较大的情况。

覆盖:不管系统里面有没有旧数据,每次重新导入时,都覆盖旧数据,仅以最新一次导入的数据为准。旧数据将会被删除,并创建最新导入的数据。
覆盖的优势:对于用户来说可以轻松的更改旧数据,对于开发来说难度和工作量都比较小。
覆盖的劣势:导入新数据的同时旧数据将会被删除,风险比较大,如果旧数据关联其他系统数据,可能会造成较大的影响。

数据的追加还是覆盖需要考虑设置审核机制,增加权限门槛,以免造成数据混乱。从产品安全角度考虑,为了能更方便进行数据的增删改查,也为了后续的数据追踪查证,可提供数据导出和导入记录入口。

综上所述,在批量导入功能设计的时候,既要考虑易用便捷性,也要考虑数据的安全性,同时也要思考当前数据与数据,数据与各个系统的的关联性,未来有没有可能和其他系统产生密切的关联。

数据导入时,如果有重复数据怎么处理?

一般会有两种处理方式,第一种是将数据中的具有唯一特性的字段作为唯一标识,如果新导入的数据与旧数据ID相同,可允许覆盖旧数据。如果想新建数据且保留旧数据,则允许跳过,但同时需要将ID相同的那条数据进行标记失败,失败原因是与系统中数据重复。

另一种方式是在不影响数据正确创建的情况下,允许用户自由选择数据的处理方式。

下面我们将进入重要的导入数据环节。

5.2 导入中

导入数据的基本步骤

导入数据的步骤一般是:下载模版→上传文件→处理数据→返回结果

由于大量数据是以Excel表格来承载的,因此需要根据前面设置的校验规则来校验每个数据。以确保导入的数据是符合规范且完全正确可创建的。
有些产品前期做了格式过滤,选择文件的时候自动识别文件格式,那么这样就可以省去文件格式的校验。
文件导入后显示处理进度,提升用户使用安全感。
导入过程中有一些具体的交互操作细节会在下文中以图文的形式呈现。

这里展示的报错方式和前文展示的不太一样,关于样式的问题可以根据产品要求自由发挥。
下面我将展示一些产品的批量导入流程图供大家参考。

其他案例

批量导入功能设计还有一些其他的样式,如下图所示:

飞书这个批量导入人员的弹窗步骤图上没有主操作按钮,上传文件的同时创建数据,提示也是在当前窗口。这种交互方式比较简单,适用于数据量较少,校验逻辑较简单的批量导入。

钉钉这个批量导入企业客户是在页面上分步骤,上传文件后直接在当前页面上显示文件数据,并且可以进行重复校验,校验后可继续导入,最后会在页面显示导入结果,有两个操作按钮“重新导入文件”、“下载失败文件”。

感兴趣的可以实际操作一下,会有不同的体会。

5.3 导入后

导入后就要给用户反馈结果,用户关心的是数据是否全部导入成功,导入成功分全部导入成功和部分导入成功,全部导入成功意味着数据全部正确,部分导入成功意味着数据部分正确部分错误,那么对于导入失败的数据就需要明确告知用户失败的原因及修改的方法,总结来说就是要进行数据核对及错误数据修改。

数据核对

人工手动录入的时候,难免会出现错误的数据,比如字段值不合法、数据重复、字段值漏填、字段值填写不符合规范等,出现以上任一情况,数据将无法正确的一次性顺利创建成功,因此为了便于用户更好的知晓错误发生的详情,就有必要告知用户导入成功、导入失败各导入重复的数量,其总和确保和数据总数量一致。

给用户反馈清晰直观的导入结果,有利于数据的成功创建,更能提高数据录入的正确率。
相反如果不核对导入数量,仅仅直接反馈导入结果如“导入成功”或者是“导入失败”,会让用户疑惑,用户还要通过其他路径查询相关导入结果,不仅体验不佳,更容易造成数据混乱。

上面的样式是以弹窗的形式展示导入结果的。
下面这种样式来自飞书管理后台,这种是直接在页面上展示导入结果的。
当然还有msg、消息通知、任务列表记录等方式展示结果的,具体样式根据产品需求及设计规范来定,没有特定的要求。

错误数据处理

数据导入后会返回导入结果,根据结果制定相应的处理措施。结果显示导入失败的时候需要进一步处理,直至数据全部正确创建。
一般有错误数据的时候,随导入结果会返回一个excel失败报告或者是失败记录表格,文件中会记录错误的数据,并且会标记失败的原因,用户可以快速定位并修改数据,以便可以再次导入。

具体的样式前文已提供。

5.4 批量导入功能设计步骤总结

功能设计需遵循产品整体设计规范。

  1. 设计批量导入模板:制定填写说明及规则;
  2. 确定导入规则:同步或者异步、追加或是覆盖、何时报错、制定校验规则等;
  3. 选择文件导入:思考上传文件后是直接创建数据还是先审核文件再导入数据;
  4. 展示结果:页面上反馈、弹窗反馈、msg形式反馈等;
  5. 页面数据展示:导入后是直接展示在数据列表,还是先在当前页面展示复核正确后再展示在列表页。

6、B端批量导入功能价值思考

B端产品一般是为企业组织服务的,终极目标是“赋能”,而批量导入功能其重要价值是提高企业的办公协同效率,释放人力,减少企业和个人的时间成本。

批量导入的交互样式因产品不同,样式也会有所差别,但功能目的是一致的,具体样式还应结合实际产品需求来设计。

注:文章中可能存在一些错误,如果各位大佬对文章中内容有更好的建议,欢迎一起交流~

67
Report
|
162
Share
相关推荐
评论
in to comment
Add emoji
喜欢TA的作品吗?喜欢就快来夸夸TA吧!
推荐素材
You may like
IP设计合集 DGS FRIENDS
Homepage recommendation
装东西Packing.
Homepage recommendation
相关收藏夹
读
读
读
读
作品收藏夹
24
ue
ue
ue
ue
作品收藏夹
ue
21
作品集
作品集
作品集
作品集
作品收藏夹
B端产品
B端产品
B端产品
B端产品
作品收藏夹
学习
学习
学习
学习
作品收藏夹
大家都在看
Log in