经验

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

作为一个基础功能，导入功能在产品中没有太大的战略意义，也不是什么核心功能。但这并不意味着就可以随意应付。能把这些基础功能做好，反而说明了产品经理的基本功很不错。这段时间全身心扑在另一个项目上，一直没机会继续输出内容，临近春节项目也规划好了年前年后的各项工作，总算有点空隙来写点什么，笔者整理了下思路，决定选择探讨“数据导入”这一功能，原因主要有两个方面：首先，“数据导入”是B端产品中一项基础而通用的功能，不受行业限制，以此为切入点，记录自己在分析用户目的、业务场景、价值体验时的思路，这样更容易被来自各行各业的朋友所理解和应用，特别是刚入行的读者朋友，如果有需要可以以此文为基础，取其精华，去其糟粕。其次，打磨好常用的方案进行总结和记录是笔者个人的习惯，这样不仅是在加深自己的记忆，也是在积累专业底蕴。在未来面对不同类型项目时，就可以敏锐的察觉到当年走过的坑，然后迅速复用这些经验。在笔者看来，这也是衡量一个产品经理对于企业能带来多少价值的关键之一。一、需求分析确定目标用户与使用场景用户背景分析：首先要了解你的目标用户是谁（财会系统-会计、财务，人力资源系统-BP、秘书，呼叫中心-客服），他们通常需要导入什么类型的数据（客户数据、订单数据、产品数据等）。使用场景定义：明确用户在哪些具体情况下会用到导入，以及导入的具体信息。比如系统重构后希望立即迁移旧平台的数据；或是已有用户想要更新信息；或者日常运营中需要批量加工数据。那在现状没有导入功能的情况下，对于用户的影响是什么（没办法快速查找数据？无法快速对数据进行加工？)。需求评估需求频率：数据导入发生的频率是多少？每天需要导入几百次，和一年导入十次，那设计方案的思路是完全不一样的；需求范围：有多少用户受到了这个问题的影响？几个人需要用导入来加工数据，还是有几百个人需要用导入来加工数据，前后两种场景得出的投入产出比相差可能很大；业务价值：实现这个需求，可以带来多大的价值？是节省多少个运营工时或者增强数据准确性，还是能提高用户满意度和转化率续签率等等。或者说既不节省工时，又不直接带来经济效益，但是要满足集团的合规要求或者数据管理规范的要求？从上面三个维度出发，我们可以对需求，建立起来粗略二维矩阵模型来宏观的审视需求(此处仅为方法论，未代入具体案例) 高频率高广度：这是最高优先级的需求，应该尽快解决。高频率低广度：虽然影响用户较少，但如果这些用户非常重要（如核心用户或付费用户），也值得优先考虑。低频率高广度：虽然不是经常发生，但由于影响广泛，也应该给予重视。低频率低广度：这类需求优先级最低，可以在更重要的需求得到解决之后再考虑。当然，这也只是方法论的一种，也可以使用其他方法作为分析的依据，例如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）……以此类推失败信息下载失败信息表，进行报错详情查看后修正并重新导入，如下增加【失败说明】列：四、总结导入只是个很基础的功能，实际并不具有战略性的业务价值，也不足以成为核心功能进行卖点宣导，但是做基础能力的态度和思维，往往决定了一个产品的下限。一些细枝末节的角落，能不能设计到让用户几乎是趋于本能性的进行使用，让操作体验无阻，业务流程衔接顺畅，这非常考验产品经理的设计思维。本篇文章为了更具体的说明逻辑，笔者简单举了一些业务场景的例子，这里只是为了能够扩大通用性，让读者朋友能代入后去清晰的阅读，也是给未来的自己留下一些面对不同领域业务也能复用的材料。实际上根据系统架构、业务需求、产品定位、用户群体等等不同，这里面可以做的差异化设计还有很多很多，再写几篇文章也写不完。包括导入的报错，数据量小，怎么更快捷的进行数据修正，数据量过大，怎么进行拆表修正等等。还有财会系统、薪酬系统，对数据精度要求极高，需要牺牲很大一部分用户体验做多重校验，对导入时可操作的数据权限控制设计、导入数据本身的分层校验设计也十分复杂。还是那句话，以上内容并非绝对的行业标准，各位读者可以去其糟粕，取其精华，根据现在所面临的处境按需取用，也欢迎大家进行良性讨论和补充完善。本文由 @huang 原创发布于人人都是产品经理，未经许可，禁止转载题图来自 Unsplash，基于 CC0 协议该文

Rihanna

1月 25, 2025 - 04:30

4314

作为一个基础功能，导入功能在产品中没有太大的战略意义，也不是什么核心功能。但这并不意味着就可以随意应付。能把这些基础功能做好，反而说明了产品经理的基本功很不错。

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

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

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

一、需求分析

确定目标用户与使用场景

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

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

需求评估

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

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

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

当然，这也只是方法论的一种，也可以使用其他方法作为分析的依据，例如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）……以此类推

失败信息

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

四、总结

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

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

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

本文由 @huang 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

经验