表單是B端產品中最常見的組件之一，主要⽤於數據收集、校驗和提交。比如登陸流程的賬號密碼填寫，註冊流程的郵箱、用戶名等信息填寫，都是表單應用的常見案例，在數棧產品中也是出現頻率⾮常⾼的組件。

儘管表單應用十分普遍，但在我們對舊版數棧產品進行調研時，發現許多產品同學都反饋了關於表單的問題。所以在實際設計時關於「表單」會有很多需要去思考的問題:

· 標簽是使⽤左右佈局還是上下佈局更合適？

· 標簽⽂本過⻓要怎麼解決？

· 提示信息怎麼顯示不會形成⼲擾？

· 操作按鈕居左還是居右？

· 控制項⻓度整體排列還是按輸⼊預期錯落有致？

· ……

本文就根據數棧UI 5.0的設計邏輯，從表單構成、表單佈局，以及表單的交互形式等多⻆度梳理了這篇文章，希望能給大家帶來B端產品設計不一樣的啟示，這些乾貨知識相信你一定用的上。

表單的構成

儘管我們都對錶單很熟悉，但為了確保清晰，我們還是先介紹一下它的構成。一個基礎的表單通常由標簽、表單域、提示信息、校驗信息和操作按鈕等基礎組件構成。

標簽

標簽主要⽤於告知⽤戶要錄⼊的內容，通常需要簡明扼要便於⽤戶理解。

標簽的放置分三種形式⽔平排列（右標簽），上下排列（頂標簽），顯示輸⼊框內（⾏內標簽）。

數棧⽬前的表單⻚以上下排列的表單樣式為主，⽔平排列的表單為輔。數棧UI5.0使⽤上下表單形式⽬的也是為瞭解決UI4.0中⽔平表單所存在的問題，⽐如標題過⻓、對⻬、備註提示信息位置不統⼀、視覺的整體性等。但不管標簽是上下排列還是左右排列都有各⾃的優劣勢，具體運⽤到⻚⾯中還是需要考慮實際的使⽤場景。還有⼀類⾏內標簽應⽤較少，主要⽤於搜索框組件的使⽤。

上下排列-頂標簽

應用場景：

適⽤基礎表單、分佈表單、抽屜、彈窗等表單交互形式。

優勢：

· 相⽐於左右對⻬標簽可容納更多字數

· 標簽與表單域聯繫更加緊密，視覺橫向移動距離⼩，最適合快速瀏覽操作（上下表單：單個標簽到輸⼊區平均耗時50毫秒；⽔平表單：單個標簽到輸⼊區平均耗時 240 毫秒）

· 信息擴展性更強，可容納更多提示信息來幫助⽤戶更具象的理解以及預防錯誤發⽣

· 表單整體佈局更加規則且有秩序

劣勢：

⼀定程度上占⽤⼤量的縱向空間，縱向空間利⽤率不⾼。

左右排列-右標簽

應用場景：

⽤於表格篩選等縱向空間有限時，使⽤橫向排列減少⻚⾯⾼度占⽐，⽐如：表格篩選可使⽤橫向表單來減少占⽤⾼度，對⻬⽅式按照輸⼊框對⻬。

表單域

表單域包含文本框、多行文本框、單選框、覆選框和下拉選擇框等，用於採集用戶輸入或選擇的數據。根據不同類型的數據，選擇與之對應的錄入方式能夠提高表單操作的效率和用戶體驗。

文本錄入

⽂本錄⼊是最基礎的信息輸⼊⽅式。按照輸⼊的內容分為單⾏輸⼊框、多⾏輸⼊框和數值輸⼊框。但需要註意的是輸⼊項過多，操作就會變得繁瑣，在之前發佈的⽂章可⽤性原則中有提到過系統識別勝過記憶原則，⽤選擇代替輸⼊可以減少⽤戶的記憶負擔，也能減少輸⼊錯誤等問題，可以有效的提升操作效率。

應用場景：

當用戶輸入的內容不可預測或自由度程度高時使用。使用單行文本框適用於輸入文本字元數較少的場景；多行文本框適用於輸入文本字元數較多時，可以選擇使用拖拽文本框樣式或⽂本⾃動撐⾼的功能。

複合輸入框

輸⼊的內容帶單位/符號，使⽤複合輸⼊框讓輸⼊信息更具整體性。

選擇錄入

選擇錄⼊是為⽤戶預先提供了⼀定的選擇範圍，在指定範圍中選擇⽬標選項進⾏錄⼊，在數棧的產品中⽐較常⽤的組件有單選、多選、選擇器、開關、時間選擇器等。

● Radio單選

在⼀組相關且互斥的數據中，⽤戶僅能選擇⼀個選項。

應用場景：

· 當選項數量少於5個時，使⽤平鋪可以減少⽤戶的操作步⻓，當選項過多時建議使⽤下拉選擇器

· 在⼀組單選框中，可以設置⼀個最有可能被選擇或者最安全的選項作為預設選項

● Checkbox覆選

允許⽤戶選擇⼀個或多個獨⽴選項。

應用場景：

· ⽤於篩選或批量處理的操作：⽤於過濾⻚⾯、菜單中的數據，表格批量操作等

· ⽤於條款或條件級：選中覆選框表明⽤戶同意這些條款或條件

· 當選項內容較少時（滿⾜(7±2 )法則），平鋪的交互效果更友好，⽅便⽤戶點選取消

● Switch開關

互斥性的操作控制項，⽤戶可打開或關閉某個功能。

應用場景：

對於⽤戶更改後⽴即⽣效的設置，使⽤開關。

● Select選擇器

當⽤戶需要從⼀組同類數據中選擇⼀個或多個時，可以使⽤下拉選擇器，點擊後選擇對應項。

應用場景：

· 主要⽤於表單填寫（錄⼊）和屬性選擇（篩選）場景

· 當選項⼤於5個以上時，使⽤選擇器，保持潔⾯簡潔，避免混亂

● ⽇期/時間選擇器

這個⽐較明確，僅⽤於時間/⽇期的選擇或篩選。

應用場景：

當⽤戶需要輸⼊⽇期、時間信息時，提供基礎的時間、⽇期篩選功能。

穿梭框

左右兩側佈局的多選組件，分為候選區和已選區，兩側數據平鋪在⻚⾯上，⽤戶可以以直觀的⽅式將數據從⼀側即時移到另⼀側，完成選擇或移除數據的交互⾏為。

應用場景：

需要更清晰的展示選擇內容時，穿梭框⽤直觀的⽅式展示出了更多的選項信息，能夠減少因信息隱藏造成的錯誤，⽅便⽤戶實時瞭解選擇的內容，增加⽤戶的確定感。

上傳錄⼊

⽤於傳輸⽂件或者提交相應的內容，⽬前數棧多數場景都是使⽤單個上傳樣式。

提示與反饋

在之前的文章中，我們提到了尼爾森十大可用性原則中的“系統可見性原則”和“幫助用戶發現、判斷和修複錯誤”，這些都強調了提示與反饋的重要性。在用戶進行任務操作的過程中，適當的反饋能夠讓用戶瞭解當前的狀態，並引導用戶進行正確的交互行為。

為了提供更好的用戶體驗，數棧UI5.0提供了多種組件類型，來應對不同場景下的提示與反饋交互，例如警告提示、文本提示、必填項提示、Tooltips文字氣泡提示、Popover氣泡卡片提示等。此外，對於操作結果的反饋方式，我們也可以採用校驗反饋、全局提示、通知提醒框、Modal對話框、Popconfirm氣泡確認框、頁面反饋等。在整個表單填寫過程中，及時給予用戶相應的提示與反饋，可以顯著提高填寫的效率。

文本提示

提升⽤戶輸⼊內容的準確性和效率，使⽤提示性⽂案的⽅式顯示在操作區域。

應用場景：

· 在輸⼊框內顯示提示⽂案，告知⽤戶輸⼊規則，在⽤戶還未輸⼊任何字元時顯示

· 在表單域上⽅提示，對業務規則或輸⼊⽬的等信息進⾏說明

必填項提示

當⻚⾯需要填寫的表單過多時，多數⽤戶都會表現出排斥，如果能明確告知⽤戶必填的表單，能夠極⼤簡化⽤戶錄⼊的流程，減少不必要的信息⼲擾。

數棧UI5.0沿⽤了之前的“*”星號作為必填提示，也是⽬前⽤戶普遍⽐較習慣的⼀種形式。

應用場景：

· 任務中必須完成的操作需要標記星號

· ⼀個表單所有都是必填項時，為了避免產⽣理解性的錯誤，我們還是建議標記星號，因為部分⽤戶會習慣判斷⽆星號的表單不是必填內容

Tooltips⽂字⽓泡提示

常⽤於解釋說明，僅承載簡單的⽂案信息。

應用場景：

· 展示幫助性信息：解釋說明、幫助信息這類提示更偏向於業務屬性，隨著⽤戶深⼊使⽤產品，這些信息會變得不再重要，⽤戶查看的頻率也會越來越低。所以我們通常會將這類信息收起，當⽤戶不理解某個功能，或想要獲得更多信息時，通過訪問“?”問號 icon 查看相關聯的更多幫助性信息。

· 增強交互的確定感：當⽤戶與界⾯進⾏交互時，⽂字提示能夠幫助⽤戶增強對所交互元素效果的確定感（如按鈕的操作提示）

· ⻚⾯位置有限時：當⻚⾯位置有限時，⼀些UI元素需要以簡化的形式出現（如單獨的圖標），或者⽂字省略，使⽤⽂字提示能夠更好的幫助⽤戶理解信息

Popover⽓泡卡⽚提示

常⽤於承載信息和操作，承載的內容和形式更為多樣。

應用場景：

在使⽤場景上，⽓泡彈窗（Popover）可以像⽂字提示（Tooltip）⼀樣為⽤戶提供幫助，但整體來說擴展性更強。⼀⽅⾯，Popover 可以承載更多的圖⽂信息，提供詳情預覽的功能；另⼀⽅⾯ Popover 允許⽤戶在其中進⾏⼀些簡單操作，在功能上更接近彈窗。

警告提示

向⽤戶傳遞與當前⻚⾯相關的⾏為反饋、公告信息。提示較為醒⽬，通常顯示在⻚⾯頂部，或者彈窗頂部，隨容器寬度⾃適應。⾮浮層的靜態展現形式，始終展現，不會⾃動消失，⽤戶可以點擊關閉。

應用場景：

· ⽤於向⽤戶傳遞產品或系統的重要提醒，與⽤戶的任務或狀態⽆關，會⼀直存在，直到被⽤戶處理或關閉

· 僅在必要時使⽤提示，且應將提示限制在與之內容相關的任務界⾯中

校驗反饋

⽤於表單等控制項的結果反饋，顯示在對應控制項下⽅，在操作後消失。

應用場景：

⽤於表單、表格等數據錄⼊場景下，當⽤戶輸⼊的內容不符合欄位或表單的要求顯示。

全局提示

全局展示操作反饋信息，可提供成功、警告和錯誤等反饋信息，頂部居中顯示並⾃動消失，是⼀種不打斷⽤戶操作的輕量級提示⽅式。

應用場景：

· ⽤於執⾏操作後提供的操作結果反饋，如成功、失敗等提示

· 只提供結果反饋，不提供給操作按鈕，如果需要⽤戶對結果做出回應，建議使⽤ Modal 對話框

通知提醒框

向⽤戶反饋重要的警告提示和通知消息，⼀般顯示在⻚⾯的右上⻆，可以⼿動關閉，也可以設置時間⾃動關閉，⽬前數棧產品內是在彈出⼏秒後⾃動關閉。

應用場景：

· ⼀般⽤於系統級通知，需要吸引⽤戶關註但⼜不強制⽤戶去處理的場景

· 通知提醒框為內容提供的空間有限，因此內容必須簡短明瞭，⽤戶應該能夠快速瀏覽通知，瞭解情況，並知道下⼀步該做什麼

頁面反饋

以⻚⾯的形式展示操作結果反饋，或進⼀步引導。

應用場景：

⽤於某個任務流結束後的結果反饋，且⽤戶⾮常關註此任務的結果時，建議使⽤落地⻚反饋結果。

表單操作按鈕佈局

在數據錄⼊完成後，需要對任務進⾏保存、提交或者取消等操作。除了對錶單任務進⾏保存/提交操作外，還需提供⽤戶能夠隨時取消當前執⾏的任務的操作。所以通常表單⻚都應提供兩個按鈕，確定/保存和取消操作。

按鈕之間需要區分主次關係，按鈕作為主要的視覺引導，在⼀個焦點任務中最多只使⽤⼀個主按鈕。同時存在多個主按鈕會讓⽤戶失去操作焦點，造成信息⼲擾。

按鈕居左

當表單內容靠左時，按鈕居左邊，主次關係從左到右排列。尼爾森團隊發表過一份關於《眼睛軌跡的研究》報告，其中提到了“F”型瀏覽模式。用戶的閱讀習慣一直以來都是從上到下、從左到右。因此，按照“F”型順序延伸，當表單佈局靠左時，按鈕組合的位置也應靠左。

再說到按鈕的主次關係佈局，我們通常將靠近邊緣的按鈕視為主要按鈕。這是因為菲茲定律中有一條叫做邊角利用，邊界對於用戶的操作來說是“無限可觸發”的。當內容置於邊緣時，操作失誤率會大大降低。

按鈕居中

當表單內容分步時，步驟條位於⻚⾯中⼼，對應的操作按鈕同樣居中顯示。垂直佈局下，⽤戶瀏覽時的眼動路徑單純向下，這種由上⾃下的瀏覽效率是最⾼的。因此，對應的主次關係佈局應該遵循方向性原則，主按鈕帶有明確⽅向，具有下⼀步性質的按鈕。

按鈕居右

彈窗的佈局是按照“Z”型構圖法，按鈕佈局在“Z”的末尾，按照古騰堡原則（對⻆線平衡法則）這個區域是⽤戶瀏覽⾏為的最終落點區域。當⽤戶任務進⾏到這個部分時需要採取措施，所以通常在這⾥放置按鈕或者⾏動點。主按鈕放在邊緣最右側，便於⽤戶快速獲得⽬標操作。

表單的佈局

表單的佈局形式影響著表單的操作效率，在表單設計時，我們通常會根據信息的容量以及內容的關聯性來選擇合適的內容組織形式。內容組織形式分為三種基礎表單、分佈表單、分組表單。

基礎表單

基礎表單是最簡單的佈局形式，將所有需填寫表單內容項直接羅列在⻚⾯上。

應用場景：

適用於內容較少、結構簡單的場景，表單項採用單列縱向排列。較短寬度且具有相關性的表單項可以組合在一行中，形成弱分組的暗示。通常，操作按鈕會跟隨內容之後，當內容超出一屏幕後，操作按鈕會懸浮固定在底部。

分組表單

分組表單是按照一定相關性進行分組的表單，是遵循《簡約至上-交互設計四策略》中提到的四⼤策略之⼀“組織”的應⽤。在基礎平鋪的基礎上，將表單項中相關聯的表單項進行分組，使表單顯得更有規律和組織性。即使表單項較多，也不會顯得雜亂無章，減輕了用戶的心理壓力和視覺疲勞，提高了操作體驗。

應用場景：

適用於需要填寫大量內容的單次任務表單頁中，且不同內容之間存在一定的可分類歸納性時。

分步表單

分佈表單同樣應⽤了四⼤策略中的另⼀項策略“轉移”——當任務較複雜時，為了更簡單易⽤，可以對複雜任務進⾏巧妙拆解轉移。將⽤戶需要錄⼊的複雜信息按照線性流程組織拆解，利⽤步驟條告知⽤戶完整流程和進度。分步表單的流程化明顯，後⼀步填寫的內容常基於前⼀步來填寫。

應用場景：

分步表單適⽤於內容較多，並且前後步驟之間存線上性關係的情況。在數棧產品中，⼀般步驟⻚的信息承載量普遍都會較⼤，按照縱向單列佈局，導致⼀屏橫向空間空⽩過多，縱向路徑過⻓。所以為了確保信息的屏效⽐（⼀屏幕的內容曝光率），我們在做分佈表單佈局時，採⽤多列平鋪的樣式。

優勢：

節省⻚⾯縱向空間，可以承載更多表單項，能夠放置更多的控制項單元。

劣勢：

“Z”字型的視覺動線較為複雜，填寫體驗會相對差⼀些。

表單的交互形式

⽬前表單常⽤的交互形式有⻚⾯跳轉、抽屜、彈窗、⽓泡卡⽚、原位編輯。在什麼場景下選擇什麼樣的交互形式，通常會根據內容的承載量以及關聯度來判斷，從少到多依次為：⽓泡卡⽚ – 原位編輯 – Modal對話框 – 抽屜 – ⻚⾯跳轉。

氣泡卡片

不會影響原有任務進程，承載內容少。把內容的編輯修改操作及校驗放在⽓泡卡⽚上完成，不會打斷原有任務進程。

原位編輯

其編輯內容也為展示內容，預設展示狀態操作，可切換為編輯狀態，屬於輕量型的信息採集表單。

Modal對話框

⽤戶在不離開當前⻚的情況下繼續操作，是流程步驟中的分⽀⾏為，只能承載簡單的表單內容。

抽屜

拓展性更強，可承載⽐彈窗更複雜⼀些的表單內容。

頁面跳轉

最常⽤的⽅式，適⽤於絕⼤部分的表單，⽀持構建複雜的表單。

總結

表單是產品內操作成本較⾼的組件，操作中很容易引起⽤戶抵觸⼼理，所以在表單的整體完善度、組件的豐富度、交互的流暢度上還需要更深⼊的去探索。

希望本文能幫助你們優化表單功能，更多地考慮功能實現與體驗設計的平衡。

《數棧產品白皮書》下載地址：https://www.dtstack.com/resources/1004?src=szsm

《數據治理行業實踐白皮書》下載地址：https://www.dtstack.com/resources/1001?src=szsm

想瞭解或咨詢更多有關大數據產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠雲官網：https://www.dtstack.com/?src=szbky