編輯導(dǎo)語：在一個(gè)產(chǎn)品中，產(chǎn)品的交互設(shè)計(jì)是非常重要的，交互設(shè)計(jì)體驗(yàn)的好壞直接影響到用戶體驗(yàn)；所以在開發(fā)設(shè)計(jì)一款產(chǎn)品時(shí)，對于一些選擇類的交互板塊，需要根據(jù)場景、需求等等方面進(jìn)行考慮；本文作者分享了關(guān)于交互設(shè)計(jì)中選擇器的用法，我們一起來看一下。

本文梳理一些關(guān)于篩選控件選擇的解決思路，同時(shí)輔助三個(gè)實(shí)際案例幫助理解。

一、授人以魚不如授人以漁

我一直認(rèn)為做事不僅要有“術(shù)”，更要有“法”和“道”。

所以我每次分享的內(nèi)容不僅僅有執(zhí)行層的方法和工具，還有做事的底層邏輯和規(guī)則。只有掌握的方法才能舉一反三，因?yàn)椴煌挛镏g的規(guī)則往往有其相似之處。

下面的文章我將從移動(dòng)端的選擇器入手，分享一些解決問題的思路，具體會(huì)涉及到在遇到需要使用選擇器時(shí)如何判斷哪種方案更優(yōu)以及遇到現(xiàn)實(shí)阻力時(shí)（開發(fā)時(shí)間不夠、研發(fā)水平有限等）如何做取舍，最后再結(jié)合三個(gè)實(shí)際案例做輔助理解。

先說明一下，下文的選擇器沒有包含非?；A(chǔ)的選擇器，比如這種：

這樣的選擇器一般用于簡單的時(shí)間選擇，使用最廣泛也最基礎(chǔ)，對于這類選擇器的應(yīng)用都比較熟悉，我就不做贅述了。

二、分析思路

我們遇到需要使用篩選功能的地方，首先應(yīng)該先思考，而不是即刻動(dòng)手，磨刀不誤砍柴工，先思考再動(dòng)手能有效避免后期返工。

那么如何思考呢？

我建議從三個(gè)方面入手：用戶場景、數(shù)據(jù)量、業(yè)務(wù)需求。

1. 用戶場景

使用用戶故事模擬用戶的使用過程，為什么是模擬？因?yàn)橛行r(shí)候我們無法就頁面的每個(gè)功能向用戶求證，更多的時(shí)候我們會(huì)先做一定的用戶調(diào)研，然后出一個(gè)demo后再做用戶測試。

當(dāng)我們模擬完成后就能對用戶的心理有大概的了解，知道他每一步的想法和操作，這時(shí)我們再依靠這個(gè)用戶心理模型去選擇選擇器組件。

那么有人可能會(huì)說，靠自己想象的用戶心理模型能符合真實(shí)的用戶心理嗎？

我的答案是，不能百分百相等，但也是八九不離十的。

為什么？

• 我們本身就是用戶的一員，我們的心理一定程度能夠代表用戶的心理。
• 需求之前有做過用戶調(diào)研，了解過這個(gè)群體，對他們的心理有一定共情。
• 我們初選選擇器后，可以做一個(gè)簡單的用戶測試，比如找隔壁工位的大狗和二狗，讓他試試看覺得好不好用，一分鐘不到你就能得到反饋。

在上述三點(diǎn)理由的加持下，相信最后得到的結(jié)果絕不賴。

用戶場景能幫助我們從用戶的角度去思考交互，而另外兩個(gè)因素——數(shù)據(jù)量和業(yè)務(wù)需求，則能輔助我們確定最終的結(jié)果。

2. 數(shù)據(jù)量

這里說的數(shù)據(jù)量包含了篩選內(nèi)容的多少和字段的長短。

數(shù)據(jù)量的多少很大程度上決定了我們對篩選器的選擇，如果數(shù)據(jù)量不大，就沒必要浪費(fèi)資源開發(fā)一個(gè)復(fù)雜的篩選器。

而數(shù)據(jù)量大的時(shí)候，我們用小型篩選器來承載又會(huì)造成用戶篩選困難體驗(yàn)不好。

所以我們必須考慮數(shù)據(jù)量。

下面兩種篩選的數(shù)據(jù)量就大大不同：

3. 業(yè)務(wù)需求

不管我們選擇何種交互方式都不能業(yè)務(wù)需求相悖。

比如業(yè)務(wù)需要支持多選，而我們選擇了單選的篩選器，那么首先這個(gè)篩選器就是錯(cuò)誤的，不合格的。

所以我們選擇篩選器的時(shí)候必須把業(yè)務(wù)需求放在第一位，然后在業(yè)務(wù)需求的限制下進(jìn)一步選擇。

業(yè)務(wù)需求決定層級：

三、案例

思路說完了，下面開始案例解析，以下三個(gè)案例都是我在工作中遇到的情況，我會(huì)按照上面的思路來一步步解析如何思考，如何解決遇到的問題，最后為了幫助大家理解我會(huì)附上一個(gè)交互demo。

1. 案例一：日期選擇器

案例介紹：這是一個(gè)動(dòng)物園購票小程序“成都動(dòng)物園官方購票”。

用戶場景：用戶購票過程選擇游玩日期。

用戶故事：

今天是星期四，小明打算這周六帶著外甥女去動(dòng)物園玩，于是打開小程序，開始選擇日期。

小明遇到的問題：

問題一：這周六距離“今天”只有幾天，我想能夠快速選擇日期！

問題二：“昨天”肯定是無法購票的，我不小心誤點(diǎn)擊了“昨天”后提示我不可購票感覺很不爽！

問題三：我對日期的概念不強(qiáng)，周六不就是后天嗎，我想要更直觀的知道明后天的概念！

問題四：這周突然要加班，我改主意了，打算下周六再去，我想更直觀地看到周六日更方便的選擇日期！

看了小明的靈魂四問，有沒有一種被用戶和客戶支配的感覺2333…

回想一下當(dāng)客戶、老板和用戶對你進(jìn)行如此這般靈魂拷問的時(shí)候，你如何應(yīng)付？

當(dāng)然是懟回去…啊呸，當(dāng)然是遇山開山遇水搭橋，有條件要上，沒條件創(chuàng)建條件也要上！

咳咳，跑題了，繼續(xù)……

小明的問題我們了解了，那么我們?nèi)绾蝸斫鉀Q他的問題？

不著急，咱們一個(gè)個(gè)拆解。

問題一：這周六距離“今天”只有幾天，我想能夠快速選擇日期！

解決方案：左右滑動(dòng)選擇日期

左右滑動(dòng)選擇日期：

問題二：“昨天”肯定是無法購票的，我不小心誤點(diǎn)擊了“昨天”后提示我不可購票感覺很不爽！

解決方案：不可游玩的日期禁用，無法點(diǎn)擊

不可游玩日期禁用：

問題三：我對日期的概念不強(qiáng)，周六不就是后天嗎，我想要更直觀的知道明后天的概念！

解決方案：最近的可游玩日期增加“今/明/后天”標(biāo)簽，同時(shí)給日期補(bǔ)充星期信息。

增加標(biāo)簽和星期：

問題四：這周突然要加班，我改主意了，打算下周六再去，我想更直觀地看到周六日更方便的選擇日期！

解決方案：提供“更多”選項(xiàng)，點(diǎn)擊后彈出日歷彈窗可選擇更多日期

使用日歷彈窗承載更多日期：

看，這樣一步步分析是不是很簡單就出結(jié)果了。

這時(shí)候可能就會(huì)有人問了：“你這樣太麻煩啦！這樣子分析工作做不完的啦，加班餐吃定啦！”

我對此的回答是，表擔(dān)心，加班餐你吃不上（dog）。

為啥？因?yàn)樯厦鎺讉€(gè)步驟雖然看上去繁瑣，但是鍛煉的次數(shù)多了整個(gè)過程會(huì)非常快。

這個(gè)步驟是必不可少的，尤其對于新人來說，如果不逐步分析，只憑感覺來做的話，最后的結(jié)果可能是東西沒做好，自己又沒啥成長。

我這里特別想分享一個(gè)觀念：

永遠(yuǎn)帶著思考去做任何事情，隨時(shí)隨地鍛煉自己的思考能力。

會(huì)做事的人很多，但是會(huì)思考的人卻很少。

都說透過現(xiàn)象看本質(zhì)，但是想做到這點(diǎn)卻非常難，而能夠幫助我們盡可能靠近事件本質(zhì)的方法就是思考，持續(xù)思考，別無其他，唯有思考可以幫助我們了解一件事情的本質(zhì)。

就比如說案例一，雖說最后的結(jié)果看上去不就是一個(gè)小小的日期選擇器嗎？

絕不是，這個(gè)小小的日期選擇器是集結(jié)多方位思考的結(jié)果。

如果看的人不會(huì)思考，那么你看到的就是一個(gè)平常的日期選擇器，但是如果你試著去思考它背后的邏輯，就會(huì)發(fā)現(xiàn)它的標(biāo)簽、它的滑動(dòng)交互、它的禁用都是有目的的，都是服務(wù)于用戶和產(chǎn)品的。

下面輔助交互demo幫助理解它的交互方式。

交互demo：

2. 案例二：三級級聯(lián)選擇器-多級可選

案例介紹：這是一個(gè)工程管理APP，還沒完全上線，僅對其中一個(gè)級聯(lián)選擇器進(jìn)行敘述，敏感信息遮擋住。

此處三級級聯(lián)選擇器的使用背景是——用戶需要篩選安全隱患數(shù)據(jù)，而安全數(shù)據(jù)層級分為三級。

用戶場景：

小剛是A工程負(fù)責(zé)人，進(jìn)入頁面想查看相關(guān)安全數(shù)據(jù)，于是他開始篩選，數(shù)據(jù)層級一共有三級，需支持對每一個(gè)層級篩選。

遇到的問題：

問題一：選擇哪種篩選器？

數(shù)據(jù)層來看，隱患的數(shù)據(jù)量不小，至少幾十條，且字段字?jǐn)?shù)存在十幾個(gè)字的情況。

業(yè)務(wù)層來看，隱患共有三級，需支持對每個(gè)層級都進(jìn)行篩選。

從以上兩個(gè)點(diǎn)分析后，我選擇了上拉彈窗的篩選方式。

彈窗可以保留用戶對任務(wù)的連續(xù)感，同時(shí)由于數(shù)據(jù)量不小，所以我決定提升彈窗占屏比，讓用戶能夠看到更多的內(nèi)容；另外，業(yè)務(wù)層需要支持對每個(gè)層級進(jìn)行篩選，那么就需要在彈窗底部添加一個(gè)確定按鈕，讓用戶能夠在選擇每個(gè)層級后都能進(jìn)行篩選。

確定篩選彈窗：

問題二：字段長度太長如何處理？

不管是交互還是UI都需要考慮字段長度過長的時(shí)候如何處理。

這不僅僅是細(xì)心和專業(yè)的體現(xiàn)，更重要的作用是幫助前端處理邊界情況。

否則可能會(huì)出現(xiàn)兩種結(jié)果：

要么前端同學(xué)反復(fù)找你確認(rèn)處理方式，要么前端不作處理上線后出現(xiàn)顯示問題。

為了避免上述情況，我們一定要對邊界情況進(jìn)行處理，后續(xù)我會(huì)總結(jié)一篇邊界處理的文章，這里先說一下字段長度處理。

由于已有的數(shù)據(jù)數(shù)字長達(dá)十幾個(gè)字，所以我采取了逐級遞增的交互方式，這樣可以讓用戶在單層看到更多的內(nèi)容，當(dāng)層級展示成三級后，文字就需要換行顯示。

文字溢出處理：

可以看到，文字溢出時(shí)我選擇的處理方式是顯示全部文字，同時(shí)輔助換行進(jìn)行適配。

為什么不做隱藏呢？難道不擔(dān)心文字太多屏幕顯示問題嗎？

問得好（戲精?。?，這里我們又要引用上文提到的觀點(diǎn)“遇事切記先思考”，如果不考慮實(shí)際場景和業(yè)務(wù)我可能會(huì)選擇最多顯示一行或者兩行然后使用“…”顯示，這樣既可以保證界面美觀又可以完美適配。

但是我還是選擇了全部顯示，有兩個(gè)原因：

• 經(jīng)過調(diào)研發(fā)現(xiàn)，這里篩選的數(shù)據(jù)屬于工地隱患信息，對用戶非常重要，他們需要看到全部的信息才能確定是否是他們想要的信息。
• 這種文字太多的情況不多，不會(huì)太影響頁面的查看。

綜上，根據(jù)用戶需求和數(shù)據(jù)考慮，最終選擇了這樣的展示方式。

交互Demo：

問題三：研發(fā)時(shí)間不夠如何取舍？

作為打工人，我們都想把自己的工作做到盡善盡美，這不僅是對公司負(fù)責(zé)更是對自己負(fù)責(zé)，正因如此，我們也會(huì)希望研發(fā)能夠?qū)ξ覀兊脑O(shè)計(jì)做到百分百還原。

但是…現(xiàn)實(shí)往往與理想相悖，很多時(shí)候我們不得不做許多妥協(xié)。

而這些骨感的現(xiàn)實(shí)問題都有哪些呢？

• 開發(fā)周期短，時(shí)間來不及導(dǎo)致不得不簡化
• 前端技術(shù)有限，導(dǎo)致無法實(shí)現(xiàn)
• 前端覺得麻煩，不想干
• 交互設(shè)計(jì)太“高大上”，開發(fā)實(shí)現(xiàn)困難

針對第1點(diǎn)：開發(fā)周期短，時(shí)間來不及導(dǎo)致不得不簡化

這是較為普遍的情況，尤其是產(chǎn)品前期處于小步快跑快速迭代的情況下，很多時(shí)候都只做一個(gè)最簡單的MVP，后續(xù)再優(yōu)化。

所以這個(gè)時(shí)候的妥協(xié)是值得且合理的，因?yàn)槲覀冃枰紤]性價(jià)比。

針對第2點(diǎn)：前端技術(shù)有限

這個(gè)問題不好解決，你不能否決對方的能力，你們是同事，是合作關(guān)系，你沒有這個(gè)權(quán)限，這時(shí)候我的建議是盡量輔助尋找解決方案。

有人可能會(huì)說，我又不懂技術(shù)呀，怎么幫忙？

舉個(gè)例子，工作里我也遇到過這樣的情況：

一個(gè)前端很難解決一個(gè)問題，我咨詢了其它幾位前端后都反饋說這個(gè)問題不難，而這位同事平時(shí)是一位積極主動(dòng)的人。

所以我判定應(yīng)該是技術(shù)能力不夠，所以我把向其它幾位研發(fā)咨詢的建議發(fā)給他，同時(shí)輔助尋找一些可用的插件，最后實(shí)現(xiàn)的效果雖然還是有些許差距，但是也算是大致符合我的預(yù)期。

針對第3點(diǎn)：前端覺得麻煩，不想干

這又是個(gè)棘手的問題，尤其是我們身為設(shè)計(jì)人員不懂技術(shù)，很難判定對方是真的實(shí)現(xiàn)不了還是不想干……

這個(gè)時(shí)候我的建議還是先咨詢其他前端同學(xué)，可以得到一個(gè)比較客觀的結(jié)論，然后結(jié)合這位前端平時(shí)的做事和為人來判斷，如果是技術(shù)問題，參考第2點(diǎn)。

如果是懶，他覺得麻煩，不想做。這個(gè)時(shí)候就需要好好見招拆招了。

再舉個(gè)例子（我腫么老是遇到這種情況）：

這位前端是我們公司找的合作研發(fā)（相當(dāng)于外包），需要他做一個(gè)banner的樣式，很普通r交互方式，但是對方以餓了么控件庫沒有一模一樣的插件為由拒絕實(shí)現(xiàn)。

說真的，我當(dāng)時(shí)很憤怒，因?yàn)樗淖龇▽?shí)在不地道，我提前和他過了一遍交互方式，并且所有東西都是提前告知他，且他也沒意見的，等實(shí)現(xiàn)的時(shí)候他卻以他用的控件庫沒有一樣的插件為由拒絕。

這時(shí)候，我不懂技術(shù)，無法拿出論證說明這個(gè)交互很簡單，所以我當(dāng)即咨詢了我們公司的兩位前端同學(xué)，都反饋說很簡單，兩小時(shí)左右搞定。

然后我又把我們公司前端幫忙找的幾個(gè)相似的插件一起發(fā)給他，結(jié)果…他說難改，還是拒絕。

是可忍孰不可忍…對于缺乏職業(yè)道德操守的人絕不能姑息！

這時(shí)候我已經(jīng)無法推動(dòng)了，只能向上求助（我之前的文章也說過，該求助就要求助，不要憋著）。

我把背景、該研發(fā)的回復(fù)和我的處理方式整理好，最后附上我的想法后發(fā)給研發(fā)負(fù)責(zé)人（人是他找的），由他去交涉，最后解決了。

說句不好聽的，作為拿錢辦事的人，做事這么囂張真的好嗎~不知道你們有沒有遇到過這樣的情況，我遇到的不少……

你得相信，這個(gè)世界總有人理直氣壯地把職業(yè)道德不當(dāng)回事兒，這時(shí)候我們得理真的不能饒人！

針對第4點(diǎn)：交互設(shè)計(jì)太“高大上”，開發(fā)實(shí)現(xiàn)困難

說真的，這個(gè)問題我們得自我反思了，如果我們設(shè)計(jì)的交互方式市面少見而實(shí)現(xiàn)困難且收益低，那么性價(jià)比就太低了，不值得。

成年人的世界沒有權(quán)衡，只有取舍。

那么，如何避免自己設(shè)計(jì)出不常見的交互方式？

我的辦法是多看多用。

把市面知名的APP都下載下來研究，不僅要看，還要收集，截圖收集起來。

人的記憶力是有限的，必須收集起來分類好，方便隨時(shí)復(fù)習(xí)。

這里分享一個(gè)素材收集和整理的好工具——eagle，是的，我又要分享工具了，我是個(gè)工具狂魔。eagle可以整理圖片，給圖片打標(biāo)簽。

我的習(xí)慣是把每張圖片都打上交互標(biāo)簽，當(dāng)我想要用哪種交互方式的時(shí)候，可以隨時(shí)搜索參考。

圖片整理：

3. 案例三：三級級聯(lián)選擇器-僅可選末級

終于到了最后一個(gè)案例了，每個(gè)案例我想都講得盡量詳細(xì)，所以字?jǐn)?shù)多了些~

先介紹下案例：

這是一個(gè)垂直領(lǐng)域的教育和招聘APP，我負(fù)責(zé)里面的招聘版塊，下面的選擇器就圍繞著求職意向的選擇來說明。

用戶場景：

小明是能源行業(yè)從業(yè)人士，最近打算換工作，下載了上述APP，進(jìn)入求職版塊選擇求職意向，求職意向一共三級，僅支持末級篩選。

遇到的問題：

問題一：選擇哪種篩選器？

• 數(shù)據(jù)層：就目前的求職意向數(shù)據(jù)來看，求職意向每一級的數(shù)量大概在十幾二十個(gè)之間，就移動(dòng)端來說不算少，而每個(gè)分類的數(shù)字長度大概在2到10個(gè)之間；
• 業(yè)務(wù)層：用戶必須選擇到最后一級后才能進(jìn)行精確篩選。

從以上兩點(diǎn)分析，以及對市面競品的調(diào)研，我決定使用新頁面來承載數(shù)據(jù)。

一來這種方式在招聘APP使用較多，用戶上手快。

二來這種方式對數(shù)據(jù)的容納性很好，字段稍長一些也能較好的呈現(xiàn)。

確定篩選彈窗：

問題二：字段太長如何處理？

關(guān)于文字溢出處理的重要性我已經(jīng)在案例二重點(diǎn)說過，這里不做贅述，僅展示以下此次的篩選彈窗時(shí)如何處理的。

文字溢出處理：

為什么一級文字太多隱藏而二級和三級卻顯示呢？

因?yàn)橐患壞軌蝻@示足夠的文字，而二級和三級的顯示寬度是有限的，為了用戶識別信息，所以二級和三級需要全部顯示。

最后來個(gè)demo輔助理解。

demo：

以上，就是本次想要分享的內(nèi)容。

今日經(jīng)驗(yàn)：永遠(yuǎn)帶著思考去做任何事情。

本文由 @餿面包 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議