在前兩篇文章中，我們主要講到 B 端產品最為重要的信息展示組件表格的設計思路，根據不同的場景對表格進行了答疑，同時部分讀者與我反饋，想讓我聊聊選擇組件的一些內容，今天就來簡單聊聊在「數據錄入場景」中的一個小點：選擇錄入。

往期回顧：

提前說一句：其實這篇文章快寫完時發現已經有類似的文章，由于自己寫文章并不會在乎市面上是否有同類型的文章，文章的靈感也多來源于自己的工作中遇到的實際問題。自己也并不是想重復造輪子，有“內卷”的那味兒，最后發出來的原因主要有兩點：

1. 為了能給大家把日期選擇、樹形選擇、穿梭框、成員選擇等業務復雜的控件講懂，沒有基礎的認知進行“憑空建樓”實屬困難。
2. 發現雖然有類似的文章，但大家所講的方向并不相同，對于選擇錄入場景的理解也不太一樣。

選擇錄入的痛點

選擇類型多：在我們常見的選擇類型中，常使用的有四種：“單選框、多選框、開關、下拉選擇。”這四類便是選擇組件當中的基礎組件。在實際業務的使用中，還會涉及到：“日期選擇、樹形選擇、人員選擇、穿梭框、級聯選擇、評分” 等一些業務層面的組件，類型之多再加上每種組件用法也不盡相同，因此需要在每種組件的區分上多加思考。

其實我在評審許多設計師的稿件中，經常發現大家對它使用的場景并不了解。比如在一個表單中，讓用戶選擇性別時，是采取下拉選擇、單選框、多選框甚至是開關呢？那如果我們選擇家庭住址又應該如何設計呢？這一系列問題都需要去解決。

細節多：選擇錄入看起來是一個小小的按鈕，好像當中的細節不會特別復雜，但當你實踐過后就知道，其背后有著許許多多的潛臺詞以及默認規則。比如單選框是沒有讓用戶進行取消的操作；開關是不會讓用戶進行提交保存的，默認規則往往是這類交互本身所包含的。因此讀懂組件中的潛臺詞，也就是我們要做的事。

由于知識點很多，想要把它們完整講清楚需要花大量時間，因此我會在后續的文章中與大家逐一拆解，掰開揉碎慢慢消化，篇幅有限，今天我們先來聊聊前面幾個稍微容易理解的：「單選框、多選框、開關」，究竟應該如何設計～

先科普一個知識點，Tooltip / Popover 的區別

這是來自我 B 端交流群的一個討論，起因是有一位同學展示了自己產品的一個截圖

圖上可以看到，他的 tooltips 巨長無比，并引發了一系列的討論：

討論過后，有朋友私聊我，咨詢我“這兩個控件誰更加好”，但組件本身就不存在孰優孰劣，更多則是場景不同，使用的控件也會不盡相同。為了更好讓大家的理解兩個控件的區別，這里將它們進行簡單的對比，通過相同點與不同點去分別講解，讓大家有更全面的了解。

首先，對于 Tooltip 來說，它其實就是一個信息提示的小玩意兒，當用戶對某一未進行文字解釋的圖標進行 hover 時，便可采用 Tooltip 對該圖標的含義進行解釋，這也是我們日常工作中用到最多的情況。而對 Popover 則感覺大家會有些陌生，其實在我們常見的新手引導、確認提示中都會使用這個控件，并且在很多 B 端設計場景中，往往都可以通過這個控件進行相應的簡化。

1. 二者相同點

相同點我們主要會從形式、功能、方向三個方面去思考。

形式

它們兩者在設計的形式上都是非常相似的點，都是采取浮層進行信息的展示，并且通常都會跟著一個小“尾巴”來代表它所來源的方向，此外在窗口大小上也基本相同，因為小窗口也意味著它所承載信息會相對較少，后面會細講內容.

方向

在對其的實際運用中，都會涉及到彈出方向的不同。在實際項目中，彈窗方向一般是以上下左右四個方向進行彈出，而從上方彈窗是一般的默認方向，在外部容器限制的前提下，會對彈出方向進行改變，同時在容器角落時，會沿容器反方向的角落進行彈窗即可。

對于使用兩者的功能而言，只能說大致相同，細枝末節上還是會有不小的區別。在功能上，兩者幾乎都是想要提示用戶某些隱藏信息，并且信息的重要程度都不會太高，因此足夠輕量就成為它的關鍵屬性。

2. 二者不同點

其實兩個除了在外觀上較為接近，其實在很多地方都是不同的。

承載內容

一般 B 端的內容共有：圖標、文字、鏈接、按鈕、圖片等，我們首先說說 Tootip，Tooltip 因其容器的特殊性，只能承載簡單的文本，并且 Tooltip 的提示一般不會多于 50 個字，只能對當前的內容進行簡單解釋。

比如在常見的輸入框標題提示中，經常會有「問號、嘆號」 圖標的出現，用戶就是通過 :hover 展示 Tooltip 對標題進行解釋。

而在 Popover 中，所承載的內容要比 Tooltip 更多，小到按鈕、鏈接，大到圖片、視頻，都在它的彈窗范圍內。

觸發方式

我們常見的觸發方式一共有：Hover、Focus、Click 三種方式。

由于承載內容的不同，進而影響觸發方式的不同。

因為 Tooltip 在內容上以純文字為主，并且多是 50 字以內的輔助信息，所以在觸發方式上，要就 Tooltip 能夠及時觸發，因此當你鼠標 :hover 后，就應該將該內容的解釋信息告知給用戶，方便用戶使用。

而在 Popover 則恰恰相反，因為其內容承載較多（有圖片、按鈕等等…），如果通過 :hover 進行內容的呈現顯然是不太合理，并且通常會使用有確定、是否的對話，讓用戶進行操作，所以使用 :focus、:click 更友好。

3. 閱讀性不同

由于觸發方式的不同，進而在閱讀性上會有所干擾。

因為 Tooltip 本事是通過 :hover 進行觸發，也就直接造成在設計上，對于 Tooptip 會采取對比度更強的黑色底，這樣用戶對于信息提示能吸引更多注意力，而黑色的背景，對于用戶閱讀來說會更加困難，也因此側面反應這里的文字不宜過多。

Popover 則不會有上面的煩惱，因為是通過用戶的明確點擊而來，用戶對彈出內容已經有所預期，因此可使用白色底，閱讀性會稍好于前者。

4. 用法不同

如果說了那么多，不講怎么用便是在真正的耍流氓，因此最后我們來看看他的實際用法有哪些。

Tooltip

其一就是用來幫助用戶了解到某些圖標的含義目的，這已經是桌面端必備的邏輯，比如微信中。其二為了展示截斷的文本，因為 B 端很多長文本的場景，用戶想要提前知道，幫助用戶進行判斷。

Popover

其一可以作為警告用戶的一種提示信息，需要用戶再次確認，同時它相比 Dialog 更為輕量。

其二作為新手引導，可以讓用戶進行一步步的確認，它的輕量剛好能夠適合進行新手引導。

OK，了解完兩者的區別后，我們繼續選擇錄入，小本本準備好～

單選框 Radio

1. 單選框的歷史

單選框，也常叫做單選按鈕、單選，它最早來源于收音機上的物理按鈕，當時用于收音調頻之間的相互切換。當一個按鈕被按下時，另一個按鈕將會被彈起，使收音機只能擁有一個“按下狀態的”按鈕。

而早在計算機用戶界面誕生之初（The Xerox Alto）就已經有了單選框的出現。同時在 HTML 的底層中，Radio 就作為一個最基礎的標簽，擁有「無法撼動的地位」，所以在各大設計系統中一直作為基礎組件被沿用至今。

但隨著移動互聯網的普及，單選框這一形式在用戶心中被逐漸的弱化，取而代之的是各類功能相同但形式繁多的按鈕，這也是目前很多 B 端設計師存在的認知誤區之一。

單選按鈕：根據移動端的交互形式與「菲茲定律」，單選按鈕主要將自己的熱區擴大，能夠更方便使用鼠標進行點擊操作，可針對特定的 B 端產品進行優化。但面積增大的同時帶來的是屏效降低，作為 B 端產品，屏效比也是一個非常重要的因素之一，因此需要權衡兩者的利弊。

單選組：通過上面的單選按鈕，將兩個以上的按鈕進行排布，而形成的單選組，能夠盡可能增加展示效率。單選組的功能與 Tab 非常類似，也因此單選按鈕與單選組是一個相輔相成的過程。

2. 單選框的定義

單選框：允許用戶從多個選項中，選擇一個選項，且選項之間存在互斥關系，這也是「單選」名稱的由來。單選框的外觀一般是一個空白的圓洞，旁邊則通常有文字標簽；標簽的用途除了描述之外，還可以作為操作熱區，當用戶點擊標簽，所應用的單選框就會被選中；已選上的單選按鈕一般會在圓洞內加上一小圓點。

3. 單選框的交互邏輯

選項數量：使用單選框的選項數量一般為 2-5 個之間，因為在一個正常的表單中，是不允許寬度過寬而導致頁面排布困難的，同時使用多于 5 個的單選框，會十分影響閱讀效率，因此超出 5 個便可采取「下拉菜單」的方式進行展示。在工作中常見的的單選框為性別、是否選擇等…

默認選項：默認值在我們 B 端的設計中，往往是一把雙刃劍，你運用得好可以為自己的設計增加易用性，因為默認值本身在表單中并不常見（不可能給每一個表單都給上默認值），而在特定的場景中使用默認值會有意想不到的效果。

說一個我實際工作中遇到的內容，在我之前負責的一個關于醫美客戶系統的 SCRM 中，當客戶到店后需要由醫美咨詢師為每一位顧客新建一個客戶資料，而醫美行業的特殊性導致我們的大多數醫美客戶都為女性，因此在設計表單中的性別一欄上便可將默認值選擇為女性，這樣方便醫美咨詢師快速補充用戶信息，可以進行更高效的信息錄入。

當然，我說了雙刃劍肯定代表它也有弊的一面，我舉一個反例，比如我們在設計一個調查問卷中，去預設一些默認值就不太合理，因為問卷中需要減少對選項值的干預，保證其真實性，才能讓默認選項會導致錄入的數據產生準確，避免為后期的數據分析埋下“深坑。”

清除選擇：不知道大家有沒有發現，單選框在你選擇過后，就不能成為「為空狀態」。因為單選框沒有讓你跳過的回退機制，導致你在設計時就需要格外小心比如在一個表單中出現自己的婚姻狀況的單選框（非必填），里面有未婚、已婚、離異三種選擇，當我選擇未婚后，突然覺得這個信息較為私密，為了保證我自己的信息安全需要清除我剛才的選擇，這時我完全就沒有任何辦法，想要回退就只有一種選擇，刷新這個頁面，進行重新填寫。而我們在設計中不能避免此類方式，這時候就需要選項的 「容錯機制」

容錯機制： 既然單選無法清除選擇，我們就要對單選進行相應的優化，比如在選項中設置一個為「為空選項」對這類情況進行容錯處理，不然用戶就會感受到無法回退的尷尬。這都是單選框所帶來的潛在交互，大家在設計中一定要格外注意。

多選框 Checkbox

1. 多選框的定義

多選框，也常叫做復選框、勾選框，它允許用戶選擇一個或多個獨立選項，將自己想要的選項作為值，多個條件間的邏輯關系為并列關系。

多選框在實際業務中其實也分為兩種不同形態：單個多選框與多選框。

單個多選框：英文叫做（single checkbox）只出現一個多選框提供給用戶進行選擇，只包含“是”與“否”兩種邏輯，用戶可以選擇其一。它與之后「開關 Switch」的邏輯十分接近，但兩者的適用場景也有很大不同。

比如在我們經常遇到的用戶協議的頁面中，同意協議通常都是采取單個多選框的形式，而開關相比單個多選框，更加強調選中的狀態。之后會與開關進行深度對比，不做延展。

多選框：是多選框的一種通用樣式，允許用戶選擇多個項，主要用于各類表單設計中，所以用戶對于它的認知、功能以及行為操作有明確的心理預期和感知。

2. 多選框的特殊狀態

多選框相比其它控件，增加了兩個較為特殊的狀態 “半選中” “禁用（已選中）” ，因此這里僅僅單獨講解，其他狀態便不做過多贅述。

半選中：

半選中狀態（Indeterminate）出現的條件必須具備以下兩點：

擁有「全選」功能，因為半選中狀態是全選狀態的一種特殊狀態形式，它依附于全選。所以是當一個選擇框中有全選狀態才會有幾率出現半選狀態。

擁有「選中狀態的子項」，如果我們把全選看作是「父」，則其下的子選項看作是「子」，因為交互底層邏輯便是狀態的改變需要隨時體現，因為「子」狀態的變化，作為「父」的狀態也應該隨之改變，這樣的父子聯動才會有半選中狀態的出現。

上面說到需要父子聯動，全選是選中其下所有的選項，而我只選擇了其下一個選項時，就應該展示半選中狀態。同時，當前多選框正處于半選中狀態時，點擊多選框會執行全選操作。

禁用-已選中：

禁用-已選中狀態（Checked-disable）出現多選表示該多選框已經被激活，只是在當前情況下不能進行操作。通常不能進行操作的場景有以下兩點：

登錄賬號權限不足，無法對該條數據進行修改。且在此之前，該條數據已經被激活。

該操作為系統級別操作，通常展示出來是為了讓用戶了解到有此類操作；同時并不允許用戶操作此權限。因而采取禁用已選中進行表示。

當然多選框還會有很多不同狀態，會在章節末尾進行表格總結。

3. 多選的交互邏輯

選項數量：與單選基本一致，因為所有選項基本處于外露狀態，因此不建議放 5 個以上的選項值，超過 5 個時可考慮采取下拉菜單的形式，避免選項多且復雜，難以把控。

默認值：默認值在多選框中并不常見，在一個多選框中設置默認值一定要思考清楚。當然這里也會存在用戶之前的數據，那就另當別論。

需要提交操作：在多選的場景中，提交是必不可少的一個操作情況。

4. 典型頁面

在實際工作中，多選框會出現在一些典型的頁面場景中，針對不同的頁面場景，我們來看看究竟應該如何進行處理。

用戶權限管理

在用戶權限管理頁面中，經常會出現多選框的身影，而在權限這類頁面中，往往是一個不斷重復排列的多選框，針對不同的角色，去選擇不同的權限。且每一個權限都是開啟或關閉狀態，因此采取多選框也尤為合適。我們來看看不同產品中，都有著哪些權限頁面設置的技巧。

語雀：

權限作為語雀的一個亮點功能，便將所有角色分為三類：管理員、成員、只讀成員

在定義中，因為管理員擁有全部權限，所以不需要用戶單獨進行配置。只讀成員同樣只會擁有單獨的查看權限，而我們需要去對成員進行單獨的配置，然后將成員的權限進行細分，由于權限的數量并不多，因此采取縱向排列，方便用戶將多個權限進行對比。

上面語雀的權限配置頁面過于簡單，在真實 B 端業務時就會顯得有些弱不經風。我們實際工作中面對多維度多層級的權限管理時，又應該如何設計？我們來看看 Coding 它是如何做的。

因為在一個正常的 B 端軟件中，權限通常會拆分得特別細，對于不同字段與角色，他們的權限也會不盡相同。

Coding 首先在左側會展示“用戶組”也就是我們上面說到的角色分類，用戶可以去自定義角色類型有哪些，其次在對角色權限的配置中，會展示出用戶可以自定義的所有功能，粗略估算大概會有 100+個權限，也就意味著會有 100+個多選框需要展示。當 100+的多選框放在你面前，最為基礎的對齊則顯得尤為關鍵。通過限制多選框標簽的整體寬度，強制將其縱向對齊，雖然遇到長文本時省略給用戶帶來不太友好的體驗，但對齊所帶來的留白、節奏感是遠比省略帶來的好處要多（當然在對長文本寬度的定義中，需要多考慮下常見字段的長度即可）

其次，在每一個大功能中，Coding 都設置有一個全選功能，目前放置在整個列表的末尾，是一個特別贊的設計，能夠幫助用戶對每一個字段的權限進行統一配置，是一個經常使用的快捷入口。

流程管理頁面

在流程管理頁面中，多選框也是不可忽略的頁面。因為在整個流程頁面中會對每個狀態執行開啟與關閉操作，因此在這里同樣會重復多選框。

比如在 ONES 的流程管理頁面中，看起來像是表格，其中縱向代表每個「流程開始狀態」，橫向代表每個流程階段所要去向哪些狀態，每個表格都會展示一個復選框，去配置它是否要流轉到此狀態，從而實現業務流轉的需求。

而在這里的設計，最令人頭疼的是整體的表現形式，因為目前而言，需要將初始狀態、新增狀態、激活狀態、禁用狀態等在一個表格中進行表示，更重要的是要能夠讓用戶理解整個表格所代表的含義，這也是目前能看到的最好的設計成品，大家有什么更好的建議，歡迎在評論區留言，大家一起討論。

表格頁面

表格頁面最為復雜多變，也因此在表格中的多選框出現了兩種不同的形式，一種將多選框直接展示，讓用戶更直接選擇。另一種則是 Hover 到每一行顯示多選框，同時一定要去注意全選與半選中的邏輯，在表格的設計上尤為重要，不能出現邏輯上的漏洞，這里也就不過多贅述。

最后補充一下多選框的所有狀態的交互邏輯

開關 Switch

1. 開關的定義

開關，它是一種特殊的選擇，其含義代表你的選擇非黑即白。它不同于上面的控件，當用戶點擊后，開關需要經歷一個加載狀態，然后「立即執行」。這樣的差別就導致開關的用法與其它控件并不相同，立即執行所帶來的及時性也是設計師最容易與其他組件進行混淆的點。

2. 開關的由來

在開關的早期，為了降低用戶的學習成本，模仿現實生活中的開關進行設計，而隨著扁平風格的到來，開關便得到了精簡，去掉原本產品中的質感、投影，轉向更加明確的「狀態信息」

轉眼到了 B 端產品中，很多設計師都會沿用這一習慣，但是在 HTML 的代碼邏輯里，并沒有 Switch 的標簽，也就意味著開關并不是網頁本身所支持的形式，在程序員處理上則需要花費更多心思。不過在目前常見的前端框架中，對開關都進行了支持，比如 Element、Antdesign 可以直接引用。

3. 開關的交互邏輯

雖然在組件上可以直接進行引用，但并不代表我們作為設計者，不需要去考慮它基本的交互邏輯以及使用場景。

即時性：開關是一個立即執行的操作，因此它打破了人們對于正常表單的認知（需要有按鈕進行數據提交），因此開關與表單是一個相互排斥的關系，兩者同時出現必然會產生些許矛盾，表單中使用開關切記要慎重。那如何處理開關與表單之間的關系？就需要理解開關與表單間的「權重關系」

權重關系：開關要比表單的權重更高。開關會位于整個表單的頂部，對下面的表單進行整體操作，說起來更點空洞，我們看一個 MacOS 的案例：

在最新 Big Sur 系統中，設置頁面就采取了類似操作，我們打開設置-通知，發現開關與表單同時存在。這里也可看到，允許通知的開關在最頂層，是控制整個表單權重最高的操作，同時下方單選、多選框、下拉菜單都受到頂部開關控制。

當然，我們在實際的設計中，同樣會遇到類似的情況，比如在飛書的自建應用免審規則配置中：首先用戶需要去選擇開啟此功能，開啟后下方會展開一個基本表單，用于用戶對應用規則中更為細致的配置，并且要注意，所有的配置都是實時生效，因此在每一次修改配置時，飛書上都會有 Loading 效果。

當然我們可以將開關換成單一多選框，但切換后用戶就很難理清一二級之間的邏輯關系，因此開關更為適合權重更高的操作。

明確性：開關能明確的表示當前的狀態，當開關亮起時，則代表開關進入開啟狀態，當開關置灰時則進行關閉狀態（感覺好像是廢話，但你得需細細的品）并且在開關的使用中，是通過表達當前系統的狀態，因此在開關所配合的文案中需要格外注意。

重要提示：因為開關的權重更高，狀態也更為明確，因此它的出現多為一些需要系統校驗的操作，對于用戶不滿足條件時，需要進行禁止的提示。比如在明道云的工作流列表中，用戶便可使用開關對流程進行快速開啟，不滿足條件時，會有提示彈窗進行提示，并能讓用戶快速跳轉進行修改操作。

加載狀態：最后開關作為一個關鍵操作，在 B 端系統層面上同樣會有進行加載的情況，這里就提醒一下大家，不做擴展。

4. 開關的討論 - 為開關正名

在互聯網上，時常看到 DISS 開關不應該出現在網頁設計中，這里看到了一篇文章中討論到《為什么在 web 上使用 Switch 是愚蠢的設計》，其實我有不同的意見，簡單說一說我對開關的看法：

因為在 B 端的場景中，會有很多特殊的要求，因此不能一桿子將 Switch 一桿子打死，凡事都得辯證看待，需要去看到開關好的一面，并且規避它的一些不足。首先，在 Web 端中不能大面積的去使用開關，因為大量的開關導致的就是對頁面設計的褻瀆，當然開關依然有它的獨特之處，在開關的交互邏輯中雖然已經提到了部分特點，但我還是來簡單說說我的理由：使用開關主要是想利用開關狀態去“做文章”。使用開關在比起其他條件，會更加強調它的狀態，并能讓用戶通過狀態去控制下層的其他組件（單選框、多選框等…）這就是開關在 B 端產品中的實際需求。同時因為開關是立即執行的操作，因此需要在每一次變更狀態時進行相應的反饋，比如表單組件狀態上的提示，輔助用戶進行判斷狀態即可。

回到我們討論的開關在 WEB 中的使用上，并不能因為開關不是 HTML 基礎標簽而去否定，并且在我們 B 端實際業務中，確實會遇到開關的場景，因此大家在使用開關時還是應該根據情況進行使用。

由于選擇錄入場景的內容較多，02 篇即將更新，歡迎大家關注

我是 CE 青年，一個 2 B 行業的 2B 設計師～

歡迎關注作者的微信公眾號：CE青年