如何應對複雜B端表單設計？這次給你兩個案例（下）

上篇在優設網發表後，看到有讀者評論說沒看到B端案例，也沒看到如何解決複雜性。害！都怪我想說的內容有千言萬語，還沒寫到B端案例和解決複雜性呢，就已經幾千字了…好了，關於這倆問題，今天的下篇全給說明白！

上篇回顧：

如何應對複雜的B端表單設計？來看這個結構化方法（上）

是的，我又寫表單設計了。

閱讀文章 >>

前文已經提到：對於特別複雜的B端表單，「簡化」只是提升其易用性的方法之一。遇到數據量大，層級深，數據之間有交叉或嵌套關係的表單時，還需要考慮該如何分析拆解、組織呈現這些數據。

我們今天的重點就是從整體上思考如何組織和呈現複雜程度各異的表單。具體方法的關鍵字就八個字：邏輯架構、視圖載體。最後是兩個案例分析。

邏輯架構

網上搜一下關鍵字「B端」、「表單設計」，會搜到很多相關設計經驗出來。不過大多數經驗試圖解決單個表單的佈局和樣式問題（比如標籤欄和輸入框是上下佈局還是左右佈局、左對齊還是右對齊），而非多個表單之間的邏輯架構和銜接關係。然而一個頁面不會無緣無故的出現，它承載了特定任務，特定任務是用戶達成目標的其中一環，和其他任務（頁面）環環相扣。需求不會脫離於場景單獨存在。場景中的需求，需要場景化的解決方案。

舉個例子，某商家要進貨，需要提供訂貨單（表單1），包含商品列表（表單2），收貨信息（表單3），開票信息（表單4），付費渠道和賬期方案等（表單5）。爲了保障多方合法權益，還需要在驗證簽署人意願後（表單6），在線簽署訂單合同（表單7）。還有賣家發貨後買家的簽收單等一系列表單（表單8）。如下圖：

上面的例子可以說明，即使某個表單的數據量很大，依舊是單點問題。解決單個表單的佈局和樣式問題很重要，但這類問題處於相對較爲表層的位置，還得向深處繼續挖掘——如何處理多個表單之間的邏輯架構和銜接方式。

△右圖來自《The Elements of User Experience》（中文版本《用戶體驗要素》）

那麼對於環環相扣的複雜表單，解決方案會不會很複雜呢？其實一句話就能說清楚：

表單之間的關係從架構上看分成兩種——串行結構或者樹狀結構。（我暫時還沒發現第三種）

是不是有點像電路里的串聯和並聯？遇到複雜的，就理解成混聯，也就是兩種情況的互相嵌套，要拆解到最小顆粒度再分析。知道了這個，在調研其他產品的表單設計時，也可以把這兩種架構套進去學習別人如何組織內容的。

△剛纔提到的賣家進貨案例。

視圖載體

瞭解了架構，還需要搭配載體，也就是採用何種視圖——是頁面？還是彈窗？頁面可以是單頁，也可以是多個分頁；彈窗可以是模態的，也可以是非模態的。以下是一些常見視圖：

△非模態彈窗的表單和來源頁面關係緊密，但不要太複雜。

△常見的模態彈窗。

△模態窗也可以承載稍複雜的表單。

△一些UI組件提供了側滑抽屜的樣式，要防止用戶誤觸導致的數據丟失，對「關閉」操作進行二次確認。

△頁面是最常見的視圖形式。

△以表格形式聚合表單，形式高度結構化，整齊清晰。

△表單內輸入框之間可能存在聯動關係，聯動和層級關係需要表現清楚。

△如果表單頁面很長，儘量把內容分組，減少用戶心理負擔。可以利用摺疊面板允許用戶將內容摺疊，提升在不同模塊間的瀏覽效率。

△多步驟表單，將大任務拆解成小任務，配合成功反饋，可以提升用戶完成每小步的成就感，以及完成目標的信心。

以上是一些常見視圖，設計時採用何種形式，要綜合考慮以下幾個方面因素：

內容多少（內容太多就不適合放入彈窗內）
複雜程度（層級多少、是否存在聯動關係等）
邏輯結構（串行更適合分頁，樹狀結構適合在一個頁面內聚合）
設備限制（包括屏幕大小、設備使用方向）
和來源頁面關聯度（彈窗和新開頁面相比，彈窗和來源頁面的關聯度更強）

但這些因素本身沒有明顯邊界，所以也不存在絕對正確的選項。評估方案時，還需要把用戶使用場景中的干擾因素考慮進去（例如是一口氣完成還是分幾次間斷完成？是獨立還是協作的形式？）。

兩個案例分析

結合上面的內容，大家看看這兩個案例中的表單如何設計呢：

1. 某公司的調查報告

公司信息分成多個維度，例如擔保信息、資產信息等。

擔保信息包含多個擔保人或擔保企業，信息分爲基本信息和信用狀況。

資產信息包含房產、車輛。

涉及到自然人的信息，可以歸屬在不同類目下。

2. 評分卡配置

評分卡將多個模塊分數累加。

模塊由一個或多個評分項組成。

評分項由一組評分規則，規則需要設定分值。

談談我的設計思路

1. 某公司的調查報告

調查報告的信息層級較深，最底層模塊的字段數量也不少。爲了快速縱覽全局，我在表單旁放置了導航欄。導航欄有三個層級，可以直穿最底層，另外還添加了兩個細節——完成百分比和類目下的添加按鈕。這兩個細節的目的都是爲了提升用戶的控制感。

因爲同一個自然人的信息，可以歸屬在不同類目下（一個自然人擁有多家企業，並在各企業中擔任多個重要職責的情況很常見）。爲了數據庫的統一和規範，減少數據多處重複錄入而造成對數據庫的污染，我把自然人的基礎信息由「編輯」轉換爲「調取」，即「輸入」變成「選擇」。此人的基礎信息如果在數據庫中不存在，則需要在模態窗內添加。這樣不管公司信息維度如何劃分，各類目下的自然人信息都會和基礎信息建立映射關係。在建立用戶畫像時，此關聯數據還可以發揮重要價值。