批量導入用戶只是一個B端產品內常用的一個基礎功能，但也很重要。下面這篇文章是筆者對B端產品功能設計思路進行的一個解析，大家一起來看看吧！

B端產品的功能在使用過程中經常被用戶提出需要增加批量操作功能，比如批量導入用戶數據，批量啟禁用，權限批量續期等等。畢竟在一個公司里管理者是少數，打工人是多數，管理者一個個設置數據可能會設置到崩潰，批量設置對他們來說就是解救其從重復工作中逃脫出來的救命稻草。

批量導入用戶是一個B端產品常用的基礎功能，看似一個小小的功能，其實對于產品設計來說蘊藏著著大大的學問，如何將這個功能形成需求并且在實現功能的基礎上盡量提升用戶體驗呢？接下來我們就對這個需求產品經理的設計思路進行詳細解析！

一、接收用戶需求

用戶：我希望系統能夠讓我批量導入用戶。

二、用戶需求拆解

產品提需求肯定不能只是簡單的復述用戶提出的一句話需求，要不然就真的是人人可以是產品經理了。產品需要基于用戶的這簡單一句話對需求進行拆解，充分理解用戶的需求，并基于易用性、友好型等多方面考慮用戶的交互體驗，同時也需要考慮性能方面影響，不能因為導入大批量用戶把系統給整掛了對吧~要有全局觀哦朋友們！

那么我們在以上考慮的基礎上對用戶的需求進行拆解，可以得到以下幾個需要深入思考的點：

1. 批量導入出口
2. 導入注意事項說明提醒
3. 導入進度通知
4. 導入結果通知，如果失敗時如何提醒
5. 如果導入大批量數據考慮性能問題

三、深度思考每一點

基于以上拆解的思考點，我們就來深度思考每一個點吧，思考完成后就可以去寫這個功能啦！

首先有朋友會問，誒我是不是應該先畫一個流程圖，如果你對這方面工作熟悉度低，且產品經驗比較少，可以畫畫練練手；如果你已經熟悉這類需求，擁有一定的產品思維，可以說是一個合格的產品經理啦，這個流程其實相對來說比較簡單可以不畫圖，在腦子根據你能想到的點過一下也可以哦。

那么開始頭腦風暴！

1. 批量導入出口

①在哪里增加導入入口？

一般會在用戶管理列表的頂部增加導入按鈕。

②按鈕的交互如何？

這是一個需要一直啟用的次要按鈕，所以需要高亮并且顏色上我們考慮和主按鈕區分就可以；如果像批量啟用/禁用/刪除這類按鈕，需要默認是禁用狀態，選擇數據后才會高亮啟用。

2. 導入注意事項說明提醒

這一步就要考慮點擊導入之后的交互了，有人說，我們在點擊導入時直接出文件選擇框，然后選完了直接進行導入不就完成了？

這個……也不能說沒有完成，只是……是不是整個過程略顯突兀？用戶大概率是一臉茫然……你讓我傳啥？上傳的時候選擇什么類型的文件？導入的字段包括什么？

這就需要我們考慮在這步的時候應該怎么友好的提示用戶，那么我們就來梳理一下提示方式和提示內容應該包括哪些吧！

①文件類型

這是思考的第一步，也是校驗的第一步，系統到底需要什么？你總得告訴用戶你想要什么類型的文件吧，明確出來你想要的是excel還是txt。

②文件格式

這是思考的第二步，也是校驗的第二步，系統想要的數據長什么樣？你總得告訴用戶你需要他往文檔里放哪些字段吧，每個字段有什么注意事項，這塊最好的辦法是提供上傳模板的快速下載按鈕，讓用戶直接下載模板，模板里可以有必要的說明。

③特殊邏輯

文件類型和文件格式都對了，那會不會出現什么需要邏輯處理的地方？這是思考的第三步，比如導入用戶如果出現同名如何處理，是覆蓋還是導入失??？

這一步你可能會想說那如果出錯了怎么辦，出錯了怎么辦就可以結合“第五步，用戶結果通知，如果失敗時如何提醒”這一章進行深入思考。

④其他考慮

比如：考慮用戶導入大批量數據性能上限，綜合程序的性能和等待時長的考慮給出一個單次支持最大導出行數的建議。

基于以上思考那么導入用戶的一個提示框信息就出來了，如下圖所示：

導入模板也基本上可以出來了，如下圖所示：

流程圖，小白看這里！

如果要在筆下畫流程圖，也是基于我們這一步要思考和擴充的點去思考怎么畫流程圖，對自己大腦思考過程的一個可視化，能對第二步需求拆解有查漏補缺就更好啦。

3. 導入進度通知

如果想要用戶有很好的交互體驗，讓用戶能夠直觀的掌握導入進度，不是盲目等待，可以用導入進度條來展示導入進度，讓用戶直觀看到程序的進度。

4. 導入結果通知，如果失敗時如何提醒

導入完成的狀態分為兩種，導出成功或者導入失敗，成功可以直接提示成功。那么失敗怎么友好提示用戶呢？

首先我們分析一下導入失敗的情況，從“2.導入注意事項說明提醒”的思考過程中，我們也可以知道失敗的情況大概就是四種：

1）文件類型不對

這種可以直接在用戶上傳時做攔截，直接toast提示用戶文件類型不正確，讓用戶重新上傳符合類型的文件。比如系統要求上傳.xls或者.xlsx文件，用戶傳了.sql文件可以直接提示攔截在上傳這步。

2）文件格式不對

這種可能在用戶上傳文件時我們不好校驗，那么可以在點擊導入時進行校驗，首先校驗文件格式是否符合系統的需求，比如系統需要用戶上傳的文件字段是姓名和郵箱，用戶上傳了一個文件字段是家庭住址和身份證號碼的，跟系統模板完全不一致，我們可以在這步直接提示用戶，導入文件表格格式不符，讓他根據導入模板調整格式后再上傳。

3）某些字段不正確

這種是用戶都按要求填寫了，但是因為系統在新增用戶時會有一些校驗，比如手機號碼是11位的數字，用戶名是小于30個字符的文本，上傳的文件里某個人的手機號碼寫了20位字符，是有誤的，那么我們就要對他進行一個錯誤提醒。

如何友好的進行提醒呢，我們可以在導入完成后有個提示，提示導入成功多少條數據，導入失敗多少條數據，然后失敗的數據可以下載失敗數據文件具體查看失敗原因，用戶可以根據每條的提示進行針對性的修改。

4）超出單次上傳要求最大量限制

這種我們可以結合第三種進行提示，在導入文件的超出限制的數據每條后面標記上失敗原因是因為超出單次導入最大限制。

思路就大概是這些，但是在這一步，我們一定一定不要忘了細化導入邏輯哦，這點非常重要！我們要根據新增用戶規則把導入每個字段的校驗和處理方式都要明確的寫出來，比如導入組織如果不存在如何處理？

導入的用戶名超過字符限制如何提示，導入時如果有個字段沒寫是否有默認值等等。

鐺鐺鐺，細節都補充完成后，一個用戶導入的需求拆解和整理就完成啦，接下來就是依據這個按照順序完成需求書寫啦！

5. 如果導入大批量數據考慮性能問題

這步我們其實在2.導入注意事項說明提醒中已經有所體現，需要考慮用戶如果導入大批量數據性能上限，因此我們綜合程序的性能和等待時長的考慮給出一個單次支持最大導出行數的建議，需求評審時可以和研發溝通進行調整。

四、總結

不要小看每個需求哦，要有全局思考的頭腦，同時也要細節細節再細節，希望每一個產品在寫需求時，都能做到腦中有步驟，心中有草稿，筆下有細節！