作为一个基础功能，导入功能在产品中没有太大的战略意义，也不是什么核心功能。但这并不意味着就可以随意应付。能把这些基础功能做好，反而说明了产品经理的基本功很不错。
这段时间全身心扑在另一个项目上，一直没机会继续输出内容，临近春节项目也规划好了年前年后的各项工作，总算有点空隙来写点什么，笔者整理了下思路，决定选择探讨“数据导入”这一功能，原因主要有两个方面：
首先，“数据导入”是B端产品中一项基础而通用的功能，不受行业限制，以此为切入点，记录自己在分析用户目的、业务场景、价值体验时的思路，这样更容易被来自各行各业的朋友所理解和应用，特别是刚入行的读者朋友，如果有需要可以以此文为基础，取其精华，去其糟粕。
其次，打磨好常用的方案进行总结和记录是笔者个人的习惯，这样不仅是在加深自己的记忆，也是在积累专业底蕴。在未来面对不同类型项目时，就可以敏锐的察觉到当年走过的坑，然后迅速复用这些经验。在笔者看来，这也是衡量一个产品经理对于企业能带来多少价值的关键之一。
用户背景分析：首先要了解你的目标用户是谁（财会系统-会计、财务，人力资源系统-BP、秘书，呼叫中心-客服），他们通常需要导入什么类型的数据（客户数据、订单数据、产品数据等）。
使用场景定义：明确用户在哪些具体情况下会用到导入，以及导入的具体信息。比如系统重构后希望立即迁移旧平台的数据；或是已有用户想要更新信息；或者日常运营中需要批量加工数据。那在现状没有导入功能的情况下，对于用户的影响是什么（没办法快速查找数据？无法快速对数据进行加工？)。
从上面三个维度出发，我们可以对需求，建立起来粗略二维矩阵模型来宏观的审视需求(此处仅为方法论，未代入具体案例)
当然，这也只是方法论的一种，也可以使用其他方法作为分析的依据，例如MoSCoW方法、Kano模型、RICE评分等等，方法论主要是手段，核心还是分析思路需要跟业务同频，尽可能的从用户身上拿到所有想要的东西，以支撑下一阶段的方案设计。
因为业务特殊和篇幅原因，这里不展开写调研的所有内容，只对核心结论写几点：
根据前期的调研和业务盘点，并加以分析之后，我们发现用户存在长期高频率的线下做数据加工然后让IT手动导入数据库的场景，并且这个过程中出现的问题如下(仅为示例)：
基于以上调研分析结果，我们开始进一步的方案构思
根据梳理的现状导入流程来看，是完全没有做任何系统支持的，基本上都靠业务人工审核数据，审核之后IT手动用脚本在数据库中直接去写入，非常原始，我们可以用到笔者在前一篇文章【B端产品经理的流程设计思维（下）实操部分】中写的流程优化方法
去进行判断，后续开发为系统功能之后，流程上要优化的几个点
流程说明文件的撰写方法，在前面文章有详细写过，这里就不再复述了，在流程方案澄清，评审通过后，我们就可以开始系统方案的设计了，也就回到了我们产品经理的专业领域上
我们在流程方案设计时有提到，直接上级审核这个活动环节，我们可以将审核的规则，固化成一条条的逻辑，用系统校验替代人工，那么这些审核的规则，我们即要在前端让运营人员加工数据时就知道，也要在系统后端，校验导入数据时用到。这里就需要导入模版的设计了：
如果字段填写的数据，是固化的值列表，也可以直接设计在模版中，避免手工输入时误填，并且表格本身也会做一道校验，用户误填也能及时知道，而不是等上传了报错才发现，如：
如果字段之间有一定的集联关系，也可以在模版中说明并在prd中写明相应逻辑，如：
1、导入按钮
在需要导入的页面，增加【导入】按钮，点击后选择本地文件进行导入，似乎是最简单的操作体验
但是怎么让业务知道，我们有设计导入模版，需要满足模版格式进行导入呢？所以这里需要在点击【导入】之后，给一个下载模版文件的入口：
方案做这一步已经能简单满足导入的需求，但在前期调研的时候，业务上还有一些细微的问题，比如同时制作的文件很多，容易找不到，或者觉得去系统上一步步点上传很麻烦，不如以前做好之后发给IT去导入等等
这不仅仅是实现功能就能解决的，基于这种偏负面的情绪，我们可以在功能体验上做更多优化，降低用户抵触心理和学习成本，比如：
以上面写的材料作为依据，产品方案设计如下
2、点击导入，弹出导入窗口
3、可【重新选择】后上传
也可以在选择文件这一步，就做一级校验，即校验选择的文件中字段，与模版字段是否一致，如一致则正常选择，显示在弹窗中，如不一致，则报错提示：
选择文件无误后，点击【上传】按钮进入上传进程，上传进程中【取消】和【上传】按钮置灰无法点击(看实际业务场景，如果需要上传中途也能取消，则需要中止进程并对已上传数据进行注释)：
4、上传进程校验结束
1）【上传成功】
文件信息上传成功后，顶部浮窗显示：
注意：这里需要跟业务对齐原则，上传校验逻辑采用以下哪种方案
这里为了方便报错文件生成，二次上传避免重复数据，避免拆表，故选择a）方案，上传成功后可点击【继续上传】即可调起本地上传弹窗，继续上传内容。
2）【上传失败】
数据校验未通过
根据前期调研到的业务规则进行梳理和标准化，与业务代表达成一致后，形成固化逻辑并交付开发，以下均为示例，仅做参考：
校验原则：校验所有字段信息，如有错误数据仅做记录，不中止校验，在上传失败文件中统一呈现失败说明(数据较多时，对系统性能要求较高，慎用)
a）必填项校验：校验数据行中必填字段是否为空，为空则失败。失败说明：【对应字段】缺少必填信息；
b）权限校验：校验导入员工数据，是否为操作人同一组织部门，不为同一组织则失败，失败说明：无员工组织范围权限
c）重复项校验：以员工ID+开始派驻日期+结束派驻日期 为基准，检验本次导入数据+系统中已存在的数据，一个员工在同一时间内仅可存在一条派驻数据，否则失败，失败说明：【员工ID】存在重复数据；
d）集联校验：
1）未填写【A列】时，【A列】【B列】字段都不校验，不写入该列数据；
2）已填写【A列】时，【B列】为必填并需要写入【A列】【B列】数据，否则失败；
e）【员工ID】：校验填写的ID是否为集团在职员工，失败说明：【姓名】员工不存在
f）【派驻场景】：仅支持导入当前系统中已配置的派驻场景，否则失败，失败说明：【派驻场景】填写内容不存在
g）【派驻开始/结束时间】：
1）校验导入的派驻时间段格式是否正确，错误时失败说明：【派驻开始/结束时间】格式错误
2）数据的派驻时间段是否有误（结束时间需大于开始时间），错误时失败说明：【派驻开始/结束时间】开始时间大于结束时间
h）……以此类推
下载失败信息表，进行报错详情查看后修正并重新导入，如下增加【失败说明】列：
导入只是个很基础的功能，实际并不具有战略性的业务价值，也不足以成为核心功能进行卖点宣导，但是做基础能力的态度和思维，往往决定了一个产品的下限。一些细枝末节的角落，能不能设计到让用户几乎是趋于本能性的进行使用，让操作体验无阻，业务流程衔接顺畅，这非常考验产品经理的设计思维。
本篇文章为了更具体的说明逻辑，笔者简单举了一些业务场景的例子，这里只是为了能够扩大通用性，让读者朋友能代入后去清晰的阅读，也是给未来的自己留下一些面对不同领域业务也能复用的材料。实际上根据系统架构、业务需求、产品定位、用户群体等等不同，这里面可以做的差异化设计还有很多很多，再写几篇文章也写不完。包括导入的报错，数据量小，怎么更快捷的进行数据修正，数据量过大，怎么进行拆表修正等等。还有财会系统、薪酬系统，对数据精度要求极高，需要牺牲很大一部分用户体验做多重校验，对导入时可操作的数据权限控制设计、导入数据本身的分层校验设计也十分复杂。
还是那句话，以上内容并非绝对的行业标准，各位读者可以去其糟粕，取其精华，根据现在所面临的处境按需取用，也欢迎大家进行良性讨论和补充完善。
本文由 @huang 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。