論后臺產品經理如何優雅地設計導入功能
編輯導讀:導入功能是后臺產品必不可少的功能,也是使用頻率最高的功能之一。作為一個后臺產品經理,應該如何設計導入功能呢?本文作者從自身工作經驗出發,對此進行分析,希望對你有幫助。
對于后臺產品,導入是系統里必不可少的功能之一。如何設計好一個導入功能,了解以下幾點就夠啦(如果你覺得不夠,請在評論補充)。
一、如何定義導入模板
首先導入模板一般是由產品給出,需要率先確定導入模板的名稱、格式、大小。下面以表格為例:
名稱:模板名稱與模板內容相匹配就行了
格式:常見表格格式為xls、xlsx、csv
其中csv為純文本格式,上傳更快,當上傳文件需要支持大數量時可以用csv格式,如下所示:
說明:可在導入之前的頁面或在導入模板中加入導入說明,導入說明一般是對導入規則的解釋,主要目的是告訴用戶如何正確導入,避免導入失敗。
需要注意的一點是,最好支持刪除說明行不影響導入,匹配表頭就能導入,以上圖為例就是說把前6行刪掉也不會影響導入,只能讀取到表頭項;再進一步表頭項缺失也沒事,只要必填表頭能匹配到就行。這樣做的好處是,用戶如果自己整理好了一個excel,他不用把數據貼到模板里,只用將excel表頭改成與模板一樣就行了,更加方便。
需要注意的另一點是,確定好支持導入的文件格式后,可以限制打開文件夾的格式為支持的格式,方便用戶更快的找到需要導入的文件?,F在還有很多是全部文件格式,找個表單找半天。
另另外一點注意模板里不要帶序號,直接用excel的行號就可以了,提示錯誤信息時可以直接用行號告知具體位置。
二、導入后執行時間
一般來說都是導入后立即執行,但是也可能存在定時執行,比如導入產品價格時,可能提前導入再在之后某個時間價格才生效。如果是定時生效,需要加上生效時間,并考慮未生效期間內的其他導入是否會造成影響。
三、導入覆蓋還是不覆蓋
覆蓋:指最新一次導入的內容會現將已有內容清空再導入,相當于覆蓋了。
不覆蓋:指最新一次導入內容已經存在在系統中時,數量類型的數據相加減,非數量類型的數據以最新一條為準;系統中有但是最新導入內容里沒有的那部分數據也不會被清空掉。
像導入庫存數據,最新導入的一次是覆蓋之前的記錄還是在之前記錄基礎上加減?當然這個要結合業務場景來看,比如我們用戶經常同時使用多個軟件,他們一般先從其他系統中導出庫存,再導入進我們系統,那這種情況肯定是要覆蓋前次記錄了,因為他們每次導入的都是當前的實際庫存,而不是變動的庫存。但是像下單時快捷導入產品,考慮到我們的下單場景是用戶可能有多個產品清單需要一起下單,多次導入的時候就適合不覆蓋,相同產品數量累加。
四、分步驟導入或直接導入
導入方式一般分為分步驟導入與直接導入(導出也同理)。
分步驟導入優點是可以導入很大的數據量,并且更加安全不易造成數據丟失。先將文件上傳,上傳完成后后端并不會對數據庫進行修改,等導入時再修改數據庫。我向開發問了下具體實現方法,一種是先把數據放在臨時表里,這樣可以判斷數據格式是否正確,另一種是先上傳到云端。
直接導入優點是更快捷,適用于數據量較小的情況。
如下所示為分步驟導入:
五、導入文件中的重復數據如何處理?
這條其實很容易和上面覆蓋、不覆蓋弄混,前面說的是當前導入批次和原先導入批次之間的事,這里說的是同一導入批次里行與行的情況,可以分為以下幾種情況:
- 重復數據以最后一條為準
- 重復明細的數量相加
- 重復數據導入失敗
具體使用場景大家可以想想,在評論里留言~~~
六、如何確定導入條數
支持導入的最大條數可以結合業務場景與系統能力確定,比如導入客戶,如果是SaaS產品,那一般用于用戶首次使用系統時,需要將客戶數據從之前使用的其他系統遷移過來。那我們可以先拉取當前系統上用戶的客戶數量并從大到小排序,再拿這個最大值與開發確認系統能否支持。如果不能支持,能否通過后端分批處理、或調整導入文件格式為csv、或前端分步驟操作等方法來曲線報國。
如果實在不行,就只能調整以滿足盡可能多的用戶。我們目標就是能讓大多數用戶可以一次性導入成功,而不是彈出導入文件過大,請分多次導入的提示條······
七、針對導入失敗的處理
可以分為以下幾種情況:
- 有一條導入失敗,整個導不進去
- 有一條導入失敗,只有這一條導不進去,其他都導入成功
如果導入內容相互獨立,那么可以選擇2;如果導入內容有某種關聯,比如順序不能變,那就得選1。
無論1或2,在導入失敗時都要做好提示,產品經理需要提前列好導入失敗的原因給到開發。導入失敗原因可以正著說,如請輸入必填項客戶名稱;也可以反著說,如客戶名稱不能為空。我建議正著說,因為告知用戶正確的做法,而不是指出用戶的錯誤會讓用戶更爽一些。不過更重要的是要統一,不能一下正著說,一下又反著說。
可以將導入失敗的數據單獨列在彈窗里展示,也可以將導入失敗的部分生成一個excel,并將失敗原因附在excel里。
如果是彈窗展示失敗原因,又可以分為直接在頁面上修改或者只展示不能修改,無論是哪種都要注意數據很多時對頁面性能的影響。
八、導入統一性
系統內如果有多處導入,注意導入頁面、導入模板樣式統一。對于一些通用的導入失敗原因,文描也最好一致或依循同樣的規則,比如必填項為空、單元格式錯誤、文件過大、表頭不匹配等等。
九、導入記錄
由于導入是批量修改數據的操作,出于安全考慮,一般會有對應的導入記錄頁面,方便出問題追蹤。
十、導入完成后的操作
如果導入成功后,還有其他操作,可以在導入后進行引導,達到操作的流暢性。
十一、小結
以上為本人工作經驗總結,希望有幫助到正在設計導入功能的產品同伴。有想法一定要在評論里說出來哦,有輸出才有成長!
本文由 @是喻雪 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash, 基于CC0協議
很實用,贊
很實用,贊一個
很用心
4.導入時最好顯示進度條
1.導入時可以選擇部分信息重復時是否導入
2.導出時前端可以增加“當前無數據可導出”的提示,減少導出下載后打開模板是空數據,有一些動態列的導出也可以有效避免無數據時的“尷尬”
3.導入模板建議增加樣式編輯鎖,這樣用戶只可以輸入數據,不可以修改樣式或表頭順序,減少因為用戶修改模板后引起的導入失敗
文章很實用,贊!??
對每一條導入數據獨立編號。
編號的重復算重復數據。
編號遞增。
能解決重復數據等很多問題。
就是編號維護麻煩些。
編號聽著像唯一標識,就像導入產品時,唯一標識SKU重復了,就可以判斷兩條重復了