2023年APP設計模式之-搜索功能

APP設計模式之——搜索功能可能在許多人看來，搜尋是個不起眼的小功能，無需花太多時間贅述。但作為PM/UI/UX，我們沒有理由輕視任何涉及用戶體驗的產(chǎn)品設計，個人來講，是不怕用戶批判和吐槽的，我最怕的是眼界狹隘，思路不開闊，由于這打算了我的成長空間和速度。

所以在這篇文章中，我盡可能地把自己遇到/思索到的，涉及搜尋功能的設計模式，圍圍著搜尋流程，都一一列舉出來，也盼望大家在看到新奇的APP搜尋模式時，貢獻一下案例。

應第一篇專欄評論區(qū)@大大頭披風伴侶的建議，后面全部文章插圖，我都會進行標注。

另外特別感謝大家的關注與欣賞，你們的認可是我更新的最大動力。

言歸正傳，先放一張搜尋流程圖：

湖藍色邊框是最簡潔/必要的搜尋流程節(jié)點，考慮到各種各樣的場景，整個搜尋流程就變得“冗長”了，但是用戶體驗卻上去了。下面我們就逐一介紹搜尋流程中的各個動作和關鍵節(jié)點，以及典型實例。

一、輸入搜尋內容

1.功能入口

搜尋功能入口即用戶進入搜尋流程的起點，這個起點通常都以靜態(tài)形式呈現(xiàn)在頁面上，比如頁面左上角或右上角的搜尋圖標，或頁面上的搜尋文本框（以圓角矩形為主）。如格志和Reddit：

用戶點擊這個圖標或者文本框后，才算觸發(fā)了搜尋流程的第一步：內容錄入。

相對來說，搜尋圖標適合低頻搜尋應用，而搜尋文本欄更適合高頻搜尋應用。查詢類應用/場景明顯特別適合搜尋文本框，而且用戶使用頻度越高，搜尋文本框自身面積就越大，所占頁面位置也更加明顯，比如網(wǎng)易云音樂和金山詞霸：

個人來講，不知為何，當我看到搜尋文本框的時候，就有一種立刻就要看到期盼的內容的感覺，而單純的搜尋圖標是沒方法給這種感覺的。究竟搜尋圖標和搜尋結果中間，總會隔著一個搜尋文本框。

2.條件輸入

可能有人會說了，輸入搜尋條件還有什么好說的？直接敲鍵盤不就完事兒了嗎？

對于絕大部分用戶來說，這的確沒有問題，但是……俗話說得好，魔鬼都在細節(jié)里。越是這種不起眼的地方，我們越能做出一些能讓小眾用戶覺得很好用/好玩的設計，在體現(xiàn)APP自身特色的同時，還能幫應用留住那些“長尾用戶”。

條件輸入環(huán)節(jié)，我們應當關注的設計要素：退出搜尋頁面、一鍵刪除已輸入內容、觸發(fā)搜尋動作執(zhí)行的按鈕、小鍵盤、小鍵盤增加設計。

退出搜尋界面：通常是“取消”二字，水平置于文本框右側，也有些應用實行“＜”按鈕設計，水平置于文本框左側，比如微信閱讀和Quora：

一鍵刪除已輸入內容：通常是在搜尋框右側放置灰底白色“×”圖標，也有些應用出于用戶輸入出錯率高的狀況，將這個元素放置到用戶更簡單“夠得到”的位置，這個設計在大屏手機時代還是特別有必要的。

下面的良倉和金山詞霸分別代表了這兩種類型，且后者采納了“清空”文字’代替“×”圖標，居于屏幕中央略靠下的位置，可以說特別醒目了：

觸發(fā)搜尋動作執(zhí)行的按鈕：PC端產(chǎn)品許多還保留著有實際作用的“搜尋”按鈕，如百度首頁的“百度一下”按鈕：

谷歌的“Google搜尋”：

以及相當多應用的搜尋框內置的或者右側的搜尋圖標，PC端的“搜尋”觸發(fā)是通過“Enter”回車鍵或鼠標單擊完成，同理APP上的搜尋觸發(fā)，要么是通過點擊頁面上的“搜尋”圖標，要么是通過小鍵盤上的確認鍵來完成，而小鍵盤確認鍵往往有多種表現(xiàn)形式，如“搜尋”、“確定”、“換行”等。

小鍵盤：小鍵盤需要留意的就是依據(jù)輸入框和表單的內容，來設置默認的小鍵盤樣式，比如中文鍵盤、英文鍵盤、數(shù)字鍵盤等，為用戶帶來更順暢的操作體驗。

小鍵盤增加設計：增加設計指的是在小鍵盤上方，再增加一行命令項，在視覺設計上表現(xiàn)為做到和小鍵盤融為一體，在功能上表現(xiàn)為依據(jù)用戶使用場景，尤其是高頻操作，來設計對應的功能。

比如UC掃瞄器的小鍵盤增加設計，除了給出常見的網(wǎng)址前綴后綴，還在中間放置了一個光標精準定位滾軸，極具匠心：

還有一些帶有應用自身特色的小鍵盤增加設計，如金山詞霸和Quora。

詞霸有三個按鈕：“返回”（退出搜尋界面）、“清空”（一鍵清除已輸入內容）、“翻譯”（觸發(fā)搜尋動作），我信任只要用戶幾次詞霸，便會對這個界面欣賞有加，高頻操作按鈕居中布局，特別便利用戶單手操作，且搜尋框顯得特別簡潔美觀：

而Quora的增加設計更是獨具匠心，將問答社區(qū)高頻操作“搜尋-提問-閱讀-回答-”中的提問入口直接放到了小鍵盤上方，當用戶在動態(tài)搜尋結果中找不到自己想要的內容后，可以直接將想找的回答變?yōu)閱栴}，驚不驚喜？意不意外？

而中國版Quora，即知乎，并沒有建立起“搜尋-提問”的關聯(lián)，提問入口仍舊是孤立的（文章發(fā)布后經(jīng)@TonyLiao和@大大頭披風的提示，發(fā)覺最新版知乎已經(jīng)可以在搜尋結果頁的上劃刷新的第四屏看到“沒找到想要的內容？——去提問”的懸浮提示設計）：

思索時間：右側輸入框的設計有何優(yōu)缺點？如何進行優(yōu)化？

再放兩個特別增加設計，Termius（移動端主機管理工具）和Navicat（移動端數(shù)據(jù)庫管理工具）。

前者整合了許多實體鍵盤按鍵，而后者為了不影響表結構的顯示效果，干脆在增加設計行中做了個搜尋框，所以沒有一成不變的設計，還是要詳細問題詳細場景詳細分析。當然這種產(chǎn)品的PM基本就必需要懂相關技術和操作了：

3.幫助輸入

幫助輸入，指的是在用戶輸入前，APP供應給用戶一些內容或者選項，以便用戶更快更省力地輸入搜尋條件。如UC掃瞄器和知乎就供應了歷史搜尋記錄，來幫助：

UC是給出了歷史搜尋記錄，而知乎則更進一步，對歷史搜尋記錄進行了分類，使用“內容”和“用戶”兩個標簽讓用戶進行切換，而且還增加了“最近掃瞄”入口，便利用戶回溯自己近期的掃瞄列表，更勝一籌。

“敬重用戶的勞動”是勝利手機界面設計的最基本原則?！氨４娴乃褜ぁ焙汀白罱褜ぁ笔沟盟褜l件簡單從以前的搜尋歷史中選擇，而不用再次輸入相同的關鍵詞。

選項幫助輸入，是指在用戶輸入搜尋條件之前，供應一些基本的搜尋范圍（如內容分類等），讓用戶更快地獲得期望的結果。參見全民K歌和Pinterest：

這種搜尋方式也可以稱為“前置搜尋類別”。這種搜尋方式適用于分類較簡潔的內容，便于精確地定位搜尋內容。

與“前置搜尋類別”相對應的，是“后置搜尋類別”，我們放到后面去講。

此外還有包括基于地理位置搜尋的幫助輸入方式，這在基于LBS的APP中特別常見，如貓眼電影和高德地圖：

最佳實踐：保存搜尋需要額外的步驟去命名搜尋參考值，敬重用戶的勞動成果，讓用戶削減操作。

二、執(zhí)行搜尋命令

在移動端，最廣泛的搜尋模式是：用戶輸入搜尋內容后，APP自動執(zhí)行搜尋動作，同時將搜尋結果以列表的形式展現(xiàn)在搜尋文本框下方，用戶連續(xù)輸入搜尋內容，搜尋結果也會相應自動變化，當全部條件輸入完畢時，點擊搜尋按鈕，顯示最終結果。

這種搜尋模式，我稱之為動態(tài)搜尋，這也是目前最符合“懶設計”理念的搜尋方式。同時，還有一種較為“古老”的搜尋模式，即靜態(tài)搜尋，即用戶輸入完全部的搜尋條件，再一鍵執(zhí)行搜尋命令。

動態(tài)搜尋

動態(tài)搜尋，指輸入搜尋條件時的實時搜尋+實時展現(xiàn)。這種設計也被稱為動態(tài)過濾，即輸入文本數(shù)據(jù)，對應搜尋結果將會動態(tài)過濾顯示在屏幕上。同時，這也是一種特別形式的幫助輸入（見4.1.3）。我們以豆瓣為例：

在輸入“夢”和“夢的”兩個搜尋條件時，結果呈現(xiàn)的完全不一樣，這是由于動態(tài)搜尋時，是依據(jù)已輸入內容的詞頻熱度進行搜尋和排序的。這又涉及到搜尋算法，對于這部分內容，我們放到后面去具體介紹。

目前使用靜態(tài)搜尋設計的APP已經(jīng)越來越少，因此不做贅述。

三、搜尋等待

通常狀況下，無論是動態(tài)搜尋還是靜態(tài)搜尋，在搜尋結果呈現(xiàn)之前，都會有進度條或者加載交互動作的指示器，用以告知用戶：“正在搜尋中，請急躁等待”。當搜尋動作執(zhí)行完畢后，再展現(xiàn)最終的搜尋結果：

在2G（其次代移動通信技術）時代，下載速度在幾KB/S到10幾KB/S之間，從錄入搜尋條件到顯示搜尋結果，通常需要1秒以上的響應時間，這時的系統(tǒng)反饋就特別必要，進度條或者加載動作能給用戶以提示，表示正在搜尋中。

到了3G/4G，甚至將來幾年就能夠在國內應用的5G時代，搜尋結果幾乎瞬時呈現(xiàn)，這時系統(tǒng)反饋動作是否必要呢？答案是確定的，由于哪怕是在一線城市市中心，也會存在網(wǎng)絡環(huán)境差的場景，應用仍需要給用戶供應等待提示。

四、展現(xiàn)搜尋結果

1.

展現(xiàn)方式

搜尋結果的展現(xiàn)，涉及到展現(xiàn)方式、展現(xiàn)層級等。

搜尋完畢，結果會顯示在原有頁面下方，或在新頁面中顯示（相對較少）。展現(xiàn)方式也紛繁多樣。比如最簡潔的文字列表視圖（墨墨單詞和TripAdvisor）：

圖文并茂式列表視圖（網(wǎng)易云課堂和在行）：

還有一些簡約化，內容設計感極強的列表（Kickstarter和Town）：

Kickstarter是橫向左右滑動卡片式列表，每個卡片代表一個眾籌項目；Town是縱向滑動大圖列表，每個條目代表一處人文景觀。

增加列表視圖（豆瓣和攜程）：

增加列表視圖，是一般列表視圖的變體，指在列表視圖的基礎上，糅合其他設計要素，而呈現(xiàn)出更加多樣的視圖方式。

比如豆瓣的多重列表視圖就是增加列表視圖的一種，它采納了基于搜尋結果類別進行分列表展現(xiàn)的視圖方式。簡潔來講就是展現(xiàn)頁面有多個列表，如“圖書”列表、“電影/電視”列表等。

攜程搜尋展現(xiàn)頁面是增加型列表視圖的典型，在整體是列表視圖的整體視覺效果上，有的列表項本身就是一項內容集合，如“張家界的旅游度假”；有的列表項本身是一個詳細條目（張家界碧桂園鳳凰酒店）；有的列表項增加了內容詳情介紹（旅游產(chǎn)品介紹），不同列表項代表不同類別（飛機、酒店、旅游產(chǎn)品等），這種視圖方式適合搜尋結果門類及其簡單，不同結果展現(xiàn)權重不同的應用。

表格視圖（小紅書和ASOS）：

當搜尋結果需要圖文并茂地進行展現(xiàn)，且需要支持用戶快速掃瞄較多條目的時候，表格視圖再適合不過了，而上述兩個前提，缺了任何一個，都會影響用戶體驗。這種視圖方式常常應用在購物類的應用中，且最多兩列排列，再多的話，信息就太過密集。

假如需要圖文顯示，且用戶掃瞄速度更快，條目更多的時候，就由表格視圖變?yōu)榱藞D文并茂的列表視圖，如淘寶和美團，只保留一列內容，是為了不打斷用戶的視覺流。設想一下從上到下，和從左到右+從上到下，哪種方案更好？

縮略圖（Eventbrite）：

縮略圖視圖模式，指的是搜尋結果的內容條目，是將詳情頁的圖文內容進行選取、縮小或模糊處理后，以N個縮略圖的方式，展現(xiàn)在搜尋結果展現(xiàn)頁，因此該模式通常和其他模式混合使用。

甚至地圖衛(wèi)星圖（摩拜和ofo）：

地圖/衛(wèi)星圖的視圖方式，適合于供應基于LBS（基于地理位置信息服務）的應用，可以為用戶供應空間和位置的宏觀視角。當然，還有個默認前提就是：搜尋結果信息類別單一，比如摩拜和ofo搜尋結果都是標準化、同質化的單車，用戶不需要關懷這輛車有什么特質，只需要關懷能不能用即可。

有時依據(jù)搜尋結果的簡單程度和用戶使用首選項的不同，也會使用多種視圖顯示，如高德地圖和Eventbrite，就結合了地圖和列表兩種視圖方式：

高德地圖搜尋楊家火鍋，火鍋這種餐飲行業(yè)，即便同一品牌，不同門店供應的服務也可能相差極大，比如店鋪環(huán)境、人氣、價格（不同商圈價格會略有變化，會有一個價格系數(shù)）、經(jīng)營狀態(tài)、營業(yè)時間、評價等，所以除了位置信息，還需要把其他關鍵信息以列表形式呈現(xiàn)給用戶。

而Eventbrite特征更加明顯，我輸入的搜尋條件“基于紐約及周邊地圖的藝術類活動”明顯囊括的內容更加紛繁多樣，所以在展現(xiàn)結果時，除了使用地理位置視圖，還將活動用列表的形式呈現(xiàn)出來，配以主題、時間、地點和價格介紹等。

2.內容加載

在搜尋時，通常使用延遲加載技術，使部分結果可以被優(yōu)先、快速地展現(xiàn)出來，而更多數(shù)據(jù)則會被延遲加載，這種設計有助于提高用戶體驗，如Foursquare：

很多應用通過““查看更多”按鈕，或拖動屏幕（上拉刷新）時自動加載更多結果。如LOFTER和ABCNews：

也有應用把延遲加載做得更平滑，拖動屏幕（上拉刷新）時自動完成更新，如開眼，只有在關閉網(wǎng)絡的狀況下，我們才能看出它的加載交互，是由logo動效完成的。

五、結果篩選

結果篩選，指在搜尋結果的基礎上，通過篩選條件，對內容進行過濾，得到更加精確的搜尋結果。通常分為前置篩選、后置篩選和全局篩選。

1.前置篩選

前置篩選是在用戶觸發(fā)搜尋動作之前進行的篩選，如豆瓣：

在動態(tài)搜尋執(zhí)行完，點擊“全部”菜單，在下拉列表中選擇“圖書”，得到篩選后的結果，再次點擊“搜尋”按鈕，進入展現(xiàn)搜尋結果的全屏頁：

2.后置篩選

后置篩選，也稱結果篩選。指的是當搜尋動作執(zhí)行完畢后，基于搜尋結果，所進行的二次篩選，通常是以“搜尋表單”的方式呈現(xiàn)，特點是一個單獨的表單輸入多個條件和一個明顯的搜尋