批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器

編輯導讀:批量導入是在基礎數據錄入很常見的一個功能,即可以節省逐條新增的人力成本,又可以避免數據重複錄入的問題,一舉多得;但是模板處理不當,導入過程中不同報錯導入失敗,會讓用户煩躁不安。本文作者帶我們躲避設計裏的那些坑。

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器
一、明確的導入操作指引,減輕用户學習成本
  • 提供下載導入模板和導入模板的入口;
  • 下載和導入的模板入口在一個頁面,避免出現點擊“導入”,還要花時間找導入模板的情況。

常規設計如圖:

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器

(提供下載和導入的模板)

二、 字段/字符詳細説明,將導入失敗的風險扼殺在模板設計中1. 標註出必填和非必填字段

標註方式不限,可以為單元格角標(圖二)、字段前加 “ * ” 必填符號(圖三)、字體加粗或單元格顏色區別(圖四):

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器
2. 明確字符的類型,儘量細化字段的校驗顆粒度

導入中常見的字符類型:

文本:對文本長度進行限制。

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器

(若文本長度超出則報錯警示)

數字:整數(是否必須為整數)、正負數(是否允許負數)、小數(明確限制小數點後幾位),以上均需要進行提示説明。

特殊數字,如銀行卡號,確保單元格為文本格式,不會出現科學計數法,否則後台校驗無法通過,且用户錄入數據會很苦惱。

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器

(提前處理好數字的保存格式)

日期:規範時間格式,常見的有2020-07-24、2020/07/24、2020.07.24,但是用户實際使用的格式可能會超乎你的想象,畢竟很多人是不按規則出牌的。

所以格式有明確限制的,需要在模板中標明:

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器

(示例數據儘量列明模板允許的數據格式)

下拉框:可選範圍固定的字段,設計下拉選擇,可以避免用户手填錯誤信息的情況。

下拉選擇的值確認是在系統的表結構中已經存在的,杜絕出現導入模板有農業銀行,數據庫銀行表沒有農業銀行的情況。

也有可能出現用户直接從自己的excel表格複製數據,粘貼到模板中的情況,所以校驗字段是否和表對應很重要。

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器

(模板中設計好下拉字段可選範圍)

特殊符號:模板中有限制中英文輸入法的特殊字符,需要作出明確指示。

後者告知後台開發,對於中英文字符做兼容識別處理。

3. 鎖定禁止刪除的字段

以本模板為例:為了防止用户誤操作,鎖定了表頭字段數據和第二排的示範數據。

這裏需要和後台開發説明,示範數據已鎖定,數據的導入校驗從第三排開始。

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器

(警示用户列表已鎖定)

4. 附帶單位

數據有單位的,最好是在字段後標註上,以免用户對數據格式產生疑惑或者自己單獨在數字上加單位導致數據校驗不合格,無法通過。

(字段標註單位)

模板中可能會存在空格的情況,需要開發對空格進行處理。

避免正確數據因為有空格而校驗不通過,導入報錯而用户無法定位數據誤差的原因發生。

小結:模板內字段的設計與限制,更多的是產品對excel功能的熟悉程度靈活運用,以及如何和項目的實際業務結合起來,協助用户在信息的新增環節避錯。

三、報錯給予明確提示,提示導入成功的概率和用户體驗
  • 杜絕英文報錯提示用户體驗非常糟糕,很容易讓用户認為系統崩掉了。
  • 儘量明確的進行報錯提示,方便用户對錯誤數據進行處理後再重新導入。

常見的導入失敗原因有:

  1. 字符格式校驗不通過;
  2. 數據重複報錯;
  3. 必填字段缺失;
  4. 導入模板錯誤;
  5. 數據量過大,系統卡死;
四、重複導入如何處理1. 重複導入的定義

根據業務情況,確認具體哪些字段的重複屬於同一條數據,需要判定為重複數據。

一般會根據數據的主鍵來定義重複數據。

如下圖,員工個人信息以姓名和身份證號碼合併為主鍵,構成唯一的員工ID。

如果後台校驗到這兩個字段一樣,就不會再對其他字段進行校驗。

(姓名和身份證號形成ID,相同則報數據重複)

2. 是否允許重複導入

1)對於重複的數據,需要根據實際使用情況,確認是否允許導入。

2)不允許重複導入,則需要明確報錯提示。

重複導入的數據,處理方式可能有:用户刪除重複數據後再次上傳,後台報錯提示。

(明確指示重複的數據)

直接剔除掉模板中的重複數據,成功導入正常數據,頁面無提示;這種方式明顯減少了用户需要操作的步驟和內容,體驗更友好。

3)允許重複導入,處理方式可能有:

覆蓋原有數據,並且標記出變動的字段差異,甚至允許用户直接在頁面上對重複字段進行修改後保存再次上傳。

這種方式開發成本比較高,且僅適用於導入的數據量較小的情況。

(頁面修改重複字段後上傳)

直接覆蓋原有數據,且頁面無標記;這種方式開發成本較低,也不需要用户再做判斷,但是相應的可能會有一定的風險,比如用户誤修改了個別字段直接覆蓋了原有數據,導致其他環節出錯。特別是涉及到財務結算的模塊,慎用!

批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器
五、大數據量異步導入,節省用户時間

如果導入的數據量很大,或者校驗的字段需要調用的接口比較多,同步導入會佔用很大的內存。

且同步導入用户需要一直盯着頁面,無法使用其他窗口;若網絡發生故障或者其他原因,導致導入失敗,需要再次重新導入,用户體驗會很差。

所以對數據量比較大或者接口複雜的數據,可以採取異步導入的方式。

異步導入在條件允許的情況下,可以用進度條展示當前數據的傳輸百分比,預計完成用時。這樣用户離開窗口再次回來查看的時候,明確估算回查上傳的數據情況。

以上基本歸納了筆者在項目中踩過的“批量導入”坑,如有遺漏或者錯誤的地方,請大家指出。

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

題圖來自 Unsplash,基於CC0協議

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 2127 字。

轉載請註明: 批量上傳:別讓一鍵高效工具成為“導入失敗”的警報器 - 楠木軒