下拉菜單這么簡單,為什么總監老是說用錯?
導讀:下拉菜單相關應用在平常的交互設計當中是少不了的一環,也是被用戶飽受批評的重災區。設計得不好會適得其反,讓它變成繁瑣與LOW的代名詞。這篇文章我們也跟上一篇radio button一樣,從根本上來分析下拉菜單的構造、應用場景、注意點。
一、下拉菜單的構造圖解
下拉菜單的設計結構和文本輸入框很接近,只是內容多一些,主要有十個部分構成。
- 欄目內容
- 容器
- 下拉箭頭
- 占位符或提示文本
- 滾動條
- 下拉菜單
- 菜單項
- 分割線
- 選中項
- 提示
二、下拉菜單的類型
1. 標準形態
標準下拉菜單是針對我們所理解的“下拉”這個動詞,在激活狀態,當你點擊文本輸入欄的地方時,它會打開一個菜單。這里值得注意的是因為受到下拉菜單高度的限制以及用戶操作效率,菜單項不宜過多也不介意太少,有研究發現當有超過 10 個或少于 5 個選項時,盡量避免下拉。
2. 自動提示形態
我個人是超級喜歡這種交互模式的,某些時候這個功能變得格外實用。比如選擇城市地區時,它可以讓用戶在一長串選項中優雅的找到自己心頭所愛,不用瘋狂的讓自己下拉一遍又一遍,
特別提醒:
- 在這個場景之下,用戶雙手是在敲擊鍵盤,所以該組件可以用鍵盤上的“????”來操作尤為重要。
- 同時也要考慮到有些場景,輸入信息是來自用戶的粘貼,所以該交互模式必須支持用戶粘貼信息。
3. 自動補充形態
這也是幫助用戶從眾多選項當中進行快速完成篩選的另一種交互設計策略。
4. 附帶搜索框形態
當然我們也可以在下拉列表當中結合搜索組件,幫用戶在下拉列表中完成搜索任務。這種設計策略就比較老派了,好處是平鋪直敘,壞處是沒有啥新意,不夠優雅。
5. 特別提醒
以上小編提到幾種下拉菜單的交互形態都建議用戶在完成單選任務的時候去使用,私以為下拉菜單對于完成多選任務并不友好。會讓用戶掉入「多選陷阱」(此概念引用于Hozin大佬,再次給出最高的敬意)當中,即通過下拉菜單完成多選任務后,用戶并不能直觀看到自己選擇了哪些選項。
如果一定要使用下拉菜單完成多選任務的話,那設計師必須要帶上一個已選搜集器,這樣用戶就可以在選擇同時知道自己已選了哪些。其實這種交互設計已經不是組件范疇了,而是一種解決多選任務的交互模式。所以說小編真的不太推薦用下拉列表去完成多選任務。
6. 打爆大廠的狗頭
又要了喜聞樂見打狗頭的時間,這里又不得不提到Antdesign里的組件例子。下圖中就是Antdesign試圖用下拉菜單去解決多選陷阱的問題。不得不說這里我們看到Antdesign努力的樣子。想嘗試把用戶的已選項在框體內作展示,但是難道框體高度隨著用戶選項增多而不停增高嗎?如果用戶選擇100個選項呢?OMG反正我覺得這只能算一個能用的設計,但是不是一個優雅的設計。
三、下拉菜單使用小竅門
1. 避免默認值
在使用下拉菜單時,設置默認值絕對是一個糟糕的設計策略。大量的經驗告訴我們如果有默認值,用戶基本上不會去仔細查看其他選項而是直接跳過,除非你真的確定有90%的用戶會選擇這個默認值!??!所以說使用“請選擇”比提供默認值好上千倍。
2. 注意滾動問題
這里要特別支持關于下拉列表當中的滾動問題,如果鼠標光標位于下拉菜單之外,用戶很可能會向下滾動頁面而不是向下滾動下拉菜單,從而不自覺的隱藏屏幕上下拉菜單。然而,在一些瀏覽器中,只要有焦點,下拉框實際上就會滾動,可能會給用戶留下錯誤的數據。
3. 注意數量
選擇菜單只有2個選項,使用下拉框就是個非常糟糕的策略,用戶必須單擊才能查看可用選項。
在這種情況下,應該使用單選按鈕。讓用戶將能夠立即掃視到有多少選項以及每個選項是什么,而無需單擊任何內容來顯示此信息。
4. 活用變體
受限于移動設備尺寸,造成其屏幕空間非常有限,這意味著用戶在滾動頁面時接受到的信息內容非常局限,那就需要設計師對組件的選擇與設計要求更高。同時某些框架提供對原生組件使用起來也不太得法,比如iOS9提供對原生控件,交互操作鏈路比較長,同時窗體高度占據了50%,手勢空間也受到不小的約束。所以針對不同數據類型我們可以用同構異型的組件去讓用戶完成任務。
5. Radio group
在“手把手帶你重新認識Radio Button”一文當中小編以及有詳細的解釋這里就不在進行贅述,這里提供文章鏈接手把手帶你重新認識Radio Button,不了解的朋友可以跳回去看一看哦
6. Steppers 步進器
當對一組有序數列進行選擇任務時,使用「Steppers 」也是不錯的選擇,可以用來增加或減少一定數量。對小步長的有序數列選擇任務比較有意義,可以與輸入框結合使用。同時需要注意的一般這種數據數量不建議超過5個。假如是100個數據的話肯定不能選擇steppers了不然用戶一定會抓狂的。
Sliders滑塊
同時在數據選擇任務領域當中,使用Sliders滑塊也是種不錯的選擇。
單個值情況:
多個值情況:
跟步進器結合使用
7. Switches 開關
開關比較簡單僅僅支持兩個簡單的,完全相反的選擇。值得注意開關只有「開」「關」兩種交互形態,不存在「不可用」狀態,開關不建議加文字說明,并且個人經驗告訴得出Switches開關在B/S結構的產品當中需要慎用。關于開關的問題有興趣的朋友可以私信我或者加我好友我們仔細探討下這個問題。
這里僅僅只是舉例說明了幾種比較常見代替下拉菜單完成用戶選擇任務的等效交互組件或者交互模式,實際工作中其他例子舉不勝舉,希望大家可以在工作中沉淀出好的方法。
四、文末小結
能用的設計與優雅的設計的主要區別是什么?優雅的設計應該為用戶完成每個目標任務時都提供最合適的輸入組件。同樣的目標任務在不同的場景下的組件設計肯定有所不同,有時候可能是下拉菜單,有時候可能是Radio group,有時可能是其他形式,此文小編希望給大家在工作中開拓出更多的設計思路。
作者:月亮與六便士(vx:Callen_0304);公眾號:月亮體驗設計坊
本文由 @月亮與六便士 原創發布于人人都是產品經理,未經作者許可,禁止轉載。
題圖來自Unsplash,基于CC0協議。
備選項過多的情況下,用哪種方式比較合適呢?
B/S結構為什么不建議用Switch開關呢?
下周發一篇哦
個人覺得下拉多選的選定項直接呈現在下拉容器中自動撐高還不錯,比呈現在下拉菜單的下方有優勢
估計是你確實沒見過撐高到10厘米長的下拉容器,哈哈哈哈
所以例子2-6,選項太多有什么更好的解決辦法嗎
利用收集器解決多選陷阱
個人覺得是否可以參考穿梭框的功能,將選中項從備選列表中提出來單獨展示(組件外收集器或組件內自動撐高都可以),那么總選項就是非此即彼,你多我少的關系。這樣,隨著選中項的增多,備選項就會減少,用戶做出選擇所用的時間也會越來越少。
表達的比較亂
謝謝提出寶貴意見??