表單設計規範，你不知道的那些事兒

表單的複雜，來自於多業務場景、規則的疊加。
為了讓表單規範真正具備指導意義，我們需要由小到大，由靜到動的來創建表單規範。以上內容節選自 PinDesign 設計期刊第 113 期

在上次的期刊里我們聊了如何更全局的看待表單的設計，思考如何正確的使用表單這個工具。所以本期的文章里我們假設表單的需求已經明確，那麼接下來我們就要運用這個工具來創建表單、收集信息。

既然是工具，那麼它就需要一套完整的體系和使用規則來輔助我們工作。這也就意味著我們需要一個明確的使用規則來讓設計師正確、高效的搭建表單，也就是我們今天需要討論的主題 - 如何創建一套合理的表單設計規範。

在過去的兩周里，我們接手了一個極其複雜的後台系統，與技術同學一起打造一個能夠高度復用的 Design System。而這套系統里使用頻次最高的就是表單，所以這期的文章我們將以此為原型來與大家聊表單設計規範。

表單規範的背景

我們之前聊到過，一旦涉及到規範那麼就需要具備明確的指向性。它應該能對一個具體的領域、業務提供直接的設計參考和約束，這也是設計規範能夠提供質量 & 效率保障的基礎。所以，在開始表單規範的工作之前我們需要明確它服務於哪一個具象的業務，這個業務場景中用戶的核心訴求是什麼。

有些時候大家會拿 iOS、Google 這類的系統級規範或者 Salesforce 的 Lightning Design、SAP 的 Fiori 來作為自己的前期參考，但在實際操作的環節中卻發現總覺得有些彆扭或不清晰。這其中的原因其實就是大家各自創建的背景是完全不一樣的。

iOS、Google 這類本質上是操作系統規範，平台希望提供更多的可能性來「生長」出各種各樣的產品，在其基礎之上能夠百花齊放。因為這些不確定性和不同行業的差異性，它們必須要將自己的 Guideline 「往下沉」，相對的做得更抽象。所以它們往往會更關注設計理念（設計世界觀）的建立，並將它們作用到最小的基礎元素上。

Salesforce 和 SAP 這類的產品則恰恰相反，它們面向的是非常明確的自有業務。Guideline 要解決的是非常具體的通用問題，因此我們還會看到一些變種或組合的複雜組件。所以在設計理念部分這類 Design System 則沒有那麼抽象，更加強調對這個行業領域的設計期望。

對於大部分設計師來說，我們的工作都是服務於某一個領域的產品以及它背後的一類用戶。這類領域以及用戶的特性所提煉出來的設計目標就是我們在設計時的約束，而這些約束則是我們在設計過程中進行決策的判斷依據。

這次所面對的產品是一個典型的後台系統，且會擴展到幾十個子產品，核心關注的是嚴謹、高效和可擴展。基於這些訴求我們給表單的設計定義了幾條約束（如下），大家可以帶著它們接著往後來看。

1. 信息展示優先

2. 減少操作成本
3. 兼顧國際化場景4. 正向推進任務的完成

設計的策略

在確定好對設計的期望後，接下來就是具體的分工。因為工期的緊迫性和資源問題，我們不得不設計、技術部分的並行。而在設計端我們將復用度最高的表單和表格基於第一個子產品最先進入了設計。

由於對業務領域的陌生和子產品的繁多，直接基於某個產品頁面的需求進行設計必定會給自己埋下不少的坑。因為還有很多未知的場景和功能是我們一時之間很難覆蓋到的。在後期大量復用的時候一定會遇到很多無法解決的問題，如此我們的表單規範必將是失敗的。

所以這裡我給大家的策略建議是由小到大，由靜到動。

由小到大

表單之所以複雜，很重要一點是來源於它所服務業務（特別是後台產品）的複雜度。各種業務邏輯的組合，不同「層級」的信息透出，一大達到一定的複雜度就會導致混亂，最後失控。

為了讓我們自己先不混淆，我們需要把表單的最小單元、單元組合、靜態展示、動態反饋拆看分別一步步的遞進處理。

什麼是「小」

在之前的文章里我們聊過，表單是用來向用戶獲取一組信息來用於與系統進行交互。那麼這裡我們可以先不把它看成組件，換成問題的角度，表單其實就是由一個個問題所組合起來的。

如果我們將表單問題還原成日常對話，這裡則是提出問題、給出回答、系統再給予反饋，這就是表單的最小的一個單元，我們就先從這裡開始，將表單的基礎組件搞清楚。

如果所有的問題都通過輸入框來讓用戶來完成回答，這效率顯然是不高的，也不利於我們數據的收集整理。比如這裡我們希望了解用戶當前是在讀書還是已經工作，我們一般都會通過一組 radio box 來給用戶選擇；如果希望獲取用戶生日，會給出一組Calendar；如果希望獲取用戶的自我介紹，會給出一個 Text area…

所以，基於一個完整問題的角度，我們把 Input 、Text area、Dropdown、Radio/Check box、Calendar… 這些不同的組件看做用戶回答問題的方式，我們需要為不同類型的問題提供更適合的回答方式。

當然有些業務比較複雜，基礎組件並不不能很好的滿足需求，所以也就出現了業務定製的組件。比如在 Salesforce 中用 Radiobox （下圖）衍生出來的工作日選擇器。這部分就是需要根據我們自己業務定製的部分。