用單選還是多選？超多案例幫你完全掌握！

前幾天又重新拜讀了尼爾森（Jakob Nielsen）關(guān)于單選與復(fù)選的文章《Checkbox vs. Radio Buttons》，雖說經(jīng)典，但 2004 年的文章距離現(xiàn)在已有 18 年，有些原則在今天已經(jīng)不夠用了，有些甚至還可以拿出來探討幾番，倒是可以以此為引子和大家聊聊單選與復(fù)選。

文章里分享了一個小案例，在網(wǎng)頁注冊頁面上，遇到了以下選擇頁：

尼爾森指出在這個案例里，錯誤地使用了復(fù)選組件，因為這兩個選項是完全互斥的；另一個問題是展示了兩個又臭又長的問題，應(yīng)該使用一個簡短的提問：“是的，請向我發(fā)送有關(guān)產(chǎn)品的信息。”

按照文章中的理解，我們可以將方案改成上圖所示。文中指出，雖然很諷刺，但是單個問題用復(fù)選框是正確的。

在我看來這個例子在今天的互聯(lián)網(wǎng)環(huán)境里顯得太簡單了。如果今天的產(chǎn)品需求是：讓用戶設(shè)置是否接收消息推送，且消息推送還分為評論、點贊、私信、系統(tǒng)通知...等等呢？用戶對于評論、點贊、私信、和系統(tǒng)通知都可以選擇接受或不接受，且選項間并不互斥。那么它會是什么樣的呢？

相信大多數(shù)人的第一印象就如上圖所示，雖然邏輯上很對，但是不是會感覺怪怪的，哪里都不對卻又不知道從何說起？本期我們就來好好聊一聊單選與復(fù)選。

拓展閱讀：

講講怎么設(shè)計

1. 樣式

單選按鈕（Radiobox）的設(shè)計來源于老式汽車收音機的物理按鈕設(shè)計，老司機們用它來選擇廣播站點，當(dāng)司機選擇一個特定站點時，其他的按鈕都會被彈出，只能按下一個按鈕。

圖片來源：Tumblr

所以它的樣式也是收音機按鈕的擬物化設(shè)計，在網(wǎng)頁/桌面端中，單選的設(shè)計通常為「〇 + 選項」，如下圖所示：

而網(wǎng)頁/桌面端的多選（checkbox）則是以「口 + 選項 」的方式出現(xiàn)，如下圖所示。

移動端的列表和標簽都常用到單選，當(dāng)它是列表時，多見于以右側(cè)的打勾狀態(tài)表示選中，當(dāng)它是標簽時，多以染上主題色表示選中，如下圖所示：

有趣的是，桌面/網(wǎng)頁端表示單選的「〇 + 選項」在移動端通常會被用做多選，不信的話，現(xiàn)在拿起手機微信，發(fā)起個群收款看看？或者打開淘寶購物車，批量購買幾個商品看看？再打開網(wǎng)頁版淘寶，同樣批量購買幾件商品看看？

為什么會出現(xiàn)網(wǎng)頁/桌面端的單選樣式在移動端竟為多選的現(xiàn)象，目前為止沒有人做過討論，我也只能以我淺淺的移動端經(jīng)驗猜測一下：移動端相比網(wǎng)頁/桌面端畫面小，一個頁面所能承載的信息量遠遠不如網(wǎng)頁/桌面端，從空間上講，高亮選項比〇+√選中更節(jié)省空間；從信噪比上講，〇 對用戶選擇沒有任何助益，完全可以省略；實在需要通過√表示選擇狀態(tài)時，放在右側(cè)也比放在左側(cè)更不影響用戶的閱讀動線。此外從流程上講，網(wǎng)頁/桌面端一頁能解決的事移動端需要分好幾頁，因此，移動端單選多為選中即跳轉(zhuǎn)（實時操作），比如轉(zhuǎn)發(fā)選擇聯(lián)系人時，注冊時選擇性別時、選擇付款方式...對比而網(wǎng)頁/桌面端，單選多為列表里眾多問題中的一個，選完仍然留在該頁面，選中狀態(tài)的呈現(xiàn)比移動端重要得多。至于圓形還是方形的選擇，根據(jù)不同移動產(chǎn)品的設(shè)計風(fēng)格有不同的展現(xiàn)形式，沒有哪樣是絕對正確的，只能說現(xiàn)在大多數(shù)移動端都是用圓形，但方形的設(shè)計也存在，比如，Meterial Ddesign 就提供了方形的復(fù)選設(shè)計。一般來說只要自己產(chǎn)品內(nèi)的設(shè)計語言是一致的，就不會有什么問題。

大多數(shù)移動端對于標簽（或二級 tab）的單選和多選沒有做樣式上的區(qū)分，只是會在多選選中后，在標題或下一步操作旁列出所有已選項信息，這么多年大家用下來也沒見太多人說看不懂，大概移動端的試錯成本比較低，大家也更愿意嘗試。但是如果硬要區(qū)分的話，可以選擇都用膠囊做單選，矩形做多選。此外，還可以在文案中做適當(dāng)?shù)奶崾尽?/p>

2. 基本原則

對于何時使用單選、何時使用復(fù)選，一直以來都沒有什么爭議，規(guī)則一直都是相同的:

1. 當(dāng)存在 2 個或多個互斥選項且用戶只能選擇一個選項時，使用單選；也就是說，選中一個單選項將取消選擇之前在列表中的其他選項；
2. 當(dāng)存在多個選項且用戶可以選擇任意數(shù)量的選項時使用復(fù)選；每個復(fù)選項都獨立于列表中的所有其他復(fù)選項，選中一個項并不會取消選中其他項；

除此之外還有一些附加的建議，比如：

文案建議使用正向的措辭

反面案例諸如上述案例中的，選擇「要（yes）“不要給我發(fā)郵件”」，和「不要（no）“給我發(fā)郵件”」，肯定了否定總是比直接否定要繞更大的彎子；

單選項確保選項既全面又互斥

如果無法保證全面，需提供“其他”選項，比如在婚姻狀態(tài)里，除已婚、未婚外，如果你不知道還有別的什么狀態(tài)，最好提供“其他”選項作為補充，否則諸如，離異、喪偶等情況會無法使用該系統(tǒng)；

讓用戶通過點擊整個選項來選擇而不是「〇」或「口」

無論是單選還是多選，「〇」或「口」的面積都比較小，根據(jù)菲茲定律，更大的目標點擊速度越快，所以增大選項的熱區(qū)可以提升交互體驗；

拓展閱讀：

選項之間按邏輯進行排序

按邏輯組織排序選項可以減少用戶的理解成本；

這些都是沒什么爭議的基本原則，照做就行。

實例拓展

了解完單選與多選的通用樣式以及基本的設(shè)計原則，我們來講一些拓展場景。

1. 默認選項

既然是個選擇題，首先捋一捋是否要給用戶默認選項。對于默認選項這個問題，可以從平臺傾向和用戶使用習(xí)慣上去考慮。考慮平臺傾向很好理解，比如在支付場景，如果是今天我是給阿里做設(shè)計，會默認選擇支付寶付款，如果今天我是給騰訊做設(shè)計，就會默認選擇微信支付。如下圖所示淘寶網(wǎng)頁端付款頁面，就默認為用戶選中了平臺推薦的付款方式。

如果我們沒有平臺傾向，比如注冊頁面填寫性別，或者新學(xué)期選課，那么我們就不需要給用戶默認選擇了，避免因平臺引導(dǎo)性的設(shè)計導(dǎo)致數(shù)據(jù)偏差（比如，如果注冊時平臺默認選擇男性，那么會有大部分人因懶得修改導(dǎo)致這個平臺男性偏多，后續(xù)基于性別的所有分析都會出錯）。

當(dāng)然，沒有平臺傾向的情況下，我們可以多考慮一層用戶習(xí)慣，還是以支付為例，如果是一個無人在意的購物平臺，不需要引導(dǎo)用戶選擇支付寶支付或者微信支付，那么我們可以通過記住用戶上次的支付方式，來簡化購買流程，幫助快速成單。如果是在移動端，因為頁面有限，我們甚至可以做得極致一些。提供默認選項的情況下，大多數(shù)會只露出推薦選項和修改入口，把其他選項藏在二級頁面。比如淘寶的移動端支付，雖然選擇付款方式是個必選單選題，但它只在頁面里呈現(xiàn)了推薦選項和修改入口，其他付款方式都藏在了二級。

2. 只能用單選或多選嗎

我們聊回開頭的例題：讓用戶設(shè)置是否接收消息推送，且消息推送還分為評論、點贊、私信、系統(tǒng)通知。這么一通聊下來后，似乎可以得到以下優(yōu)化方案：

雖然看上去稍微好了一點點，但我一直認為，什么樣的邏輯用什么樣的樣式設(shè)計出來的方案只能達到 60 分，具體的場景還得做具體的分析。比如，在這個案例里，雖然接受消息類型理論上是一個多選，選擇多選樣式?jīng)]有什么問題，但是例子里所有的多選項之間是互斥且無關(guān)聯(lián)的，我們也可以簡單理解為是多個單一是否題，即“是否接收評論消息”、“是否接收點贊消息”...在一個復(fù)雜的多選題和多個簡單的是否題之間，多個簡單的是否題會更簡單一些，在移動端我認為開關(guān)（switch）會比多選（checkbox）更合適一些。

從多選改成開關(guān)后，視覺上的點擊熱區(qū)也跟著從難以用右手交互的左邊移到了右邊。簡單來說，如果此時選擇操作是該頁面的主操作，且可以拆解成不沖突的是否題時，可以考慮用開關(guān)代替多選（可以理解成一個長段落填空題會比多個是否題體感上復(fù)雜度高）。

3. 到底是單選還是多選

不知道有沒有細心的朋友發(fā)現(xiàn)，移動端有很多個理解上是單選的地方用的卻是多選的樣式，包括但不限于：登錄頁的同意協(xié)議條款、發(fā)送圖片是選擇原圖...

按理來說，這里的同意和不同意，發(fā)原圖和不發(fā)原圖，都更接近單選的邏輯，甚至可以用開關(guān)，那為什么不用呢？我們代入場景來思考下，登錄頁最重要的操作是什么，發(fā)送圖片的場景最重要的操作是什么？是登錄和發(fā)送圖片。是否發(fā)送原圖如果用開關(guān)就會因樣式過強搶了頁面內(nèi)主要任務(wù)，如果同時提供“同意與不同意”、“原圖和非原圖”同樣也擠占了較大的空間。此外它還不是選擇即跳轉(zhuǎn)，需要在原頁面表示清楚可點擊狀態(tài)和選擇狀態(tài)，這種情況下用多選可以同時滿足點擊預(yù)期和狀態(tài)展示，又不會擠占空間搶走用戶本應(yīng)專注于主流程的注意力。（題外話：登錄頁的同意條款有一個歷史背景，最初的登錄頁都是默認勾選同意條款的，約 20 年初國家才規(guī)定了不許默認給用戶勾選同意條款，所以雖然它是個必選，理應(yīng)更明顯一些，卻一直沿用了以前的設(shè)計）。

4. 疊加選擇

實際項目中，我們還有可能會遇到更復(fù)雜的情況，比如還是以消息系統(tǒng)為例，如果在你選中了為我推送評論消息后，產(chǎn)品還希望能給用戶提供選擇評論消息來源的能力，那么應(yīng)該怎么設(shè)計呢？

在網(wǎng)頁/移動端遇到這樣的疊加選擇時，一般都會在題目后，再展開一個多選題，讓用戶選擇，如下圖所示：

這樣的思路直接套用在移動端的話會如何？我們畫出來后，那種“你不能說它錯，但就是哪哪都奇怪”的感覺又升上來了。

拆解一下哪里“怪”了。首先，選項里，接收來自陌生人、粉絲、好友的評論是接收評論消息的子選項，盡管兩種方案都有意地通過縮進表達選項間的關(guān)系，但顯然因為設(shè)計一致，所以感受并不明顯；其次，因為每個大類下都有許多小類，當(dāng)用戶點打開的消息類型多了，將統(tǒng)領(lǐng)的標題頂出了屏幕外，場景的目標會變得模糊；最后，當(dāng)用戶選擇接收系統(tǒng)消息，卻不在子類選項里選擇任何類型時，那么用戶是接收系統(tǒng)消息還是不接收系統(tǒng)消息呢？這里存在一個邏輯缺陷。

遇到這種情況，我們可以采用分步驟的方式去解決，在一級頁面分消息大類：評論、點贊、私信、系統(tǒng)消息...在二級頁面選擇接收來源或者不接收，如下圖所示：

這樣既表達了層級關(guān)系，又讓上下文更緊密，且邏輯上也更嚴謹。如果這個產(chǎn)品的社交關(guān)系復(fù)雜點，有好友、特別關(guān)注、關(guān)注、鐵粉、粉絲、陌生人等，那么顯然我們不可能窮盡所有排列組合做單選，這時候可以在二級頁面做多選或者開關(guān)，如下圖所示：

之所以在這個例子里用了多選而不是開關(guān)，是因為這里的選項之間不互斥，不能簡單理解成 A 和非 A（不是鐵粉不代表不是粉絲），如果使用開關(guān)，當(dāng)用戶關(guān)閉了鐵粉的評論推送卻打開了粉絲的評論推送，就會邏輯不自洽（開關(guān)表示明顯的拒絕，而不選擇不代表拒絕）。

?當(dāng)然用戶或許會自動理解成“只接收非鐵粉粉絲”，但一百個讀者有一百個哈姆雷特，總有用戶有不同的理解，我們又很難講清楚哪個才是正確的。為了表達清楚產(chǎn)品功能，建議不要使用會帶來誤解的設(shè)計形式。

歡迎關(guān)注作者微信公眾號：「白話說交互」