數棧UI5.0設計實戰|B端表單這樣設計,不僅美觀還提效
表單是B端產品中最常見的元件之一,主要⽤於資料收集、校驗和提交。比如登陸流程的賬號密碼填寫,註冊流程的郵箱、使用者名稱等資訊填寫,都是表單應用的常見案例,在 中也是出現頻率⾮常⾼的元件。
儘管表單應用十分普遍,但在我們對舊版數棧產品進行調研時,發現許多產品同學都反饋了關於表單的問題。所以在實際設計時關於「 」會有很多需要去思考的問題:
· 標籤是使⽤左右佈局還是上下佈局更合適?
· 標籤⽂本過⻓要怎麼解決?
· 提示資訊怎麼顯示不會形成⼲擾?
· 操作按鈕居左還是居右?
· 控制元件⻓度整體排列還是按輸⼊預期錯落有致?
· ……
本文就根據 的設計邏輯,從表單構成、表單佈局,以及表單的互動形式等多⻆度梳理了這篇文章,希望能給大家帶來B端產品設計不一樣的啟示,這些乾貨知識相信你一定用的上。
表單的構成
儘管我們都對錶單很熟悉,但為了確保清晰,我們還是先介紹一下它的構成。一個基礎的表單通常由標籤、表單域、提示資訊、校驗資訊和操作按鈕等基礎元件構成。
標籤
主要⽤於告知⽤戶要錄⼊的內容,通常需要簡明扼要便於⽤戶理解。
標籤的放置分三種形式⽔平排列(右標籤),上下排列(頂標籤),顯示輸⼊框內(⾏內標籤)。
數棧⽬前的表單⻚以上下排列的表單樣式為主,⽔平排列的表單為輔。 使⽤上下表單形式⽬的也是為了解決UI4.0中⽔平表單所存在的問題,⽐如標題過⻓、對⻬、備註提示資訊位置不統⼀、視覺的整體性等。但不管標籤是上下排列還是左右排列都有各⾃的優劣勢,具體運⽤到⻚⾯中還是需要考慮實際的使⽤場景。還有⼀類⾏內標籤應⽤較少,主要⽤於搜尋框元件的使⽤。
上下排列-頂標籤
應用場景:
適⽤基礎表單、分佈表單、 、彈窗等表單互動形式。
優勢:
· 相⽐於左右對⻬標籤可容納更多字數
· 標籤與表單域聯絡更加緊密,視覺橫向移動距離⼩,最適合快速瀏覽操作(上下表單:單個標籤到輸⼊區平均耗時50毫秒;⽔平表單:單個標籤到輸⼊區平均耗時 240 毫秒)
· 資訊擴充套件性更強,可容納更多提示資訊來幫助⽤戶更具象的理解以及預防錯誤發⽣
· 表單整體佈局更加規則且有秩序
劣勢:
⼀定程度上佔⽤⼤量的縱向空間,縱向空間利⽤率不⾼。
左右排列-右標籤
應用場景:
⽤於 等縱向空間有限時,使⽤橫向排列減少⻚⾯⾼度佔⽐,⽐如:表格篩選可使⽤橫向表單來減少佔⽤⾼度,對⻬⽅式按照輸⼊框對⻬。
表單域
包含文字框、多行文字框、單選框、核取方塊和下拉選擇框等,用於採集使用者輸入或選擇的資料。根據不同型別的資料,選擇與之對應的錄入方式能夠提高表單操作的效率和使用者體驗。
文字錄入
是最基礎的資訊輸⼊⽅式。按照輸⼊的內容分為單⾏輸⼊框、多⾏輸⼊框和數值輸⼊框。但需要注意的是輸⼊項過多,操作就會變得繁瑣,在之前釋出的⽂章 中有提到過系統識別勝過記憶原則,⽤選擇代替輸⼊可以減少⽤戶的記憶負擔,也能減少輸⼊錯誤等問題,可以有效的提升操作效率。
應用場景:
當使用者輸入的內容不可預測或自由度程度高時使用。使用單行文字框適用於輸入文字字元數較少的場景;多行文字框適用於輸入文字字元數較多時,可以選擇使用拖拽文字框樣式或 的功能。
複合輸入框
輸⼊的內容帶單位/符號,使⽤ 讓輸⼊資訊更具整體性。
選擇錄入
是為⽤戶預先提供了⼀定的選擇範圍,在指定範圍中選擇⽬標選項進⾏錄⼊,在數棧的產品中⽐較常⽤的元件有單選、多選、選擇器、開關、時間選擇器等。
● Radio單選
在⼀組相關且互斥的資料中,⽤戶僅能選擇⼀個選項。
應用場景:
· 當選項數量少於5個時,使⽤平鋪可以減少⽤戶的操作步⻓,當選項過多時建議使⽤
· 在⼀組單選框中,可以設定⼀個最有可能被選擇或者最安全的選項作為預設選項
● Checkbox複選
允許⽤戶選擇⼀個或多個獨⽴選項。
應用場景:
· ⽤於篩選或批次處理的操作:⽤於過濾⻚⾯、選單中的資料,表格批次操作等
· ⽤於條款或條件級:選中 表明⽤戶同意這些條款或條件
· 當選項內容較少時(滿⾜(7±2 )法則),平鋪的互動效果更友好,⽅便⽤戶點選取消
● Switch開關
互斥性的操作控制元件,⽤戶可開啟或關閉某個功能。
應用場景:
對於⽤戶更改後⽴即⽣效的設定,使⽤開關。
● Select選擇器
當⽤戶需要從⼀組同類資料中選擇⼀個或多個時,可以使⽤下拉選擇器,點選後選擇對應項。
應用場景:
· 主要⽤於表單填寫(錄⼊)和屬性選擇(篩選)場景
· 當選項⼤於5個以上時,使⽤選擇器,保持潔⾯簡潔,避免混亂
● ⽇期/時間選擇器
這個⽐較明確,僅⽤於時間/⽇期的選擇或篩選。
應用場景:
當⽤戶需要輸⼊⽇期、時間資訊時,提供基礎的時間、⽇期篩選功能。
穿梭框
左右兩側佈局的 ,分為候選區和已選區,兩側資料平鋪在⻚⾯上,⽤戶可以以直觀的⽅式將資料從⼀側即時移到另⼀側,完成選擇或移除資料的互動⾏為。
應用場景:
需要更清晰的展示選擇內容時, ⽤直觀的⽅式展示出了更多的選項資訊,能夠減少因資訊隱藏造成的錯誤,⽅便⽤戶實時瞭解選擇的內容,增加⽤戶的確定感。
上傳錄⼊
⽤於傳輸⽂件或者提交相應的內容,⽬前數棧多數場景都是使⽤單個上傳樣式。
提示與反饋
在之前的文章中,我們提到了 中的“系統可見性原則”和“幫助使用者發現、判斷和修復錯誤”,這些都強調了 的重要性。在使用者進行任務操作的過程中,適當的反饋能夠讓使用者瞭解當前的狀態,並引導使用者進行正確的互動行為。
為了提供更好的使用者體驗, 提供了多種元件型別,來應對不同場景下的提示與反饋互動,例如警告提示、文字提示、必填項提示、 、Popover氣泡卡片提示等。此外,對於操作結果的反饋方式,我們也可以採用校驗反饋、全域性提示、通知提醒框、 、Popconfirm氣泡確認框、頁面反饋等。在整個表單填寫過程中,及時給予使用者相應的提示與反饋,可以顯著提高填寫的效率。
文字提示
提升⽤戶輸⼊內容的準確性和效率,使⽤提示性⽂案的⽅式顯示在操作區域。
應用場景:
· 在輸⼊框內顯示提示⽂案,告知⽤戶輸⼊規則,在⽤戶還未輸⼊任何字元時顯示
· 在表單域上⽅提示,對業務規則或輸⼊⽬的等資訊進⾏說明
必填項提示
當⻚⾯需要填寫的表單過多時,多數⽤戶都會表現出排斥,如果能明確告知⽤戶必填的表單,能夠極⼤簡化⽤戶錄⼊的流程,減少不必要的資訊⼲擾。
沿⽤了之前的“*”星號作為必填提示,也是⽬前⽤戶普遍⽐較習慣的⼀種形式。
應用場景:
· 任務中必須完成的操作需要標記星號
· ⼀個表單所有都是必填項時,為了避免產⽣理解性的錯誤,我們還是建議標記星號,因為部分⽤戶會習慣判斷⽆星號的表單不是必填內容
Tooltips⽂字⽓泡提示
常⽤於解釋說明,僅承載簡單的⽂案資訊。
應用場景:
· 展示幫助性資訊:解釋說明、幫助資訊這類提示更偏向於業務屬性,隨著⽤戶深⼊使⽤產品,這些資訊會變得不再重要,⽤戶檢視的頻率也會越來越低。所以我們通常會將這類資訊收起,當⽤戶不理解某個功能,或想要獲得更多資訊時,透過訪問“?”問號 icon 檢視相關聯的更多幫助性資訊。
· 增強互動的確定感:當⽤戶與界⾯進⾏互動時,⽂字提示能夠幫助⽤戶增強對所互動元素效果的確定感(如按鈕的操作提示)
· ⻚⾯位置有限時:當⻚⾯位置有限時,⼀些UI元素需要以簡化的形式出現(如單獨的圖示),或者⽂字省略,使⽤⽂字提示能夠更好的幫助⽤戶理解資訊
Popover⽓泡卡⽚提示
常⽤於承載資訊和操作,承載的內容和形式更為多樣。
應用場景:
在使⽤場景上, (Popover)可以像⽂字提示(Tooltip)⼀樣為⽤戶提供幫助,但整體來說擴充套件性更強。⼀⽅⾯,Popover 可以承載更多的圖⽂資訊,提供詳情預覽的功能;另⼀⽅⾯ Popover 允許⽤戶在其中進⾏⼀些簡單操作,在功能上更接近彈窗。
警告提示
向⽤戶傳遞與當前⻚⾯相關的⾏為反饋、公告資訊。提示較為醒⽬,通常顯示在⻚⾯頂部,或者彈窗頂部,隨容器寬度⾃適應。⾮浮層的靜態展現形式,始終展現,不會⾃動消失,⽤戶可以點選關閉。
應用場景:
· ⽤於向⽤戶傳遞產品或系統的重要提醒,與⽤戶的任務或狀態⽆關,會⼀直存在,直到被⽤戶處理或關閉
· 僅在必要時使⽤提示,且應將提示限制在與之內容相關的任務界⾯中
校驗反饋
⽤於表單等控制元件的結果反饋,顯示在對應控制元件下⽅,在操作後消失。
應用場景:
⽤於表單、表格等資料錄⼊場景下,當⽤戶輸⼊的內容不符合欄位或表單的要求顯示。
全域性提示
全域性展示操作反饋資訊,可提供成功、警告和錯誤等反饋資訊,頂部居中顯示並⾃動消失,是⼀種不打斷⽤戶操作的 。
應用場景:
· ⽤於執⾏操作後提供的操作結果反饋,如成功、失敗等提示
· 只提供結果反饋,不提供給操作按鈕,如果需要⽤戶對結果做出回應,建議使⽤ Modal 對話方塊
通知提醒框
向⽤戶反饋重要的警告提示和通知訊息,⼀般顯示在⻚⾯的右上⻆,可以⼿動關閉,也可以設定時間⾃動關閉,⽬前數棧產品內是在彈出⼏秒後⾃動關閉。
應用場景:
· ⼀般⽤於系統級通知,需要吸引⽤戶關注但⼜不強制⽤戶去處理的場景
· 通知提醒框為內容提供的空間有限,因此內容必須簡短明瞭,⽤戶應該能夠快速瀏覽通知,瞭解情況,並知道下⼀步該做什麼
頁面反饋
以⻚⾯的形式展示操作結果反饋,或進⼀步引導。
應用場景:
⽤於某個任務流結束後的結果反饋,且⽤戶⾮常關注此任務的結果時,建議使⽤落地⻚反饋結果。
表單操作按鈕佈局
在資料錄⼊完成後,需要對任務進⾏儲存、提交或者取消等操作。除了對錶單任務進⾏儲存/提交操作外,還需提供⽤戶能夠隨時取消當前執⾏的任務的操作。所以通常表單⻚都應提供兩個按鈕,確定/儲存和取消操作。
按鈕之間需要區分主次關係,按鈕作為主要的視覺引導,在⼀個焦點任務中最多隻使⽤⼀個主按鈕。同時存在多個主按鈕會讓⽤戶失去操作焦點,造成資訊⼲擾。
按鈕居左
當表單內容靠左時,按鈕居左邊,主次關係從左到右排列。尼爾森團隊發表過一份關於《眼睛軌跡的研究》報告,其中提到了“F”型瀏覽模式。使用者的閱讀習慣一直以來都是從上到下、從左到右。因此,按照“F”型順序延伸,當表單佈局靠左時,按鈕組合的位置也應靠左。
再說到按鈕的 ,我們通常將靠近邊緣的按鈕視為主要按鈕。這是因為菲茲定律中有一條叫做邊角利用,邊界對於使用者的操作來說是“ ”的。當內容置於邊緣時,操作失誤率會大大降低。
按鈕居中
當表單內容分步時,步驟條位於⻚⾯中⼼,對應的操作按鈕同樣居中顯示。垂直佈局下,⽤戶瀏覽時的眼動路徑單純向下,這種由上⾃下的瀏覽效率是最⾼的。因此,對應的主次關係佈局應該遵循 ,主按鈕帶有明確⽅向,具有下⼀步性質的按鈕。
按鈕居右
彈窗的佈局是按照“Z”型構圖法,按鈕佈局在“Z”的末尾,按照 (對⻆線平衡法則)這個區域是⽤戶瀏覽⾏為的最終落點區域。當⽤戶任務進⾏到這個部分時需要採取措施,所以通常在這⾥放置按鈕或者⾏動點。主按鈕放在邊緣最右側,便於⽤戶快速獲得⽬標操作。
表單的佈局
表單的佈局形式影響著表單的操作效率,在表單設計時,我們通常會根據資訊的容量以及內容的關聯性來選擇合適的內容組織形式。內容組織形式分為三種基礎表單、分佈表單、分組表單。
基礎表單
是最簡單的佈局形式,將所有需填寫表單內容項直接羅列在⻚⾯上。
應用場景:
適用於內容較少、結構簡單的場景,表單項採用 。較短寬度且具有相關性的表單項可以組合在一行中,形成 的暗示。通常,操作按鈕會跟隨內容之後,當內容超出一螢幕後,操作按鈕會懸浮固定在底部。
分組表單
分組表單是按照一定相關性進行分組的表單,是遵循《 》中提到的四⼤策略之⼀“組織”的應⽤。在基礎平鋪的基礎上,將表單項中相關聯的表單項進行分組,使表單顯得更有規律和組織性。即使表單項較多,也不會顯得雜亂無章,減輕了使用者的心理壓力和視覺疲勞,提高了操作體驗。
應用場景:
適用於需要填寫大量內容的單次任務表單頁中,且不同內容之間存在一定的 時。
分步表單
同樣應⽤了四⼤策略中的另⼀項策略“轉移”——當任務較複雜時,為了更簡單易⽤,可以對複雜任務進⾏巧妙拆解轉移。將⽤戶需要錄⼊的複雜資訊按照線性流程組織拆解,利⽤步驟條告知⽤戶完整流程和進度。分步表單的流程化明顯,後⼀步填寫的內容常基於前⼀步來填寫。
應用場景:
分步表單適⽤於內容較多,並且前後步驟之間存線上性關係的情況。在數棧產品中,⼀般步驟⻚的資訊承載量普遍都會較⼤,按照縱向單列布局,導致⼀屏橫向空間空⽩過多,縱向路徑過⻓。所以為了確保資訊的 (⼀螢幕的內容曝光率),我們在做 時,採⽤多列平鋪的樣式。
優勢:
節省⻚⾯縱向空間,可以承載更多表單項,能夠放置更多的控制元件單元。
劣勢:
“Z”字型的視覺動線較為複雜,填寫體驗會相對差⼀些。
表單的互動形式
⽬前表單常⽤的互動形式有⻚⾯跳轉、抽屜、彈窗、⽓泡卡⽚、原位編輯。在什麼場景下選擇什麼樣的互動形式,通常會根據內容的承載量以及關聯度來判斷,從少到多依次為:⽓泡卡⽚ – 原位編輯 – Modal對話方塊 – 抽屜 – ⻚⾯跳轉。
氣泡卡片
不會影響原有任務程式,承載內容少。把內容的編輯修改操作及校驗放在 上完成,不會打斷原有任務程式。
原位編輯
其編輯內容也為展示內容,預設展示狀態操作,可切換為編輯狀態,屬於輕量型的資訊採集表單。
Modal對話方塊
⽤戶在不離開當前⻚的情況下繼續操作,是流程步驟中的分⽀⾏為,只能承載簡單的表單內容。
抽屜
擴充性更強,可承載⽐彈窗更復雜⼀些的表單內容。
頁面跳轉
最常⽤的⽅式,適⽤於絕⼤部分的表單,⽀持構建複雜的表單。
總結
表單是產品內操作成本較⾼的元件,操作中很容易引起⽤戶牴觸⼼理,所以在表單的整體完善度、元件的豐富度、互動的流暢度上還需要更深⼊的去探索。
希望本文能幫助你們最佳化表單功能,更多地考慮功能實現與體驗設計的平衡。
《資料治理行業實踐白皮書》下載地址:
《數棧V6.0產品白皮書》下載地址:
想了解更多有關大資料產品、行業解決方案、客戶案例的朋友,瀏覽袋鼠雲官網: https://www.dtstack.com/?src=szitpub
來自 “ ITPUB部落格 ” ,連結:https://blog.itpub.net/69995740/viewspace-3001718/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 如何製作實用美觀的設計文件
- 動態表單後端設計後端
- 你的工作不僅僅是程式設計程式設計
- 學習風變程式設計,學會的不僅僅是程式設計程式設計
- 網頁端表單設計要點網頁
- 程式設計師不僅僅是寫程式碼程式設計師
- ui設計師要懂哪些B端設計原則?UI
- 自定義表單 動態表單 表單設計器 流程引擎 設計方案
- <數字IC設計> 實戰專案之GPIO埠設計 3
- Principle如何製作動效設計?簡單易學的Principle動效設計教程
- Netty實戰:設計一個IM框架就這麼簡單!Netty框架
- 52歲程式設計師的觀點:程式設計要快還是慢?程式設計師
- 時尚的不僅僅是它們的服裝,還有它們的網站設計網站
- 前端能做什麼?還是後端?全棧?程式設計師的迷茫前端後端全棧程式設計師
- 程式設計師的迷茫:前端能做什麼?還是後端?全棧?程式設計師前端後端全棧
- 為什麼要這樣設計,還是我理解錯誤
- 居然還能這樣——程式設計師加薪的新方法程式設計師
- 設計模式---外觀設計模式設計模式
- 設計筆記:世界觀設計筆記
- 看完這篇原型設計模式,還不會,請你吃瓜原型設計模式
- java 流程引擎 表單設計器 設計方案Java
- 流程表單開發設計器設計方案
- 程式設計師的美麗假期(並不)程式設計師
- 傷不起的全棧程式設計師全棧程式設計師
- 注重實效的程式設計師程式設計師
- 流程表單設計器
- 淺談表單設計
- 程式設計師該不該主動提加薪?程式設計師
- 袋鼠雲數棧UI5.0煥新升級,全新設計語言DT Design,更懂視覺更懂你!UI視覺
- 十條不錯的程式設計觀點程式設計
- IP地址還可以這樣設
- 4分鐘內完成網頁設計:簡單美觀通用的CSS - jgthms網頁CSS
- 不會 A/B 測試的 Web 設計師不是好程式設計師Web程式設計師
- MetaWork:拜託,這樣遠端結對程式設計超酷的!程式設計
- java 工作流表單設計器 設計方案Java
- 程式設計師的世界盃觀戰指南程式設計師
- 實際工作中是這樣程式設計的程式設計
- 幽默:全棧程式設計師與前後端程式設計師區別全棧程式設計師後端