在B端產品中，表單填寫是比較主要的一個模塊，而在填寫大量信息與數據的過程中，我們最怕操作被中斷需重新填寫信息、信息填寫沒有標準化導致冗餘等問題，因此筆者提出了基礎數據需要專人統一維護&某些簡單數據的快速自動維護等思考。

B端產品設計中，對於基礎性的數據維護上一直以來是個問題，業務人員在使用軟件系統時總想快點完成，不希望跳轉到很多頁面才能完成一件事情，頁面交互不應該過於複雜，用戶在實際的軟件使用場景里總是會被各種各樣的電話或者事務性工作所中斷，尤其是在B端產品中，需要填寫提交的表單項目有很多，自動保存和暫存用戶的輸入數據就變得尤為重要了，重新填寫一份單真的讓人很痛苦。

軟件的設計者和管理者從角色、風險的角度考慮，常常把一個業務流程拆分，進行流程化分配到各個相關人員的節點進行處理，軟件雖然可以劃分流程和功能操作權限。但是卻不一定能立刻提高協作的效率。

一、基礎數據需要專人統一維護

比如下圖的這個賣方、買方的單位名稱的選擇上，雖然考慮到了基礎數據單位的維護，但礙於角色權限的控制，強制了用戶必須先在對應的供應商單位維護模塊新增單位後，才能在這裡使用。而且因為權限的原因，避免單位維護的混亂，強制需要特定的人員進行單位數據維護，這樣就會中斷當前用戶的其它操作。

這裡區別於C端產品的設計，如常見的購物類APP中都會需要用戶先維護好“收貨地址”這個基礎數據，但是因為用戶一個人擁有所有的功能與數據權限，因此對於這種類型的基礎數據維護上就可以充分的考慮便捷性，為了完成購物的這個動作，需要快速的方便用戶進行數據維護。

當默認的收貨地址需要更改的時候，點擊【收貨地址】則彈出所有保存的收貨地址，而且可以立即添加新地址並使用，每個頁面的邏輯很清晰，用戶可以迅速的完成新增與保存收貨地址操作，且保存後默認使用該新地址作為此訂單的收貨地址。

因為維護數據的不同，軟件面向用戶的不同， 產生了不同的使用效率問題。

企業中要求提供完整的單位信息和審核之後才能在訂單中使用，新增一個單位也需要填寫繁瑣的關聯性信息（如：營業執照、納稅人識別號、開戶銀行、銀行賬號、開票電話、地址等），完全不同於C端產品的設計，追求的是信息的完整性，但每每落實到實際的業務場景中，卻又會阻礙員工之間的協同效率。

二、某些簡單數據的快速自動維護

企業對於供應商的風險管理控制無可厚非，但一定程度上降低了工作效率，業務流程化之後對於企業的整體運作上是很不錯的。

另外一些相關數據的維護上也可以不進行權限控制，每個人員提交自己的訂單後系統自動保存對應的數據供下次使用，這裡的例子中，是保存了對應單位的發站、到站、專用線代碼及名稱信息，因為沒有特定人員去維護信息，依據所有人員提交的數據供下次選擇使用，這樣就會產生很多冗餘的數據或者名稱相似的數據。

例如產生的冗餘數據站名，許昌站、許昌，因為每個用戶會有不盡相同的對同一個站的叫法，出現了同一個站的多種稱呼被保存起來。

有時候為了讓用戶快速進行操作，捨棄數據的準確性與完整性之後，雖然用戶提交的訂單多了，但是會產生很多名稱類似的信息，但其實是同一家單位，特別是在用戶沒有達成一致的業務規範的時候，就會產生這種冗亂數據的問題，反而會降低其它用戶使用效率。

不管採取哪種維護數據的方案，用戶最終想得到的是更準確的數據信息，更快速的下單，當下不了單時則想快點臨時添加一下進行下一步操作，當下次再次使用到這個存在的基礎信息時則想信息時準確的，系統對繁雜的數據不能僅僅是保存，還需要加入一定的判定與校驗邏輯，結合兩種方式，方便用戶的管理維護和臨時性下單的業務需求。

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

題圖來自Unsplash，基於CC0協議