編輯導語：在一個產品中，產品的交互設計是非常重要的，交互設計體驗的好壞直接影響到用户體驗；所以在開發設計一款產品時，對於一些選擇類的交互板塊，需要根據場景、需求等等方面進行考慮；本文作者分享了關於交互設計中選擇器的用法，我們一起來看一下。
本文梳理一些關於篩選控件選擇的解決思路，同時輔助三個實際案例幫助理解。
一、授人以魚不如授人以漁我一直認為做事不僅要有“術”，更要有“法”和“道”。
所以我每次分享的內容不僅僅有執行層的方法和工具，還有做事的底層邏輯和規則。只有掌握的方法才能舉一反三，因為不同事物之間的規則往往有其相似之處。
下面的文章我將從移動端的選擇器入手，分享一些解決問題的思路，具體會涉及到在遇到需要使用選擇器時如何判斷哪種方案更優以及遇到現實阻力時（開發時間不夠、研發水平有限等）如何做取捨，最後再結合三個實際案例做輔助理解。
先説明一下，下文的選擇器沒有包含非常基礎的選擇器，比如這種：
這樣的選擇器一般用於簡單的時間選擇，使用最廣泛也最基礎，對於這類選擇器的應用都比較熟悉，我就不做贅述了。
二、分析思路我們遇到需要使用篩選功能的地方，首先應該先思考，而不是即刻動手，磨刀不誤砍柴工，先思考再動手能有效避免後期返工。
那麼如何思考呢？
我建議從三個方面入手：用户場景、數據量、業務需求。
1. 用户場景使用用户故事模擬用户的使用過程，為什麼是模擬？因為有些時候我們無法就頁面的每個功能向用户求證，更多的時候我們會先做一定的用户調研，然後出一個demo後再做用户測試。
當我們模擬完成後就能對用户的心理有大概的瞭解，知道他每一步的想法和操作，這時我們再依靠這個用户心理模型去選擇選擇器組件。
那麼有人可能會説，靠自己想象的用户心理模型能符合真實的用户心理嗎？
我的答案是，不能百分百相等，但也是八九不離十的。
為什麼？
- 我們本身就是用户的一員，我們的心理一定程度能夠代表用户的心理。
- 需求之前有做過用户調研，瞭解過這個羣體，對他們的心理有一定共情。
- 我們初選選擇器後，可以做一個簡單的用户測試，比如找隔壁工位的大狗和二狗，讓他試試看覺得好不好用，一分鐘不到你就能得到反饋。
在上述三點理由的加持下，相信最後得到的結果絕不賴。
用户場景能幫助我們從用户的角度去思考交互，而另外兩個因素——數據量和業務需求，則能輔助我們確定最終的結果。
2. 數據量這裏説的數據量包含了篩選內容的多少和字段的長短。
數據量的多少很大程度上決定了我們對篩選器的選擇，如果數據量不大，就沒必要浪費資源開發一個複雜的篩選器。
而數據量大的時候，我們用小型篩選器來承載又會造成用户篩選困難體驗不好。
所以我們必須考慮數據量。
下面兩種篩選的數據量就大大不同：
不管我們選擇何種交互方式都不能業務需求相悖。
比如業務需要支持多選，而我們選擇了單選的篩選器，那麼首先這個篩選器就是錯誤的，不合格的。
所以我們選擇篩選器的時候必須把業務需求放在第一位，然後在業務需求的限制下進一步選擇。
業務需求決定層級：
思路説完了，下面開始案例解析，以下三個案例都是我在工作中遇到的情況，我會按照上面的思路來一步步解析如何思考，如何解決遇到的問題，最後為了幫助大家理解我會附上一個交互demo。
1. 案例一：日期選擇器案例介紹：這是一個動物園購票小程序“成都動物園官方購票”。
用户場景：用户購票過程選擇遊玩日期。
用户故事：
今天是星期四，小明打算這週六帶着外甥女去動物園玩，於是打開小程序，開始選擇日期。
小明遇到的問題：
問題一：這週六距離“今天”只有幾天，我想能夠快速選擇日期！
問題二：“昨天”肯定是無法購票的，我不小心誤點擊了“昨天”後提示我不可購票感覺很不爽！
問題三：我對日期的概念不強，週六不就是後天嗎，我想要更直觀的知道明後天的概念！
問題四：這周突然要加班，我改主意了，打算下週六再去，我想更直觀地看到週六日更方便的選擇日期！
看了小明的靈魂四問，有沒有一種被用户和客户支配的感覺2333…
回想一下當客户、老闆和用户對你進行如此這般靈魂拷問的時候，你如何應付？
當然是懟回去…啊呸，當然是遇山開山遇水搭橋，有條件要上，沒條件創建條件也要上！
咳咳，跑題了，繼續……
小明的問題我們瞭解了，那麼我們如何來解決他的問題？
不着急，咱們一個個拆解。
問題一：這週六距離“今天”只有幾天，我想能夠快速選擇日期！
解決方案：左右滑動選擇日期
左右滑動選擇日期：
問題二：“昨天”肯定是無法購票的，我不小心誤點擊了“昨天”後提示我不可購票感覺很不爽！
解決方案：不可遊玩的日期禁用，無法點擊
不可遊玩日期禁用：
問題三：我對日期的概念不強，週六不就是後天嗎，我想要更直觀的知道明後天的概念！
解決方案：最近的可遊玩日期增加“今/明/後天”標籤，同時給日期補充星期信息。
增加標籤和星期：
問題四：這周突然要加班，我改主意了，打算下週六再去，我想更直觀地看到週六日更方便的選擇日期！
解決方案：提供“更多”選項，點擊後彈出日曆彈窗可選擇更多日期
使用日曆彈窗承載更多日期：
看，這樣一步步分析是不是很簡單就出結果了。
這時候可能就會有人問了：“你這樣太麻煩啦！這樣子分析工作做不完的啦，加班餐吃定啦！”
我對此的回答是，表擔心，加班餐你吃不上（dog）。
為啥？因為上面幾個步驟雖然看上去繁瑣，但是鍛鍊的次數多了整個過程會非常快。
這個步驟是必不可少的，尤其對於新人來説，如果不逐步分析，只憑感覺來做的話，最後的結果可能是東西沒做好，自己又沒啥成長。
我這裏特別想分享一個觀念：
永遠帶着思考去做任何事情，隨時隨地鍛鍊自己的思考能力。
會做事的人很多，但是會思考的人卻很少。
都説透過現象看本質，但是想做到這點卻非常難，而能夠幫助我們儘可能靠近事件本質的方法就是思考，持續思考，別無其他，唯有思考可以幫助我們瞭解一件事情的本質。
就比如説案例一，雖説最後的結果看上去不就是一個小小的日期選擇器嗎？
絕不是，這個小小的日期選擇器是集結多方位思考的結果。
如果看的人不會思考，那麼你看到的就是一個平常的日期選擇器，但是如果你試着去思考它背後的邏輯，就會發現它的標籤、它的滑動交互、它的禁用都是有目的的，都是服務於用户和產品的。
下面輔助交互demo幫助理解它的交互方式。
交互demo：
案例介紹：這是一個工程管理APP，還沒完全上線，僅對其中一個級聯選擇器進行敍述，敏感信息遮擋住。
此處三級級聯選擇器的使用背景是——用户需要篩選安全隱患數據，而安全數據層級分為三級。
用户場景：
小剛是A工程負責人，進入頁面想查看相關安全數據，於是他開始篩選，數據層級一共有三級，需支持對每一個層級篩選。
遇到的問題：
問題一：選擇哪種篩選器？
數據層來看，隱患的數據量不小，至少幾十條，且字段字數存在十幾個字的情況。
業務層來看，隱患共有三級，需支持對每個層級都進行篩選。
從以上兩個點分析後，我選擇了上拉彈窗的篩選方式。
彈窗可以保留用户對任務的連續感，同時由於數據量不小，所以我決定提升彈窗佔屏比，讓用户能夠看到更多的內容；另外，業務層需要支持對每個層級進行篩選，那麼就需要在彈窗底部添加一個確定按鈕，讓用户能夠在選擇每個層級後都能進行篩選。
確定篩選彈窗：
問題二：字段長度太長如何處理？
不管是交互還是UI都需要考慮字段長度過長的時候如何處理。
這不僅僅是細心和專業的體現，更重要的作用是幫助前端處理邊界情況。
否則可能會出現兩種結果：
要麼前端同學反覆找你確認處理方式，要麼前端不作處理上線後出現顯示問題。
為了避免上述情況，我們一定要對邊界情況進行處理，後續我會總結一篇邊界處理的文章，這裏先説一下字段長度處理。
由於已有的數據數字長達十幾個字，所以我採取了逐級遞增的交互方式，這樣可以讓用户在單層看到更多的內容，當層級展示成三級後，文字就需要換行顯示。
文字溢出處理：
可以看到，文字溢出時我選擇的處理方式是顯示全部文字，同時輔助換行進行適配。
為什麼不做隱藏呢？難道不擔心文字太多屏幕顯示問題嗎？
問得好（戲精！），這裏我們又要引用上文提到的觀點“遇事切記先思考”，如果不考慮實際場景和業務我可能會選擇最多顯示一行或者兩行然後使用“…”顯示，這樣既可以保證界面美觀又可以完美適配。
但是我還是選擇了全部顯示，有兩個原因：
- 經過調研發現，這裏篩選的數據屬於工地隱患信息，對用户非常重要，他們需要看到全部的信息才能確定是否是他們想要的信息。
- 這種文字太多的情況不多，不會太影響頁面的查看。
綜上，根據用户需求和數據考慮，最終選擇了這樣的展示方式。
交互Demo：
問題三：研發時間不夠如何取捨？
作為打工人，我們都想把自己的工作做到盡善盡美，這不僅是對公司負責更是對自己負責，正因如此，我們也會希望研發能夠對我們的設計做到百分百還原。
但是…現實往往與理想相悖，很多時候我們不得不做許多妥協。
而這些骨感的現實問題都有哪些呢？
- 開發週期短，時間來不及導致不得不簡化
- 前端技術有限，導致無法實現
- 前端覺得麻煩，不想幹
- 交互設計太“高大上”，開發實現困難
針對第1點：開發週期短，時間來不及導致不得不簡化
這是較為普遍的情況，尤其是產品前期處於小步快跑快速迭代的情況下，很多時候都只做一個最簡單的MVP，後續再優化。
所以這個時候的妥協是值得且合理的，因為我們需要考慮性價比。
針對第2點：前端技術有限
這個問題不好解決，你不能否決對方的能力，你們是同事，是合作關係，你沒有這個權限，這時候我的建議是儘量輔助尋找解決方案。
有人可能會説，我又不懂技術呀，怎麼幫忙？
舉個例子，工作裏我也遇到過這樣的情況：
一個前端很難解決一個問題，我諮詢了其它幾位前端後都反饋説這個問題不難，而這位同事平時是一位積極主動的人。
所以我判定應該是技術能力不夠，所以我把向其它幾位研發諮詢的建議發給他，同時輔助尋找一些可用的插件，最後實現的效果雖然還是有些許差距，但是也算是大致符合我的預期。
針對第3點：前端覺得麻煩，不想幹
這又是個棘手的問題，尤其是我們身為設計人員不懂技術，很難判定對方是真的實現不了還是不想幹……
這個時候我的建議還是先諮詢其他前端同學，可以得到一個比較客觀的結論，然後結合這位前端平時的做事和為人來判斷，如果是技術問題，參考第2點。
如果是懶，他覺得麻煩，不想做。這個時候就需要好好見招拆招了。
再舉個例子（我腫麼老是遇到這種情況）：
這位前端是我們公司找的合作研發（相當於外包），需要他做一個banner的樣式，很普通r交互方式，但是對方以餓了麼控件庫沒有一模一樣的插件為由拒絕實現。
説真的，我當時很憤怒，因為他的做法實在不地道，我提前和他過了一遍交互方式，並且所有東西都是提前告知他，且他也沒意見的，等實現的時候他卻以他用的控件庫沒有一樣的插件為由拒絕。
這時候，我不懂技術，無法拿出論證説明這個交互很簡單，所以我當即諮詢了我們公司的兩位前端同學，都反饋説很簡單，兩小時左右搞定。
然後我又把我們公司前端幫忙找的幾個相似的插件一起發給他，結果…他説難改，還是拒絕。
是可忍孰不可忍…對於缺乏職業道德操守的人絕不能姑息！
這時候我已經無法推動了，只能向上求助（我之前的文章也説過，該求助就要求助，不要憋着）。
我把背景、該研發的回覆和我的處理方式整理好，最後附上我的想法後發給研發負責人（人是他找的），由他去交涉，最後解決了。
説句不好聽的，作為拿錢辦事的人，做事這麼囂張真的好嗎~不知道你們有沒有遇到過這樣的情況，我遇到的不少……
你得相信，這個世界總有人理直氣壯地把職業道德不當回事兒，這時候我們得理真的不能饒人！
針對第4點：交互設計太“高大上”，開發實現困難
説真的，這個問題我們得自我反思了，如果我們設計的交互方式市面少見而實現困難且收益低，那麼性價比就太低了，不值得。
成年人的世界沒有權衡，只有取捨。
那麼，如何避免自己設計出不常見的交互方式？
我的辦法是多看多用。
把市面知名的APP都下載下來研究，不僅要看，還要收集，截圖收集起來。
人的記憶力是有限的，必須收集起來分類好，方便隨時複習。
這裏分享一個素材收集和整理的好工具——eagle，是的，我又要分享工具了，我是個工具狂魔。eagle可以整理圖片，給圖片打標籤。
我的習慣是把每張圖片都打上交互標籤，當我想要用哪種交互方式的時候，可以隨時搜索參考。
圖片整理：
終於到了最後一個案例了，每個案例我想都講得儘量詳細，所以字數多了些~
先介紹下案例：
這是一個垂直領域的教育和招聘APP，我負責裏面的招聘版塊，下面的選擇器就圍繞着求職意向的選擇來説明。
用户場景：
小明是能源行業從業人士，最近打算換工作，下載了上述APP，進入求職版塊選擇求職意向，求職意向一共三級，僅支持末級篩選。
遇到的問題：
問題一：選擇哪種篩選器？
- 數據層：就目前的求職意向數據來看，求職意向每一級的數量大概在十幾二十個之間，就移動端來説不算少，而每個分類的數字長度大概在2到10個之間；
- 業務層：用户必須選擇到最後一級後才能進行精確篩選。
從以上兩點分析，以及對市面競品的調研，我決定使用新頁面來承載數據。
一來這種方式在招聘APP使用較多，用户上手快。
二來這種方式對數據的容納性很好，字段稍長一些也能較好的呈現。
確定篩選彈窗：
問題二：字段太長如何處理？
關於文字溢出處理的重要性我已經在案例二重點説過，這裏不做贅述，僅展示以下此次的篩選彈窗時如何處理的。
文字溢出處理：
為什麼一級文字太多隱藏而二級和三級卻顯示呢？
因為一級能夠顯示足夠的文字，而二級和三級的顯示寬度是有限的，為了用户識別信息，所以二級和三級需要全部顯示。
最後來個demo輔助理解。
demo：
以上，就是本次想要分享的內容。
今日經驗：永遠帶着思考去做任何事情。
本文由 @餿麪包 原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議