设计导出功能，这三点需牢记

先来看一个假设的场景，小明是某B端数据产品的产品同学，前段时间收到了很多用户关于“导出”功能的需求反馈，分析后得出增加导出功能可以解决用户的问题，为用户带来价值。为此花了一个迭代周期，上线了导出功能。

但是功能上线后，就收到了用户不好的反馈，用户认为“导出功能”虽然解决了数据导出的需求，但是增加了他们关于“数据安全”的风险，产品内的任何账号都可以进行导出动作，无法对账号进行“是否可以导出”的管控，会存在数据泄漏的风险。例如员工A在真实业务场景中不被允许直接拿到买家数据，但员工A通过“导出功能”拿到了订单明细中的买家信息，泄露给竞争对手后导致买家流失，从而造成了业务团队数十万甚至上百万的损失。

为了避免造成损失，用户只好暂时停止使用该产品，希望尽快解决这个问题，甚至有可能造成该用户转用其他产品从而造成了流失。这个场景下，就是小明同学在设计导出功能时，缺少了对“导出权限”的思考，导致原本希望帮用户解决问题的功能，反而给用户带来了损失，也给整个产品带来了损失。

“导出权限”是我们在设计导出功能时具体需要关注的点，事实上，除了“导出权限”外，在整个导出流程中，我们需要注意的点还有很多，本文想从“导出前”、“导出中”、“导出后”3个环节和大家讨论分析需要注意的点。

一、导出前注意的点

导出前的定义，即用户在发起导出（点击导出按钮）前这个环节，那么设计导出功能在这一环节需要考虑什么呢？我认为需要考虑2点内容，一是“导出权限”的思考；二是“导出颗粒度”的思考。

1. 导出权限

在设计导出权限的时候，首先可以思考的是“用户是否可以导出”，即用户能否通过“导出”功能将产品内的数据导出到本地，具体分为两种结果，可以导出与无法导出，而在具体的实现方案上通常会有两种做法。

第一种是对“导出”功能做按钮级别的控制，通过控制了用户是否可见“导出”，从而实现控制“用户是否可以进行导出”，但是并没有对导出数据进行控制，意味着用户只要有导出入口，就能导出所有数据。这种做法优点是配置简单同时传递给用户的也便于理解，只需要对不同账号设置是否有“导出”即可，有“导出”就能导出数据。但是无法对导出的情况做更精细化的区分。

第二种是利用“数据”来实现对用户导出结果的控制，当用户拥有某一数据权限时，就可以通过“导出”拿到这部分数据，但是并没有对“导出”进行控制，用户都可以见到“导出”并使用“导出”，最终导出可见的数据，就是用户数据权限可以见到的数据。这种做法的优点，可以对“导出”结果做更精细化的区分，比如有个人数据权限的用户能导出个人数据，而有个人、团队数据权限的用户能导出个人和团队的数据。但是需要依赖产品内有成熟的数据权限，用户对于该方式的感知也没有那么直接，需要用户去理解“有某一个数据权限就能导出这部分的数据”这层意思。

这两种做法的差异在于，“导出”是否透出给用户可见，以及控制全部数据还是部分数据。在实际业务场景中，这两种做法通常是组合使用的。

案例：

一起来看一组案例，某公司自建了一款地推工作台的应用，方便“地推团队”日常工作收集信息。地推成员通过“工作台-新建客户”录入客户线索，字段包括：客户姓名、客户规模、客户电话、客户地址、客户等级等字段。

地推主管通过“客户信息”菜单审核收集上来的客户线索，审核结束后，财务来计算地推成员的绩效，财务提出希望可以增加“导出”功能，方便直接导出数据后在Excel内进行统计计算。

在这个案例中“地推主管”和“财务”都可以看到客户数据，而两个角色的区别在于“财务”需要将数据导出到本地进行绩效核算，“地推主管”不需要将数据导出。所以产品团队在“客户信息”菜单增加了一个导出按钮，并对“导出”按钮做了控制，财务角色的账号拥有“导出”权限，地推主管角色没有“导出权限”，这就是对“导出”功能做按钮级别的控制在实际场景中的应用。

后来公司业务发展，地推团队不但需要收集客户线索，还需要对“审核通过”后的客户线索进行日常跟进和回访。对于地推成员，需要在“客户信息”菜单查询地推主管审核后分发给自己的客户线索，并将数据导出到本地后打印，方便外出拜访客户时可以用纸质携带客户资料。因此也需要导出权限，但是当前产品通过“按钮”来控制导出权限的做法，只能实现所有客户线索的“可以导出”和“不可导出”，为了避免地推成员拿到全部客户线索后，出现互相抢单的情况，在现有功能下只能赋予“地推主管”导出权限，地推主管导出数据后再去进行逐一的分发。

为此，产品团队，在“地推工作台”内增加了个人数据权限、团队数据权限，并通过“数据权限”来进行导出控制。最终通过赋予“地推成员”拥有“个人数据权限+导出权限”，来实现地推成员只导出个人的数据，这是利用“数据”来实现对用户导出结果的控制在实际场景中的应用。

另外，对于“导出权限”除了“用户是否可以导出”的思考外，还需要思考“导出用户的真实性”，即二次验证环节，验证当前用户的安全性。

导出的数据中很可能包括项目的核心内容，关系到公司安危，其重要性也衍生了一些通过违法手段获利的行为，比如模拟账号登入盗取数据、套用他人账号进行导出等。

因此我们在实际触发导出任务前，可以增加一个二次验证，验证该导出行为是否是账号本人操作，常见的包括“设置的安全码验证”、“绑定的社交账号验证”等，最大可能的保障数据的安全性。

2. 导出颗粒度

通常的，通过“导出功能”可以把页面上的数据，导出到本地环境，但是如果用户想要导出的数据是下钻的呢？在页面上查询得到的数据是1-3月每个月的汇总数据，但用户想要导出每个月份下每一天的数据，即1.1-3.31号每一天的数据。这里出现了不同的颗粒度，如果导出1-3月每个月的汇总数据，就是按月颗粒度导出数据；如果导出1.1-3.31号每一天的数据，就是按日颗粒度导出数据。

由此可见，导出颗粒度是存在相对关系的，比如大小关系，从上文的导出时间维度看，按月导出是大颗粒度，而按日导出是小颗粒度。当存在多个导出颗粒度时，就跟需要详细标明不同导出的数据颗粒度，让用户明确感知到通过“导出”可以拿到的数据颗粒度是什么，这也是我们需要在“导出前”环节思考的。

通过一个案例来看一下吧，某电商后台“商品分析模块”，提供了两种导出形式的数据，形式1，提供商品一段时间的销售额之和；形式2，提供商品一段时间每一天的销售额。

这里也出现了不同导出颗粒度之间的相对关系，在相同时间段内，同一个字段，形式2导出的数据加起来，就等于形式1导出的数据。由此可见形式1导出的是商品一段时间内的汇总数据，而形式2导出的是商品一段时间内的明细数据，这就是两种不同的“导出颗粒度”，需要我们通过文案来透出两者的区别，帮助用户明确理解通过哪一种形式可以拿到怎么样的数据，常被用于同时存在“多个导出”的场景下使用。

二、导出中注意的点

文章开头，小明提的简单的导出方案，已经包括了“导出环节”中发起导出入口，导出结果反馈等部分，导出中的主体流程通常都是被大家注意并且重视的，这里想要讨论在导出中需要注意的是一些细节，这些细节给用户带来体验的提升。

1. 支持自定义设置

用户通过导出拿到的数据字段，常见的是和页面展示的字段保持一致的。但在实际业务场景中，用户想要的导出字段存在比页面上少或者多的情况。

先来看下，用户想要导出的字段比页面上少的场景。出现这种场景的原因是，页面提供的内容是为了满足不同用户的需求而存在的，所覆盖的业务比单一用户多的多。

以常见的“销售记录”为例，销售记录中有订单相关、用户相关、商品相关等字段，不同字段的组合可以满足用户的需要，但是对于单一用户来说，部分字段与它所关心的业务无关，这部分字段对于该用户来讲就是多余的，用户A只关心销售记录中的订单数据，导出后得到的商品相关字段可能就会变成一种负担，需要用户去进行删除，从而增加了用户的操作成本。

系统提供可导出字段为m个字段，比如字段1、字段2、字段3
页面展示的字段为n个字段，比如字段1、字段2、字段3
这里m=n，页面展示的字段即为系统支持用户导出的字段
当用户实际使用的字段x≤n=m时，就是用户想要导出字段小于页面的场景

再来看下，用户想要导出的字段比页面上多的场景。出现这种场景的原因是，页面提供的内容是有限的，展示太多字段会出现滚动条并且导致增加用户查找某一字段的成本，因此页面上展示的字段通常是覆盖目标用户群体的大部分需求而存在的，这就会造成一个问题，导出字段如果和系统支持导出一致，会使得部分字段对于大部分用户来说是无效字段；导出字段如果和页面支持一致，使得小部分用户得不到“系统提供但是页面之外”的字段，使得该部分用户的需求无法被满足。

系统提供可导出字段为m个字段，比如字段1、字段2、字段3、字段4、字段5
页面展示的字段为n个字段，比如字段1、字段2、字段3
这里m>n，页面展示的字段小于了系统支持用户导出的字段
当用户实际使用的字段n

针对这两种场景，可以支持用户自定义导出字段来解决，但是这里有一个前提条件，从上文场景描述中可以发现，“自定义”是存在边界的，用户可以导出字段的上限就是“系统支持导出”的字段个数，所以如果用户想要自定义导出的字段不在“系统支持导出字段”内，那么就不是“自定义设置”可以解决的问题，而是去评估“是否支持该新字段的查询和导出”。

通过一个案例来理解吧，某电商后台有“销售记录”菜单，提供了“订单编号、创建时间、下单时间、付款时间、交易状态、订单金额、买家昵称、商品名称、商品编号、商品单价、商品数量”字段的查询和导出，而不同业务的运营同学对于导出的字段不同，商品运营的同学不关心“创建时间”和“下单时间”，业务运营的同学不关心“商品单价”和“商品数量”，在导出数据进行报表制作时，都需要对“导出”的字段进行删减。

这就是“用户想要导出的字段比页面少”的场景，而通过支持“自定义设置导出字段”，就可以解决这个问题，默认支持导出“订单编号”等11个字段，业务方可以根据实际的业务场景需要，进行设置，得到想要导出的字段。

自定义字段设置，除了对“字段”数量多少进行自定义以外，还可以在系统支持的导出格式内对“字段”进行设置，例如系统内支持“值班时长”字段秒、分/秒、时/分/秒等3种格式，那么在导出时也可以支持让户去设置自己想要的格式。

2. 导出过程的反馈

对于“导出结果”会提供明确的反馈结果，让用户感知到“导出任务”是成功了还是失败了，但是导出的过程的进度常常会被我们忽略，导出过程中“进度反馈”的缺失，引发了“我这个任务怎么还没有完成？”，“这个任务还需要多久才能完成”，“我是需要一直等待还是可以去做别的事情”等疑惑的产生，进而导致用户陷入一种未知恐惧的状态。

而提供“导出进度”的反馈，可以很好的提升用户在导出流程中的体验，通过变化的进度条让用户感知到了导出任务的变化过程，让用户对等待有感知的，也可以根据进度情况安排自己下一步的行为。

3. 导出文件的格式设置

对“导出文件格式”这一细节的优化也可以给用户带来体验的提升，当导出用户对象不是专业数据分析同学时，用户可能就忽略了数据分析前需要进行的清洗工作，直接在导出文件上进行了加工，存在一些数据格式使得公式无法使用，原有公示失效等问题。

以Excel为例导出文件中的单元格格式就会影响在文件内使用公式无法生效，例如下图中左边的单元格格式是常规，而右边的单元格格式是文本，求和公式就无法生效了。

三、导出后注意的点

当用户下载拿到导出文件后，并不是意味着我们“导出功能”设计的结束，在导出后的环节中，我们需要注意用户“二次导出”以及“导出记录”的场景。

1. 二次导出

用户通过浏览器下载拿到导出文件后，只是代表了用户本次导出行为的结束，但是用户会存在短期二次重复导出的需求，例如本地文件保存不当丢失，产品原因导致导出数据缺失等，这个时候用户需要重新进行导出，那么用户就需要重新在“页面”进行操作，并伴随着导出条件的筛选，包括时间、状态等具体的业务条件，如果导出条件比较复杂的话无疑增加了用户的成本。

我们可以提供“导出中心”的功能，整合用户短时间（一般7天，30天）的导出任务，方便用户在需要重复导出时，可以直接通过该模块再次生成导出任务，而不需要在页面上重新操作了。

2. 导出记录

虽然在导出前已经对“导出权限”问题做了详细的限制，包括账号级别的权限和二次验证，但是仍然可能会存在数据泄漏的问题，这个时候就需要有对应的模块可以去查询当时的导出情况，是什么时候导出的，是哪个账号导出，导出的数据条件是哪些。

就可以帮助用户定位到具体出问题的账号是哪个，进行追责，以及评估数据泄露的程度。例如下图中的导出记录，就帮助用户定位到了账号1在8月4日，在菜单1导出了2020年8月2号到4号，订单状态为“已付款”的订单信息。

四、总结

当确定要做导出后，在设计具体导出功能时，不仅需要关注核心的导出中的流程环节，也需要思考“导出前”、“导出后”。导出前需要注意“导出的权限”问题，以及让用户明确感知导出的颗粒度；导出后需要帮助解决用户“二次导出”和“定位导出记录”的需求。

最后祝大家新年快乐～

#作者#

晌午，微信公众号：晌午自习室。4年产品经验，专注于数据方向，目前是电商客服领域的产品 。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！