No.003-移動端應用搜索模塊的設計分析
文中圖片較多，部分圖片包括內容較多，所以文中縮略圖可能看不清楚，請點擊放大圖片查看內容。
- 搜索簡介
搜索幾乎隨著互聯網一起發展起來的，算是用戶進入網路的門戶之一，Google和百度的成功已經證明瞭搜索的重要性。時至今日，用戶接觸到的網路信息都是海量的，因此在產品中添加搜索功能就成為必須，尤其在移動端產品中，由於手機屏幕尺寸的天然侷限性，搜索功能就更加更加顯得不可或缺。本文將從設計的角度來分析如何做好移動端的搜索功能。
2. 搜索流程分析
如果說搜索功能的外在形式是顏值，那麼搜索的邏輯結構則是骨架。不同搜索功能的外在形式可能表現的不一樣，但在邏輯上的「骨架」則基本上一致。從市面上的大多數應用來看，用戶搜索的主要操作流程大致可以歸納為：點擊搜索入口，進入搜索頁面，輸入關鍵字，展示搜索結果，如下簡圖所示
根據上述搜索流程可以將搜索模塊的架構簡化為如下圖所示：頁面中有搜索入口，點擊搜索入口進入單獨的搜索頁面，在搜索頁面的搜索框中輸入關鍵字，通過合適的方式觸發搜索並展示在搜索頁面展示搜索結果。
現在大部分應用都採用了這種設計，但也有部分應用的搜索模塊不是採用這種設計，而是直接在當前頁面中展示搜索框，並在其中輸入文字觸發搜索後進入結果頁面展示搜索結果，即省略了用戶進入搜索頁面的步驟，GooglePlay中的搜索功能就是採用這種設計。如下圖中所示，左圖為GooglePlay首頁的搜索框，右圖為直接在首頁的搜索框中輸入關鍵詞。
相比較而言，GooglePlay這種搜索設計，用戶的操作流程是少一步的，即直接在當前頁面搜索框中輸入，無需點擊進入搜索頁面再輸入，但缺點也很明顯，首先就是必須在頁面中提供可輸入的「搜索框」，這會導致產品架構佈局的侷限性，畢竟搜索框的尺寸在那裡，必須為它預留足夠的空間。一般而言，這種設計在PC端比較常見（PC端一般來說頁面空間足夠）。此外缺少了搜索頁面（未輸入關鍵字時），就只能單純的為用戶提供搜索了，就不能展示「推薦搜索」類似的引導提示信息了，而在大數據時代個性化推薦信息是比較重要的，而搜索頁面就算是一個很好好的信息載體，可以為產品提供更多的發揮空間。
另外有一點值得注意的是，現在移動端搜索模塊大多都是直接集成在在客戶端中，不會採用H5頁面，因此在點擊搜索入口進入搜索頁面以及從搜索頁面返回原頁面的「頁面間跳轉」都不會有體驗上的問題，但如果搜索模塊是基於H5的頁面，可能就不太適合採用這種「點擊跳轉到搜索頁面」設計方案，因為H5頁面的每一次的跳轉對用戶來說都是極為不友好，會讓用戶有明顯的「任務流程被中斷或卡頓」的感覺，因此如果是H5頁面或者網頁內做搜索設計時，採用GooglePlay搜索的這種方案可能更合適。
3. 搜索模塊架構概述
儘管常見的搜索操作流程基本一致，但不同的應用在具體的搜索架構設計上卻不盡相同，各有特點。最直接的原因就是在不同的應用中搜索的重要性是不同的。如果在產品定位中，搜索模塊足夠重要，那甚至可以將搜索模塊設計規劃到產品的一級結構中，如下圖所示
由於搜索模塊在架構上屬於一級結構，相當於應用的全局搜索功能，因此可以對全部的模塊1，2，3進行的搜索，即換一句話說，就是模塊1，2，3共同使用一個搜索模塊，用戶可以在任何模塊快速通過應用的導航結構進入搜索頁面。微博的搜索模塊就是屬於這種設計，即在「首頁」，「消息」，「發現」和「我」中都可以快速進入搜索頁面。微博將「搜索模塊」定位的如此之高，可能是因為微博本身的產品需要，在實際中並不是所有的應用都適合採用這種設計，畢竟大部分應用中搜索模塊算不上產品的主要結構模塊（儘管非常重要）。另外一種常見的設計方法是在用戶需要使用搜索功能時，在當前頁面中提供搜索入口，如下圖所示
這種結構是最常見的，好處在於其普適性和通用性，幾乎是適用於任何產品，而且搜索模塊的拓展性也比較好。在這種搜索結構中需要注意的是，搜索入口與搜索頁面的之間關聯性以及統一規範性，如果產品體系龐大，在不斷增加新的搜索入口過程中（比如不同時期不同團隊新增不同模塊的搜索入口），那麼可能就會導致搜索頁面的不可控制性，即應用中多個搜索頁面的結構和邏輯上不統一，會造成較壞的影響。因此最好在產品初期時就需要對搜索模塊架構做統一規範的處理，以保證產品搜索模塊的健壯性，統一規範性以及可拓展性。我建議將搜索模塊設計成獨立於產品主體功能結構（即一級結構）的獨立模塊或體系（賬號體系也可以這樣做），該模塊下是產品中所有與搜索相關的功能結構，主要邏輯結構是搜索入口和搜索頁面，如下圖所示。
這樣設計的好處是，即可以保證搜索模塊的功能性，又可以保證隨時根據需要調整搜索模塊與其他主體結構之間的關係，同時保證搜索功能模塊的統一規範性以及拓展性，比如說，可以將搜索模塊提升「地位」，變成微博的那種一級結構。如圖所示，當用戶在在應用中一級架構模塊1和模塊3需要使用搜索功能，那麼就可以直接在模塊1和 3中添加搜索入口，搜索入口關聯搜索頁面即可，就算模塊1中具體的搜索功能與模塊3中不一樣，也可以直接在搜索結構中設計具體的邏輯來處理，比如用戶使用搜索功能時，自動根據用戶的上下文環境來確定具體的搜索結構。這樣不僅可以保證產品架構上的簡潔以及搜索模塊的高度復用，降低維護開發成本，還可以保證產品的統一規範性，降低用戶的使用成本。
4. 搜索模塊架構具體分析
上文分析了常見的搜索模塊架構，即搜索入口和搜索頁面兩部分，接下來的就仔細的分析這個兩個部分的特徵。
（1）搜索入口形式
從上面的分析可知，搜索入口是幫助和引導用戶從產品頁面中進入搜索頁面，本身並沒有其它的主要功能，因此搜索入口從本質上來講就類似於一個「超鏈接」。在移動應用中，常見的搜索模塊的樣式可以歸納為以下下幾種形式：
- 搜索圖標形式
搜索圖標形式的搜索入口應該是移動應用中最常見的一種形式，常見的設計是將搜索入口放在APP Bar上（一般位於右上角），以單一的搜索圖標（多為放大鏡圖標）形式存在，如下左右圖所示為網易雲音樂的搜索入口示意圖，點擊頁面中右上角的搜索圖標，就可以進入搜索頁面（即右圖）。
這種搜索圖標形式設計的優點是其普適性，即無論何種產品都可以使用，用戶側也不會有任何使用上的問題；缺點也比較明顯，搜索圖標形式尺寸較小，很難獲得較多的用戶焦點，可能導致用戶的使用搜索模塊的頻率較低，即可能不會主動使用。此外也可以使用文字按鈕的形式代替圖標形式，即點擊「搜索」標籤的按鈕，進入搜索頁面，這種設計雖然與圖標入口類似，但文字的吸引力遠遠比不上圖標，會導致用戶的使用體驗較差，不建議使用。
- 頁面頂部搜索框形式
頁面頂部搜索框的搜搜形式，本質上可以算是獨立入口搜索形式的拓展，將一個獨立的圖標（文字）搜索入口拓展為一個搜索文本框的形式，常見的設計是搜索框與頁面等寬，用戶點擊搜索框在進入搜索頁面。常見的頁面頂部搜索框形式有2種，一是搜索框位於App Bar的區域內，一是位於App Bar 下方，即頁面內在。這兩種形式的搜索形式在功能本質上沒有區別，但是在搜索策略上的偏重點略有不同的，前者表示搜索功能的重要程度比後者更高，即更希望用戶去使用搜索功能。同時，前者既可以做為全局搜索（即針對整個產品）也可以做為局部搜索（某一模塊或頁面），而後者一般來說建議做為局部搜索。
如下圖所示為京東的搜索框，位於頁面頂部，而且是一種類似全局的搜索形式，搜索框在用戶瀏覽商品信息時會一直存在，有比較強烈的「提示作用」引導用戶去搜索商品。淘寶的搜索功能也採用了類似的設計，但是由於京東和淘寶在架構層級上有區別，因此搜索的細節形式還是有區別的。這種頁面頂部搜索框形式目前已成為最主流的設計形式，因為這種設計的綜合「性價比」是最高的，兼顧了用戶和產品兩方面的「需求」。
如下圖所示為QQ搜索入口以及搜索頁面示意，QQ的搜索功能是將搜索入口App Bar之下，功能實現沒有問題，但是由於App Bar 存在緣故，邏輯上總感覺搜索是針對App Bar下的當前功能模塊，即是局部搜索。值得注意的是，QQ的搜索的架構像上文所說的一樣，在不同模塊中點進去都是搜索頁面，但搜索模塊的整體框架是一致的，展示的細節內容是不同的，即相當於在QQ中維護以了獨立的搜索模塊，根據用戶所處的上下環境，進入搜索頁面後展示的內容細節不一樣。
小米MIUI9中的信息和聯繫的搜索功能也採用了類似的設計，如下圖所示，將搜索框入口置於App Bar之下。之所以將搜索入口放在AppBar下（頁面內），個人覺得可能是產品的其他功能架構設計影響了搜索功能的設計，如AppBar的標題，導航以及其他功能選項入口設計。
頁面頂部搜索框形式，由於其形式上與頁面等寬，所以與獨立圖標入口形式相比，能吸引更多用戶的注意力，而且可以在搜索框中自定義展現相關的提示引導的信息，引導用戶進行搜索或傳遞信息。騰訊視頻，愛奇藝，優酷等視頻應用的搜索功能也採用了類似的「變種」設計，如下圖所示，即縮短了搜索框的寬度，這種搜索的設計形式可以看做是置頂搜索框（App BAr內部）與獨立入口形式之間的一種折中形式，即可以達到引導用戶進行搜索和傳遞信息的目的，又不會過於突出搜素功能的產品定位而導致其他功能模塊被用戶忽視。
（2）搜索頁面分析
前面已經分析搜索模塊的第一部分，即搜索入口，相對搜索頁面來說，搜索入口在形式和邏輯結構上都比較簡單，而搜索頁面是搜索功能的主體，用戶使用搜索的絕大數流程都是在搜索頁面完成。可以說，搜索模塊成功與否都取決於搜索頁面，因此在實際中一定要做好搜索頁面的設計。接下來，結合用戶特徵、操作流程以及頁面結構元素等方面對搜索頁面進行深入分析。
- 用戶使用搜索功能的基本操作特徵
任何設計都是為了服務用戶，所以在分析搜索頁面的具體結構前，需要針對用戶在搜索頁面的操作行為進行分析（不同產品的用戶不同，那麼搜索需求也應該是不同的，因此這裡僅僅對用戶通用的搜索行為進行普遍性分析）。
首先用戶使用搜索功能的大致流程，可以簡單的歸納為3個大步驟：搜索前，搜索過程中，搜索後。搜索前指的是用戶在真正使用搜索功能（輸入關鍵詞）前的操作，例如在淘寶中就是用戶點擊搜索入口，進入搜索頁面輸入關鍵詞前的過程；搜索中即用戶搜索的過程中，指的是用戶是輸入關鍵詞到篩選到符合用戶預期信息的過程；搜索後指的是用戶對最終搜索結果操作的過程，其實到了這一步已經和搜索模塊關係不大了，更多的是與其他功能模塊的關聯。因此在用戶使用搜索的過程中，用戶的操作流程（搜索過程）以及主要路徑點（頁面或部件），大致可以歸納為如下圖所示，其中需要注意的是在用戶的搜索過程中有可能放棄搜索，放棄的原因可能有多種，比如搜索不到結果而放棄或不需要搜索就可以解決用戶的問題（突然想起來了答案）等。
根據上圖的用戶操作流程，可以將用戶的搜索過程的關鍵「動作」歸納為：輸入關鍵詞，搜索，查看搜索結果，完成搜索會到產品的原始頁面或者對搜索結果進行一定的操作。接下來部分針對這些關鍵「動作」進行一一分析。
輸入關鍵詞：
在搜索模塊中重要但又簡單的一個點是用戶如何搜索信息，即搜索方式，幾乎所有應用App中基本上都是通過關鍵詞來檢索（當然現在可以通過一些其他手段進行搜索比如拍照/圖片），即用戶通過關鍵詞的方式來搜索自己想要信息，所以搜索頁面中必須有一個能讓用戶輸入關鍵詞的搜索框，即文本框。
觸發搜索：
由於關鍵詞是用戶在搜索框中輸入的，而輸入是一個持續的過程狀態，理論上這個過程的時間長短是不可預測的，即無法判斷用戶會在什麼時候結果輸入，所以常見的設計是需要用戶在輸入完成時主動「確認完成」才進行搜索」，即需要用戶手動觸發搜索，然後產品會給用戶展示出最終的搜索結果。
篩選過濾搜索結果：
用戶的搜索的目的是為了尋找信息，用戶需要搜索什麼樣的信息在用戶搜索前對於產品而言是不確定的，因此用戶在應用中搜索的目的總體上可以劃分為兩種，一是用戶帶著明確的目的去搜索，即精準搜索，比如要買羅技G402滑鼠，那麼用戶在淘寶上就會直接輸入「羅技402」或「羅技滑鼠402」這些基本不會有模糊含義的關鍵字來搜索；二是用戶帶有不十分明確的目的去搜索，即模糊搜索，比如同用戶要買一個滑鼠，但對於品牌價格想這些因素並沒有十分確定的限制，那麼用戶可能就會先輸入「滑鼠」來看一些商品信息，再通過一系列的條件或因素來篩選，比如選擇商鋪信用高的或價格便宜的，再最終選擇一款滑鼠，因此最終會選擇雷蛇而不是羅技。從本質上講，用戶精準搜索關鍵詞就是將模糊搜索結果範圍進一步縮小至用戶的預期範圍內。同時在實際的搜索邏輯中，也基本很少出現關鍵詞與搜索結果是一對一的情況，基本都是多對一，也就是說用戶在使用搜索功能時，基本上會有對搜搜結果進行篩選過濾的操作，所以在搜素結果較多，為用戶提供一個過濾篩選信息的「模塊元素」貌似也是必須的。
重新搜索：
在用戶的操作路徑中還有一個點值得說一下的就是「重新搜索」。仔細分析可以得出，用戶的重新搜索應該可以歸類為兩種場景，第一種場景是用戶對第一次搜索的結果不滿意，用戶可能會換一個關鍵詞來搜索，在這個場景中，用戶需要刪除之前的關鍵詞，在輸入新的關鍵詞，現在大部分應用都會提供快速「清除」輸入字元的功能；第二種場景是用戶現搜索了一個關鍵詞，可能在之後的某個時機還需在針對同樣的關鍵詞進行搜索，比如多次搜索同樣的文章。因此大部分有此類需求的應用會記錄並在搜索結果頁面展示用戶的搜索歷史，以方便用戶快速重新搜索。
返回原頁面：
搜索模塊在邏輯結構上講是相對獨立的，但依然是應用整體結構的一部分，所以必須保證用戶可以在搜索模塊和其他功能模塊之間快速切換，即快速進入搜索模塊和退出搜索模塊。前賣弄已經分析過，用戶通過搜索入口進入搜索模塊進行搜索操作，當用戶已經完成搜索者，終止或放棄搜索時，就需要從搜索模塊「退出」，即為用戶提供「返回原頁面」的導航功能。
因此根據用戶的搜索流程，將用戶使用產品的搜索模塊的主流程路徑以及主要操作「動作」歸納為如下圖所示
- 搜索頁面架構元素根據上文的分析和總結以及對用戶的操作流程和重點操作動作，可以歸納出搜索頁面結構中的主要「元素」，如下圖所示，其中「返回原頁面」（即放棄搜索），是屬於產品的架構導航部分，幫助用戶在產品頁面和搜索模塊快速切換。
上圖所說的搜索頁面信架構元素是從用戶和產品兩個角度分析的，不同的應用不同的實際需求可能有差別，如在信息過濾和篩選在特定應用和條件下就不需要，可能有些應用不需要搜索歷史，所以在上圖中，我將這些「元素」定位於可選項，在實際中，可以根據產品來確定是否需要這些元素，但有一些元素是必須，即圖中必選項元素，比如說搜索框，展示的結果等。下面部分會針對這些架構元素結合常見應用的搜索模塊，詳細分析如何設計搜索頁面。
5. 搜索頁面具體架構分析
未完待續
下一篇文章中會分析剩下的部分，包括上面所說的頁面元素的設計形式以及如何規劃設計應用的搜索模塊。
最近工作上比較忙，但又不想隨便水一篇，盡量寫的有理有據，所以花的時間比較長。
作者現在是一名交互設計師，寫的不好不正確的請見諒。記錄，僅以此自勉。
歡迎關注我的公眾號notestudy，會定期寫一些與設計相關的短文，謝謝支持。
推薦閱讀：
