b端產品設計與實現總結（B端產品設計批量導入）

2023-04-15 15:28:53

批量導入是B端後臺產品中常用的一大功能，看起來簡單但是實際上做起來卻能夠發現裡面的坑有很多。作者結合自己的實戰經驗，與大家分享自己當時從0到1的設計過程，希望對你有所幫助。

批量導入是B端後臺產品中非常常見的功能，乍看簡單，但實際做起來才發現裡面的坑著實不少。筆者根據自己的工作經歷，記錄整理了當時從0到1的設計過程。內容較長，耐心看完，相信你一定會有所收穫！

一、業務分析

在開始任何B端產品的功能設計前，都需要先分析這個功能對應的業務場景以及想解決的業務問題。

批量導入也不例外，一般導入功能都出現在需要單次錄入大批量數據的後臺產品中。根據不同的場景會有不同的應用，需要結合用戶特徵來一起分析，它們共同決定了導入功能的軟體功能流程和基本邏輯，例如：

導入的數據是「新增」還是「覆蓋」？（即系統中已有數據的情況下，本次導入是在其後添加數據，還是完全覆蓋系統已有的數據）存在錯誤數據時，是忽略錯誤數據允許正常數據導入，還是全部打回重新導入？錯誤數據如何提示和處理，是在線修改，還是導出excel讓客戶修改後重新導入？······

這些都是在業務分析階段就需要思考的事情！

二、導入流程

導入功能大致可以分為3個環節

導入指引：讓用戶了解怎樣使用導入功能，並給出一份模板文件；導入文件：上傳文件，並校驗錯誤數據；結果反饋：讓用戶知道本次導入的結果&影響。

其中2是最麻煩最複雜的一環，因為除了常規的文件類型和數據格式校驗外，部分B端產品可能還會有一些業務上的限制，需要考慮到導入的數據與現有的業務規則是否衝突，如果存在衝突，要以何種形式告知用戶哪些數據異常、要如何處理。

三、功能設計

3.1導入指引

3.1.1導入指引

如果導入過程並不複雜，只需要給出下載模板和上傳文件的入口即可；如果流程比較長，需要給出一條明確的步驟指引。

3.1.2模板說明

對於一些重要的系統要求或者是不易察覺的設置，需要在表頭上進行說明，引導用戶正確的填寫數據。

3.2導入文件

3.2.1 導入進度

根據導入數據的規模和校驗規則的複雜程度，需要考慮不同的上傳進度提示。（這些最好提前與研發人員溝通好）

如果一般情況下上傳數據少，校驗規則也比較簡單，耗時短，可以給一個輕量的加載圖標；如果單次導入的數據量大，或者校驗規則比較複雜，需要較長的時間，可以給一個上傳進度條。在這種情況下，導入任務可以設置成異步處理，即允許用戶關閉當前導入窗口，使用軟體的其他功能模塊。

3.2.2 文件解析和數據逐行校驗

一般導入文件的校驗分為兩個過程：

1）文件格式校驗

在寫入數據前，首先會校驗文件的基本格式是否符合規範，如果不符合則需提示用戶檢查上傳的文件並重新上傳。一般會有如下規則：

文件類型：支持的文件類型，如excel文件；文件大小：是否超出規定的文件大小，如2M；表頭：是否與模板一致；行數：是否超過規定的上傳上限，比如最多允許導入1000行記錄，但上傳的文件有2000條記錄

2）數據內容校驗

文件校驗通過後，就開始校驗逐行表格中的數據內容，一般包括數據格式和業務規則的檢驗：

數據格式：欄位的數據類型、長度，比如某個數量欄位，用戶填了文字；業務規則：記錄重複、不同欄位之間的運算關係、主從邏輯判斷等；（比較複雜，會在文章末尾中的案例中提供示例參考）

3.3 導入結果反饋

1）導入結果

反饋用戶本次導入的結果狀態。

一般「覆蓋」導入（即導入的數據會覆蓋系統原有數據），對於錯誤數據，都是全部攔截並進行報錯提示；「新增」導入（即導入的數據會在系統原有數據基礎上進行新增），一般都只允許正常數據導入，錯誤數據到出修改，這樣可以方便用戶快速定位到錯誤的欄位上。

2）錯誤數據修改

導入失敗的數據可以支持單獨導出，並在excel中對異常欄位進行特別標註，也需附上「錯誤原因」。（也有文章提過部分情況下可以讓用戶在線修改，但個人認為這種方式並不好，因為對於由同一個錯誤引起的大量異常數據，修改效率很低。如果考慮批量編輯功能，開發成本又會變得很高）

3）導入歷史（非必須）

部分特殊情況還需要記錄導入歷史，方便後續查看。

四、分析案例

4.1 產品介紹

一款面向小微企業&個體工商戶的ERP進銷存管理軟體，幫助他們實現業務的數位化管理。（說人話就是，倒買倒賣的中間商每天向哪個供應商買了哪些商品？又向哪個客戶賣了哪些商品？倉庫裡現在又還有哪些貨、數量多少？······

成千上萬個商品在不同時間、不同客戶、不同供應商中積累的價格、數量、金額等信息是海量的，光靠腦子不可能記得住，更不用說去分析一個周期內的銷售額、利潤！因此軟體就是幫助這些中間商記錄商品流通過程中的信息數據，更好地掌握生意狀況）

4.2 需求背景

我是一名批發商，上次向某個供應商訂了一批貨，這次供應商把貨送了過來，還附了一張單據（可能是電子單據，也可能是紙質單據，不同供應商給的單據格式也不一樣，如下圖所示），你確認沒問題後，把這批貨搬進倉庫，然後把這個單據錄到系統中，一個個選擇商品肯定太麻煩了，於是你希望有一個導入功能，幫你把這些數據批量處理掉。

4.3 業務背景

這裡提兩個比較重要的概念，方便讀者更好的理解下面的分析過程。

1）商品唯一性標識

商品條碼一般是商品的唯一標識，由商品國際物品編碼協會賦予，包含該物品的生產國、製造廠家、商品名稱、生產日期、類別、日期等許多信息，在商品流通有廣泛的應用。（簡單來說就是你去便利店買東西結帳，店員用掃碼槍「嘀」的那塊地方，如下圖）

但是對於部分行業，流通的商品大多是非標品，例如茶葉、部分食品、五金件等，也沒有條碼的概念，只能通過一定的規則（通常是商品名稱）去標識一個唯一的商品。

而我們軟體定位是泛行業的軟體，所以商品條碼是商品最高級的唯一標識，卻又不是一個必要信息。除此之外，商品名稱&規格組合也是一個商品的唯一標識，不可重複。

2）單位

商品單位容易理解，計量商品的標準量，如個、件、箱、米等。值得注意的是，部分商品在實際業務中可能同時存在多個單位，例如300ml罐裝的可樂，1「瓶」3元，論「箱」（1箱=24瓶）銷售時，1「箱」70元，即同一商品不同單位之間存在換算關係，所以這些商品在商品管理上略微複雜，導入功能設計上也需要考慮到這種情況。

4.4 分析過程

1）用戶分析

在過往的用戶調研中，我們發現用戶大多是四十左右的中年人，文化水平普遍偏低，對於大篇幅的文字說明都不太敏感，可能導入出錯的概率會比較高。因此除了功能框架層設計上要簡單清晰，還要強化對異常情況的處理提示，讓用戶一眼就知道導入失敗原因在哪以及如何處理。

2）業務場景分析

進貨場景下，可能同時會進一些新商品和舊商品（即軟體中沒有/已有的商品資料），進新商品會新建商品資料，進舊商品會更新庫存數量，綜合考慮決定「商品名稱」和「數量」為必填欄位，其他為非必填欄位；另外導入數據規模上，產品介紹有提到軟體面向的是小微企業主，他們的進貨規模根據調研結果，單次大多不超過100個sku，所以導入限制在200~1000行數據就足夠了。

3）可能出錯情況

由於新舊商品同時存在，因此要考慮的難點除了舊商品與已有商品資料的衝突，還有建立新商品資料的業務規則衝突。需要分別窮盡所有的出錯情況，並根據出錯場景，來決定哪些需要軟體自動處理這些錯誤，哪些需要導出讓用戶確認修改這些錯誤。

分析到這裡，差不多一個完整的導入功能流程就呼之欲出了。

4.6 功能流程圖

4.7 原型設計&說明

這裡就不貼原型了，網上資源多的是。主要講講其中的核心部分：數據內容的逐行校驗與提示。

由於公司保密制度規定非常嚴格，無法把PRD全部貼上來，這裡簡單提幾個可能的業務規則校驗供大家參考：

不同供應商品名：系統商品資料存在這個條碼，但對應的商品名稱不同（比如一罐可口可樂，供應商A叫「可口可樂」，你錄到系統裡也命名為「可口可樂」，但你這次又從供應商B那裡進了這個商品，他給你的單據上顯示名稱為「可口可樂300ml」）舊商品新單位：商品條碼、名稱與系統一致，但該商品沒有此單位運算關係衝突：多個欄位之間存在運算關係，但用戶上傳的數據不符合計算邏輯，比如單價*數量≠金額······

值得注意的是，上面提到的業務規則校驗，並不是所有都要當錯誤處理，有些可以讓程序自動處理，提高用戶的產品體驗。

本文由 @飛魚 原創發布於人人都是產品經理，未經許可，禁止轉載

題圖來自 unsplash，基於 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。

,