編輯導語：在很多產品中，搜索都是其中比較基礎且很重要的一個功能，在很多時候我們都需要進行搜索找到需要的東西，搜索的設計、邏輯、交互等問題也是需要特別注意的；本文作者分享了關于搜索功能的設計理解，我們一起來了解一下。

搜索功能是許多產品的核心，例如電商搜索、內容搜索等等；面對如何進行搜索功能設計，確實是個看似簡單實則深奧的問題。

不管不顧，隨后畫一個條形框、正方體，他們就是搜索框和搜索圖標就能代表一個搜索模塊；若要仔細研磨，各種用戶交互問題，各類邏輯，那他們也是一個搜索系統；這一切都取決于你，產品設計師如何設計。

設計一個搜索功能我們需要從用戶體驗和功能實現兩方面出發：

• 用戶體驗包含了樣式UI設計、交互設計；囊括起來說就是用戶搜索前、搜索中以及搜索后用戶對我們的功能的感知；
• 而功能實現則是聚焦用戶對問題的輸入，和我們結果的輸出（結果匹配度）。

由此我將分成搜索的設計和搜索的邏輯兩部分進行說明。

一、搜索的設計

先從可感知的樣式來說。我們按照用戶路徑地圖來理解用戶使用功能時的具體步驟：

用戶使用產品 – 有疑問需要搜索解決 – 看見搜索功能 – 點擊搜索功能（展開輸入框） – 輸入問題 – 點擊確認等到結果反饋 – 翻閱搜索結果 – 選擇結果進行查閱。

按照上述路徑，我們可以將用戶使用搜索功能的場景分為三部分：搜索前、搜索中、搜素后。同時根據應用場景的不同，還需區分移動端和PC端。

1. 搜索前

首先，我需要申明我對于搜索核心的定義，那就是搜索功能核心在于解決用戶的疑問，給予用戶滿意的答案；因此我們在設計的時候，需要帶入場景假想我們就是用戶，我們在迫切需要解決問題的時候，我們會是什么樣的心里活，煩躁？渴望？又或是興奮？建立了同理心后才是功能的設計。

所以在搜索功能設計的時候，對面用戶迫切的心情，我們合理設計搜索功能。在用戶使用產品產生疑問的時候，我們要根據當前場景進行選擇放大、縮小搜索對于用戶的感官；在越容易產生疑問的地方選擇使用輸入框搜索作為設計方案，而在不容產生問題的地方還是可以選擇搜索圖標作為解決方案。

這兩個解決方案是十分常見的，但我們需要注意，除開樣式的差異在選擇使用輸入框作為搜索樣式的時候，大多人都偏愛在輸入框上做文字引導，這種文字引導有引導使用文案和推薦搜素文案兩種。

這樣做不是一定需要的，因為我確實沒準確的數據告訴你，做了和沒做在數據層次帶來的效果是什么。所以這是需要你自己自行選擇的。

2. 搜索中

用戶點擊搜索功能輸入問題這段時間，我們看作搜索中，在這里有兩種設計方式：分別是當前頁面直接進行搜索和進入搜索獨立頁面。

其中，當前頁面直接進行搜索，在pc端較為常見，因為pc頁面有大面積區域可使用，可以盡情展示內容所以常見。

另外一種采用搜索獨立頁面在移動手機端常見，因受限于手機屏幕大小，在不跳轉頁面直接搜索的情況下我們可展示的內容過于受限；而采用了新頁面承載搜索，那就可以提供更多的功能和內容。

在這里我們可以通過后臺管理功能，盡情的增加熱門搜索的內容。同時在用戶輸入內容后，我們對輸入內容進行聯想展示，方便用戶選擇他想搜索的實際內容，提高搜索的易用性和便捷性。

但是產品設計師們需要注意的是，聯想展示內容不易過多，控制在7個詞條左右就行，過多詞條會干擾用戶閱讀；展示內容需要有獨立一套邏輯支撐，需要明確告知研發，為什么顯示這些內容？這些內容排序依據是什么等。（這里后面部分會介紹說明）

同理，從提高搜索的易用性和便捷性這個目的出發，我們可以收錄用戶近期歷史搜索，以便用戶再次搜索相同問題；至于歷史記錄每次展示幾個，可參考7+-2法則控制數量。（一般人的短時記憶容量約為7個加減2個，即5–9之間，可以理解為7加減2個組塊。）

3. 搜索后

搜索結果的展示在移動端上一般是雙排和單排展示。雙排能夠展示更多的搜索結果。單排能對搜索結果展示更多的信息。

到這里基本對于搜索功能的原型就沒有問題，下面開始說說搜索功能的邏輯部分。

二、搜索的邏輯

先說結論：看似簡單的搜索其實并不只是由簡單的sql（數據操作語言）進行全數據庫搜索，里面還涉及對用戶搜索問題的、分詞、糾錯、預測、召回以及排序排序。

1. 分詞

分詞很好理解，就是當用戶輸入問題后，對輸入的文字進行拆分，就叫分詞。分詞核心在于分詞法以及特性字詞典庫。

同時分詞也叫NLP（自然語言處理分析）算是AI人工智能的一個分支，畢竟你需要讓人工智能理解你說的是什么，學的是什么，不然就成人工智障了。那么搜索是按照什么方式進行分詞的了？其實分詞的方式很像小時候查字典。

1）逐詞匹配

我們理解為一個人給你一句話，這時你需要將他們分成兩兩相對或三三相對的詞條，但是你并不知道如何那幾個相鄰的字能夠組成字條。那么索性你直接拿著這句話去翻新歡詞典，從頭到尾翻一次，發現沒有符合的時候，就刪除最后一個字，在去翻詞典。以至于將詞典中的所有詞按由長到短的順序在文章中逐字搜索，直至文章結束。

這種方式你可以想象下，如果是人是不是很崩潰。就算是電腦在進行，因為需要重復的查詢，也會造成效率低下，等半天才分詞成功。

2）正向最大匹配法

最大正向匹配會按照我們的閱讀習慣，從左到右進行匹配，而其中的最大的含義就是當出現多個匹配詞條時，以字數最多的詞條為準；比如匹配野生動物園這個詞條有兩個匹配，一個是野生動物圖案，另一個是動物園，那我們以野生動物園為最終匹配，按照這個思路我們再說明。

有個用戶搜索：“成都動物園在哪里”。

• 這個時候進行第一次詞典查詢，按在最大的詞“成都動物園在哪里”進行查詢，發現沒有匹配。
• 進行第二次查詢，這次查詢“成都動物園在哪”，同樣沒發現匹配。
• 進行第三次查詢，這次是“成都動物園在”，還是發現沒有匹配的。
• 第四匹配的時候，這次匹配“成都動物園”，結果在詞條里面檢索到了。

我們保留結果是“成都動物園”，隨后便去除“成都動物園”變成“在哪里”重新開始檢索；這樣根據我們的詞典進行分詞，我們可以得到結果：“成都動物園”“在”“哪里”，這就是正向最大匹配

3）逆向最大匹配法

大致邏輯和正向匹配相同，唯一的區別在于它是從右到左，每次減去開頭的字。還是以“成都動物園在哪里”為例。

• 第一次詞典查詢，按在最大的詞“成都動物園在哪里”進行查詢，發現沒有匹配。
• 進行第二次查詢，這次查詢“都動物園在哪里”，同樣沒發現匹配。
• 進行第三次查詢，這次是“動物園在哪里”，還是發現沒有匹配的。
• …….
• 最后在第七次查詢我們得到“哪里”，隨后便去除“哪里”對““都動物園在”進行檢索。

當同樣的邏輯縮減到“在”后，還是沒有相對應的詞典，那么將“在”也單獨剔出，開始檢索“成都動物園”。這樣第一次檢索就成功檢索出來，得到結果“哪里”“在”“成都動物園”這樣的分詞。因為是反向其實結果和正向結果相同。

4）雙向匹配

這種匹配法是為了更加準確的分詞出現，把正向和反向兩種算法都切一遍，然后根據詞條顆粒度來進行選擇。分詞的詞條越長越好，非詞典詞和單字詞越少越好的原則，選出這里面最合適的進行匹配。例如：

• 非詞典內的詞：正向匹配（1）> 反向匹配（0） 選擇反向
• 詞典內的單字：正向匹配（2）= 反向匹配（2） 持平不做選擇
• 總分詞數量：正向匹配（3）< 反向匹配（2）選擇反向

2. 詞意糾錯

詞意糾錯也是搜索里重要的一環節，在搜索的時候，打錯字說錯話是很常見場景（語言搜索）；并且因為文字和語言是情感交流的渠道，中文漢字會因為聲調的不同有著不同的含義，同時一詞多義，通假字等也是十分頭疼的事情。

這詞意糾錯也可以按照查字典來理解，只是查詢的字典是特殊字典里面的內容包含了情感，拼音還有聲調相關的內容。抽象點的描述，我們在看見“康帥傅”的時候大腦會把“康帥傅”自動糾錯成“康師傅”，這就有點自動糾錯的味道。

1）拼音糾錯

當輸入的漢字存在錯誤時，系統需要及時聯系上下文進行解析，可以將漢字轉換成拼音，通過同拼音進行識別，比如“如何吧大象放入病象”，把他們未能分詞成功單獨留下的漢字轉化成拼音“如何”“ba”“大象”“放入”“bing”“xiang”在查詢字典進行處理。

2）模型算法

這部分高于繁瑣，想了解的可自行搜索：SVM、Maxent等。

3. 類目預測

用戶使用搜索功能在于得到解答，所以我們需要理解用戶搜索內容的含義；比如用戶搜索蘋果的時候，她搜索的是吃的蘋果還是蘋果手機了；一個吃一個用這兩個答案是風馬牛不相及的，所以預測類目會對用戶搜索結果影響很大。

做類目預測有幾個方法：

1）人工配置

通過后端埋點日志搜集最近熱門的搜索詞，對這些搜索詞進行指定配置，這樣就可以保證當用戶搜索蘋果的時候出來的是蘋果手機，而不是真的蘋果；這樣也是最簡單有效的方法，但麻煩在需要安排人長期維護。

2）類目相關性

通過對搜索詞進行算法計算，從搜索詞的重要性、類目數、類目出現次數、搜索詞出現次數等進行計算。

代表性tf-dc算法。

4. 結果排序

搜索結果的排序也是十分頭疼的事情，比如搜索蘋果手機，出現的結果是10萬+條商品信息，那么誰排第一這就成了一個問題，因此我們要從權重出發進行權重排序。（商品少也可以按照最新更新時間排序，哈哈看個人）。

• 詞頻：對搜索對query進行分詞處理，在進行預測類目后對高詞頻內容優先展示；
• 用戶標簽：符合用戶標簽喜好的商品進行加權,優先排序；
• 時間段：對當前時段營業（客服在線）進行加權；
• 銷量、好評率：同理這就不說了；
• 商品時效：對新更新商品進行加權，可用于互沖舊商品銷量、好評的加；
• 付費：競價廣告、付費升權等。

作者：wcof，在努力做產品不做產品經理的人；微信公眾號：Wcof（ID：wcofPM）

本文由 @Wcof 原創發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議。