楠木軒

論後台產品經理如何優雅地設計導入功能

由 勞新忠 發佈於 奇聞

編輯導讀:導入功能是後台產品必不可少的功能,也是使用頻率最高的功能之一。作為一個後台產品經理,應該如何設計導入功能呢?本文作者從自身工作經驗出發,對此進行分析,希望對你有幫助。

對於後台產品,導入是系統裏必不可少的功能之一。如何設計好一個導入功能,瞭解以下幾點就夠啦(如果你覺得不夠,請在評論補充)。

一、如何定義導入模板

首先導入模板一般是由產品給出,需要率先確定導入模板的名稱、格式、大小。下面以表格為例:

名稱:模板名稱與模板內容相匹配就行了

格式:常見表格格式為xls、xlsx、csv

其中csv為純文本格式,上傳更快,當上傳文件需要支持大數量時可以用csv格式,如下所示:

説明:可在導入之前的頁面或在導入模板中加入導入説明,導入説明一般是對導入規則的解釋,主要目的是告訴用户如何正確導入,避免導入失敗。

需要注意的一點是,最好支持刪除説明行不影響導入,匹配表頭就能導入,以上圖為例就是説把前6行刪掉也不會影響導入,只能讀取到表頭項;再進一步表頭項缺失也沒事,只要必填表頭能匹配到就行。這樣做的好處是,用户如果自己整理好了一個excel,他不用把數據貼到模板裏,只用將excel表頭改成與模板一樣就行了,更加方便。

需要注意的另一點是,確定好支持導入的文件格式後,可以限制打開文件夾的格式為支持的格式,方便用户更快的找到需要導入的文件。現在還有很多是全部文件格式,找個表單找半天。

另另外一點注意模板裏不要帶序號,直接用excel的行號就可以了,提示錯誤信息時可以直接用行號告知具體位置。

二、導入後執行時間

一般來説都是導入後立即執行,但是也可能存在定時執行,比如導入產品價格時,可能提前導入再在之後某個時間價格才生效。如果是定時生效,需要加上生效時間,並考慮未生效期間內的其他導入是否會造成影響。

三、導入覆蓋還是不覆蓋

覆蓋:指最新一次導入的內容會現將已有內容清空再導入,相當於覆蓋了。

不覆蓋:指最新一次導入內容已經存在在系統中時,數量類型的數據相加減,非數量類型的數據以最新一條為準;系統中有但是最新導入內容裏沒有的那部分數據也不會被清空掉。

像導入庫存數據,最新導入的一次是覆蓋之前的記錄還是在之前記錄基礎上加減?當然這個要結合業務場景來看,比如我們用户經常同時使用多個軟件,他們一般先從其他系統中導出庫存,再導入進我們系統,那這種情況肯定是要覆蓋前次記錄了,因為他們每次導入的都是當前的實際庫存,而不是變動的庫存。但是像下單時快捷導入產品,考慮到我們的下單場景是用户可能有多個產品清單需要一起下單,多次導入的時候就適合不覆蓋,相同產品數量累加。

四、分步驟導入或直接導入

導入方式一般分為分步驟導入與直接導入(導出也同理)。

分步驟導入優點是可以導入很大的數據量,並且更加安全不易造成數據丟失。先將文件上傳,上傳完成後後端並不會對數據庫進行修改,等導入時再修改數據庫。我向開發問了下具體實現方法,一種是先把數據放在臨時表裏,這樣可以判斷數據格式是否正確,另一種是先上傳到雲端。

直接導入優點是更快捷,適用於數據量較小的情況。

如下所示為分步驟導入:

五、導入文件中的重複數據如何處理?

這條其實很容易和上面覆蓋、不覆蓋弄混,前面説的是當前導入批次和原先導入批次之間的事,這裏説的是同一導入批次裏行與行的情況,可以分為以下幾種情況:

  • 重複數據以最後一條為準
  • 重複明細的數量相加
  • 重複數據導入失敗

具體使用場景大家可以想想,在評論裏留言~~~

六、如何確定導入條數

支持導入的最大條數可以結合業務場景與系統能力確定,比如導入客户,如果是SaaS產品,那一般用於用户首次使用系統時,需要將客户數據從之前使用的其他系統遷移過來。那我們可以先拉取當前系統上用户的客户數量並從大到小排序,再拿這個最大值與開發確認系統能否支持。如果不能支持,能否通過後端分批處理、或調整導入文件格式為csv、或前端分步驟操作等方法來曲線報國。

如果實在不行,就只能調整以滿足儘可能多的用户。我們目標就是能讓大多數用户可以一次性導入成功,而不是彈出導入文件過大,請分多次導入的提示條······

七、針對導入失敗的處理

可以分為以下幾種情況:

  • 有一條導入失敗,整個導不進去
  • 有一條導入失敗,只有這一條導不進去,其他都導入成功

如果導入內容相互獨立,那麼可以選擇2;如果導入內容有某種關聯,比如順序不能變,那就得選1。

無論1或2,在導入失敗時都要做好提示,產品經理需要提前列好導入失敗的原因給到開發。導入失敗原因可以正着説,如請輸入必填項客户名稱;也可以反着説,如客户名稱不能為空。我建議正着説,因為告知用户正確的做法,而不是指出用户的錯誤會讓用户更爽一些。不過更重要的是要統一,不能一下正着説,一下又反着説。

可以將導入失敗的數據單獨列在彈窗裏展示,也可以將導入失敗的部分生成一個excel,並將失敗原因附在excel裏。

如果是彈窗展示失敗原因,又可以分為直接在頁面上修改或者只展示不能修改,無論是哪種都要注意數據很多時對頁面性能的影響。

八、導入統一性

系統內如果有多處導入,注意導入頁面、導入模板樣式統一。對於一些通用的導入失敗原因,文描也最好一致或依循同樣的規則,比如必填項為空、單元格式錯誤、文件過大、表頭不匹配等等。

九、導入記錄

由於導入是批量修改數據的操作,出於安全考慮,一般會有對應的導入記錄頁面,方便出問題追蹤。

十、導入完成後的操作

如果導入成功後,還有其他操作,可以在導入後進行引導,達到操作的流暢性。

十一、小結

以上為本人工作經驗總結,希望有幫助到正在設計導入功能的產品同伴。有想法一定要在評論裏説出來哦,有輸出才有成長!

本文由 @是喻雪 原創發佈於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash, 基於CC0協議