B端需求分析案例：通用设计【导入】

内容转载自：huang

这段时间全身心扑在另一个项目上，一直没机会继续输出内容，临近春节项目也规划好了年前年后的各项工作，总算有点空隙来写点什么，笔者整理了下思路，决定选择探讨“数据导入”这一功能，原因主要有两个方面：

首先，“数据导入”是B端产品中一项基础而通用的功能，不受行业限制，以此为切入点，记录自己在分析用户目的、业务场景、价值体验时的思路，这样更容易被来自各行各业的朋友所理解和应用，特别是刚入行的读者朋友，如果有需要可以以此文为基础，取其精华，去其糟粕。

其次，打磨好常用的方案进行总结和记录是笔者个人的习惯，这样不仅是在加深自己的记忆，也是在积累专业底蕴。在未来面对不同类型项目时，就可以敏锐的察觉到当年走过的坑，然后迅速复用这些经验。在笔者看来，这也是衡量一个产品经理对于企业能带来多少价值的关键之一。

一、需求分析

确定目标用户与使用场景

用户背景分析：首先要了解你的目标用户是谁（财会系统-会计、财务，人力资源系统-BP、秘书，呼叫中心-客服），他们通常需要导入什么类型的数据（客户数据、订单数据、产品数据等）。

使用场景定义：明确用户在哪些具体情况下会用到导入，以及导入的具体信息。比如系统重构后希望立即迁移旧平台的数据；或是已有用户想要更新信息；或者日常运营中需要批量加工数据。那在现状没有导入功能的情况下，对于用户的影响是什么（没办法快速查找数据？无法快速对数据进行加工？)。

需求评估

1. 需求频率：数据导入发生的频率是多少？每天需要导入几百次，和一年导入十次，那设计方案的思路是完全不一样的；
2. 需求范围：有多少用户受到了这个问题的影响？几个人需要用导入来加工数据，还是有几百个人需要用导入来加工数据，前后两种场景得出的投入产出比相差可能很大；
3. 业务价值：实现这个需求，可以带来多大的价值？是节省多少个运营工时或者增强数据准确性，还是能提高用户满意度和转化率续签率等等。或者说既不节省工时，又不直接带来经济效益，但是要满足集团的合规要求或者数据管理规范的要求？

从上面三个维度出发，我们可以对需求，建立起来粗略二维矩阵模型来宏观的审视需求(此处仅为方法论，未代入具体案例)

• 高频率高广度：这是最高优先级的需求，应该尽快解决。
• 高频率低广度：虽然影响用户较少，但如果这些用户非常重要（如核心用户或付费用户），也值得优先考虑。
• 低频率高广度：虽然不是经常发生，但由于影响广泛，也应该给予重视。
• 低频率低广度：这类需求优先级最低，可以在更重要的需求得到解决之后再考虑。

当然，这也只是方法论的一种，也可以使用其他方法作为分析的依据，例如MoSCoW方法、Kano模型、RICE评分等等，方法论主要是手段，核心还是分析思路需要跟业务同频，尽可能的从用户身上拿到所有想要的东西，以支撑下一阶段的方案设计。

问题示例

因为业务特殊和篇幅原因，这里不展开写调研的所有内容，只对核心结论写几点：

根据前期的调研和业务盘点，并加以分析之后，我们发现用户存在长期高频率的线下做数据加工然后让IT手动导入数据库的场景，并且这个过程中出现的问题如下(仅为示例)：

• 数据量大时，审核人员校准文件非常困难，且都在做重复性工作，例如检查日期格式，检查数据中的人员是否在职，这些都是可以固化的规则逻辑，完全可以实现自动化，释放业务、运营或开发的精力；
• 人工校准会出现失误，导致导入错误数据，需要返工，影响系统对业务的支持；
• 因为数据导入链路长，使得业务数据更新的时效性不高，影响系统对业务的支持；
• 数据唯一性无法保证，常出现重复数据；
• 因为都是微信或其他办公软件在发送文件，会出现发错，或文件过期，IT人员遗漏消息等问题；
• 某些业务数据属于内部敏感资料，需要多人员去配合完成导入，有泄漏外传的风险，不符合合规管控要求；
• 导入之后无法修改，必须删掉所有数据重新走一遍导入流程；
• 一份数据多个系统分别需要其中某一部分时，要业务拆表制作，而拆表后，一旦更新又要重新制作，重新拆表，重新给多方更新，不然会影响数据质量，十分繁琐；
• …….

基于以上调研分析结果，我们开始进一步的方案构思

二、流程方案设计

现状流程

根据梳理的现状导入流程来看，是完全没有做任何系统支持的，基本上都靠业务人工审核数据，审核之后IT手动用脚本在数据库中直接去写入，非常原始，我们可以用到笔者在前一篇文章【B端产品经理的流程设计思维（下）实操部分】中写的流程优化方法

去进行判断，后续开发为系统功能之后，流程上要优化的几个点

• 原流程无角色信息，职权不明晰
• 加工业务数据前，可以先按照数据库格式进行要求，避免最后一步返工
• 上级审核的规则和判断，固化成一条条的清晰逻辑，用系统校验替代人工
• 开发导入这个动作可以完全省略，系统页面增加导入功能，整体流程由用户侧完成导入不成功返回结果，可以根据实际需求，做成实时反馈(弹窗或下载报错数据)，或者统一反馈（邮件通知）
• …….

优化后的流程

流程说明文件的撰写方法，在前面文章有详细写过，这里就不再复述了，在流程方案澄清，评审通过后，我们就可以开始系统方案的设计了，也就回到了我们产品经理的专业领域上

三、系统方案设计

导入模版设计

我们在流程方案设计时有提到，直接上级审核这个活动环节，我们可以将审核的规则，固化成一条条的逻辑，用系统校验替代人工，那么这些审核的规则，我们即要在前端让运营人员加工数据时就知道，也要在系统后端，校验导入数据时用到。这里就需要导入模版的设计了：

• 【模版说明】：通过抬头第1行告知填写的人员注意事项；
• 【字段】：来源于前期跟业务敲定的共识，以后统一使用标准字段；
• 【填写格式】：来源于前期跟业务敲定的共识，以后统一使用标准格式，如日期填写都是用 YYYY-MM-DD，而不是2025/1/1 或 2025.01.1；
• 【数据起始行】：写入数据库的顺序起始第1行;
• …….

如果字段填写的数据，是固化的值列表，也可以直接设计在模版中，避免手工输入时误填，并且表格本身也会做一道校验，用户误填也能及时知道，而不是等上传了报错才发现，如：

如果字段之间有一定的集联关系，也可以在模版中说明并在prd中写明相应逻辑，如：

• 填写了B字段，则C字段必填；
• 如B字段中填写10，则对应校验C字段填写必须为1-10之间的整数；
• 如B字段中填写20，则对应校验C字段填写值必须为11-20之间的整数；
• ……

导入功能设计

1、导入按钮

在需要导入的页面，增加【导入】按钮，点击后选择本地文件进行导入，似乎是最简单的操作体验

但是怎么让业务知道，我们有设计导入模版，需要满足模版格式进行导入呢？所以这里需要在点击【导入】之后，给一个下载模版文件的入口：

方案做这一步已经能简单满足导入的需求，但在前期调研的时候，业务上还有一些细微的问题，比如同时制作的文件很多，容易找不到，或者觉得去系统上一步步点上传很麻烦，不如以前做好之后发给IT去导入等等

这不仅仅是实现功能就能解决的，基于这种偏负面的情绪，我们可以在功能体验上做更多优化，降低用户抵触心理和学习成本，比如：

• 支持拖动上传，减少操作步骤；
• 增加上传过程的提示，缓解用户等待情绪；
• 上传成功或上传失败，都要有对应的提示告知用户；
• 可以操作的地方亮起，不能操作的地方置灰；
• 打磨其他细节，务必做到操作简洁，体验清晰，指引准确；
• …….

以上面写的材料作为依据，产品方案设计如下

2、点击导入，弹出导入窗口

• 拖动文件到弹窗中，自动上传(需要做文件格式识别，拖入word或其他文件无法上传)
• 点击弹窗中间区域，调起本地文件选择器，选择文件类型仅支持，xls/.xlsx 格式。
• 点击【点击下载模板文件】处，即可下载导入模板；导入模板命名：xxxx_批量导入模板
• 未选择文件前【上传】按钮置灰，不可点击

3、可【重新选择】后上传

也可以在选择文件这一步，就做一级校验，即校验选择的文件中字段，与模版字段是否一致，如一致则正常选择，显示在弹窗中，如不一致，则报错提示：

选择文件无误后，点击【上传】按钮进入上传进程，上传进程中【取消】和【上传】按钮置灰无法点击(看实际业务场景，如果需要上传中途也能取消，则需要中止进程并对已上传数据进行注释)：

4、上传进程校验结束

1）【上传成功】

文件信息上传成功后，顶部浮窗显示：

注意：这里需要跟业务对齐原则，上传校验逻辑采用以下哪种方案

• 所有数据都校验通过，才可以上传成功，否则整个文件全部失败；
• 文件中校验通过的数据正常上传，校验失败的数据，单独生成失败文件；

这里为了方便报错文件生成，二次上传避免重复数据，避免拆表，故选择a）方案，上传成功后可点击【继续上传】即可调起本地上传弹窗，继续上传内容。

2）【上传失败】

数据校验未通过

• 上传数据中，若上传数据中有数据未通过校验时，全部数据都无法正常导入，对应有问题的数据按字段分别生成原因在“失败说明”列；
• 点击“点击下载失败信息”将下载上传失败的表格到本地；模板名称：xxxx_批量导入失败信息

校验逻辑说明

根据前期调研到的业务规则进行梳理和标准化，与业务代表达成一致后，形成固化逻辑并交付开发，以下均为示例，仅做参考：

校验原则：校验所有字段信息，如有错误数据仅做记录，不中止校验，在上传失败文件中统一呈现失败说明(数据较多时，对系统性能要求较高，慎用)

a）必填项校验：校验数据行中必填字段是否为空，为空则失败。失败说明：【对应字段】缺少必填信息；

b）权限校验：校验导入员工数据，是否为操作人同一组织部门，不为同一组织则失败，失败说明：无员工组织范围权限

c）重复项校验：以员工ID+开始派驻日期+结束派驻日期 为基准，检验本次导入数据+系统中已存在的数据，一个员工在同一时间内仅可存在一条派驻数据，否则失败，失败说明：【员工ID】存在重复数据；

d）集联校验：

1）未填写【A列】时，【A列】【B列】字段都不校验，不写入该列数据；

2）已填写【A列】时，【B列】为必填并需要写入【A列】【B列】数据，否则失败；

e）【员工ID】：校验填写的ID是否为集团在职员工，失败说明：【姓名】员工不存在

f）【派驻场景】：仅支持导入当前系统中已配置的派驻场景，否则失败，失败说明：【派驻场景】填写内容不存在

g）【派驻开始/结束时间】：

1）校验导入的派驻时间段格式是否正确，错误时失败说明：【派驻开始/结束时间】格式错误

2）数据的派驻时间段是否有误（结束时间需大于开始时间），错误时失败说明：【派驻开始/结束时间】开始时间大于结束时间

h）……以此类推

失败信息

下载失败信息表，进行报错详情查看后修正并重新导入，如下增加【失败说明】列：

四、总结

导入只是个很基础的功能，实际并不具有战略性的业务价值，也不足以成为核心功能进行卖点宣导，但是做基础能力的态度和思维，往往决定了一个产品的下限。一些细枝末节的角落，能不能设计到让用户几乎是趋于本能性的进行使用，让操作体验无阻，业务流程衔接顺畅，这非常考验产品经理的设计思维。

本篇文章为了更具体的说明逻辑，笔者简单举了一些业务场景的例子，这里只是为了能够扩大通用性，让读者朋友能代入后去清晰的阅读，也是给未来的自己留下一些面对不同领域业务也能复用的材料。实际上根据系统架构、业务需求、产品定位、用户群体等等不同，这里面可以做的差异化设计还有很多很多，再写几篇文章也写不完。包括导入的报错，数据量小，怎么更快捷的进行数据修正，数据量过大，怎么进行拆表修正等等。还有财会系统、薪酬系统，对数据精度要求极高，需要牺牲很大一部分用户体验做多重校验，对导入时可操作的数据权限控制设计、导入数据本身的分层校验设计也十分复杂。

还是那句话，以上内容并非绝对的行业标准，各位读者可以去其糟粕，取其精华，根据现在所面临的处境按需取用，也欢迎大家进行良性讨论和补充完善。