編輯導語：搜索功能是用戶常使用功能之一，其中又包括條件輸入、內容判定、搜索觸發、結果展示等模塊。那么，具體到各個模塊，設計師又應當從哪些細節入手來提升用戶的使用體驗？本篇文章里，作者就搜索功能設計做了思考和總結，一起來看一下。

可能在很多人看來，搜索是個不起眼的小功能，無需花太多時間贅述。但作為PM/UI/UX，我們沒有理由輕視任何涉及用戶體驗的產品設計，個人來講，是不怕用戶批評和吐槽的，我最怕的是眼界狹隘，思路不開闊，因為這決定了我的成長空間和速度。

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

應第一篇專欄評論區@大大頭披風朋友的建議，后面所有文章插圖，我都會進行標注。

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

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

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

一、輸入搜索內容

1. 功能入口

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

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

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

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

2. 條件輸入

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

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

條件輸入環節，我們應該關注的設計要素：退出搜索頁面、一鍵刪除已輸入內容、觸發搜索動作執行的按鈕、小鍵盤、小鍵盤增強設計。

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

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

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

觸發搜索動作執行的按鈕：PC端產品很多還保留著有實際作用的“搜索”按鈕，如百度首頁的“百度一下”按鈕：

谷歌的“Google搜索”：

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

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

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

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

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

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

而Quora的增強設計更是獨具匠心，將問答社區高頻操作“搜索-提問-閱讀-回答-”中的提問入口直接放到了小鍵盤上方，當用戶在動態搜索結果中找不到自己想要的內容后，可以直接將想找的回答變為問題，驚不驚喜？意不意外？

而中國版Quora，即知乎，并沒有建立起“搜索-提問”的關聯，提問入口仍然是孤立的（文章發布后經@Tony Liao 和@大大頭披風 的提醒，發現最新版知乎已經可以在搜索結果頁的上劃刷新的第四屏看到“沒找到想要的內容？——去提問”的懸浮提示設計）：

思考時間：右側輸入框的設計有何優缺點？如何進行優化？

再放兩個特殊增強設計，Termius（移動端主機管理工具）和Navicat（移動端數據庫管理工具）。

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

3. 輔助輸入

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

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

“尊重用戶的勞動”是成功手機界面設計的最基本原則?！氨４娴乃阉鳌焙汀白罱阉鳌笔沟盟阉鳁l件容易從以前的搜索歷史中選擇，而不用再次輸入相同的關鍵詞。

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

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

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

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

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

二、執行搜索命令

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

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

動態搜索

動態搜索，指輸入搜索條件時的實時搜索+實時展示。這種設計也被稱為動態過濾，即輸入文本數據，對應搜索結果將會動態過濾顯示在屏幕上。同時，這也是一種特殊形式的輔助輸入（見4.1.3）。我們以豆瓣為例：

在輸入“夢”和“夢的”兩個搜索條件時，結果展現的完全不一樣，這是因為動態搜索時，是根據已輸入內容的詞頻熱度進行搜索和排序的。這又涉及到搜索算法，對于這部分內容，我們放到后面去詳細介紹。

目前使用靜態搜索設計的APP已經越來越少，因此不做贅述。

三、搜索等待

通常情況下，無論是動態搜索還是靜態搜索，在搜索結果呈現之前，都會有進度條或者加載交互動作的指示器，用以告知用戶：“正在搜索中，請耐心等待”。當搜索動作執行完畢后，再展示最終的搜索結果：

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

到了3G/4G，甚至未來幾年就能夠在國內應用的5G時代，搜索結果幾乎瞬時呈現，這時系統反饋動作是否必要呢？答案是肯定的，因為哪怕是在一線城市市中心，也會存在網絡環境差的場景，應用仍需要給用戶提供等待提示。

四、展示搜索結果

1.?展示方式

搜索結果的展示，涉及到展示方式、展示層級等。

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

圖文并茂式列表視圖（網易云課堂和在行）：

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

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

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

增強列表視圖，是普通列表視圖的變體，指在列表視圖的基礎上，糅合其他設計要素，而呈現出更加多樣的視圖方式。

比如豆瓣的多重列表視圖就是增強列表視圖的一種，它采用了基于搜索結果類別進行分列表展示的視圖方式。簡單來講就是展示頁面有多個列表，如“圖書”列表、“電影/電視”列表等。

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

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

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

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

縮略圖（Eventbrite）：

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

甚至地圖衛星圖（摩拜和ofo）：

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

有時根據搜索結果的復雜程度和用戶使用首選項的不同，也會使用多種視圖顯示，如高德地圖和Eventbrite，就結合了地圖和列表兩種視圖方式：

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

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

2. 內容加載

在搜索時，通常使用延遲加載技術，使部分結果可以被優先、快速地展示出來，而更多數據則會被延遲加載，這種設計有助于提高用戶體驗，如Foursquare：

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

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

五、結果篩選

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

1. 前置篩選

前置篩選是在用戶觸發搜索動作之前進行的篩選，如豆瓣：

在動態搜索執行完，點擊“全部”菜單，在下拉列表中選擇“圖書”，得到篩選后的結果，再次點擊“搜索”按鈕，進入展示搜索結果的全屏頁：

2. 后置篩選

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

這種搜索模式常用于內容分類較復雜的應用中，如美團和淘寶使用搜索表單來搜索服務和商品：

全部表單展開后，是這個樣子的：

最佳實踐：

1. 用最少的內容輸入，實現精準搜索。
2. 遵循表單設計原則（對齊、標簽、大?。?。

3. 全局篩選

有些應用的篩選邏輯只有一層，所有內容都在至少一個分類目錄下被收錄，各分類目錄之間互斥，這樣可以保證無論是在搜索動作執行的前面還是后面，都可以設定篩選條件，既可以前置，又可以后置。比如知乎：

用戶既可以在輸入搜索條件前在“內容”和“用戶”兩個標簽之間切換，也可以在得到搜索結果后再進行標簽切換。

作者：銀發的芝加哥

原文鏈接：https://zhuanlan.zhihu.com/p/27476719

本文由@銀發的芝加哥 授權發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議