在產品中一般會分布著大大小小的搜索，以便提升用戶的信息獲取效率和信息消費的能力。本文作者全流程角度，對搜索功能進行了講解，并從搜索流程中尋找提升體驗的觸點，一起來看一下吧。
在產品中因多功能訴求和業務復雜性等因素，界面大多有高信息密度和高交互密度的特征，為了讓用戶能快速獲取信息和完成任務，在產品中會分布著大大小小的搜索，以便提升用戶的信息獲取效率和信息消費的能力。
同時因為用戶輸入內容不可控、解析-匹配-排序規則的復雜度、用戶搜索場景的不同等因素，讓搜索功能有一定空間去提升體驗，所以本文將嘗試從全流程角度講解搜索功能，從搜索流程中尋找提升體驗的觸點。
若對內容有疑問或想要探討，希望各位不吝賜教～
本文將通過「激活搜索」、「輸入關鍵詞」、「解析內容」、「召回」、「排序」、「結果呈現」6個步驟對搜索內容進行拆解說明。其中前三部分和交互強相關，所以本文將重點講解。
一、激活搜索
激活搜索階段最重要的是提供反饋明確當前狀態，目前大抵會有兩種呈現方式。
1. 出現搜索下拉面板，展示搜索歷史or熱門搜索or內容引流
如：在飛書文檔中激活搜索時會在面板中展示“搜索歷史”和“最近瀏覽”，增加相關內容曝光，去給用戶提供更多選擇以觸達目標內容，該交互形式通常出現在全局性搜索或多維度搜索功能中。
再如：在餓了么中激活搜索進入搜索頁，不僅會提供歷史搜索，還有一系列的推薦內容和營銷榜單的引導，達到商業運營的目的。
2. 僅光標聚焦到搜索框中
如：Coding的事項列表中點擊搜索，僅光標聚焦搜索框。
作為任務管理工具在使用搜索時其目標是非常明確的，其對于搜索體驗目標是要求快速匹配內容。僅聚焦搜索框中可以減少視覺干擾專注于完成搜索操作。該交互形式常運用于B端產品的表格、列表搜索中。
所以在激活搜索階段需要結合當前產品性質和搜索場景綜合考慮采用何種反饋形式。
二、輸入關鍵字
在此之前我們先看幾個例子：
- 石墨文檔中，輸入關鍵字后即開始進行搜索行為，并在下拉面板中直接呈現出了搜索結果
- 知乎中輸入關鍵字后即時出現了關鍵詞聯想列表，用戶可選擇回車or點按鈕查看搜索結果，也可根據列表切換關鍵詞后查看結果。
可以看出不同產品的交互差異，那造成這種差異的原因是什么呢？之前在思考這個問題的時候認為是B端產品和C端產品的區別，但仔細一想這樣劃分過于粗暴。后續嘗試用搜索場景來解釋發現會更合理。
1. 定義搜索場景
在《Web信息架構》中對搜索場景劃分為4類，在結合具體產品后我將其收縮為2類。
1）已知條目搜索
用戶有非常明確的搜索目標，是在已知內容庫中快速定位信息。輸入的關鍵詞就是想要獲取信息主題。
如：想在Jira上看掛在我頭上關于“組件”的任務，會直接在列表中搜索“組件”，此時的搜索結果即我想要的內容。如：查找微信聯系人，是有非常明確的搜索目標。
2）探索式搜索
用戶有模糊的搜索目標，是在未知內容庫中搜尋信息。是對于該類信息主題是未知的想要去探索，且大概率是不能精準描述關鍵詞和結構化表達問題。
如：最近在做組件，想看一下相關文章參考，則會在一些知識平臺上輸入“組件”查找參考。若沒有查找到目標內容，則不停的切換關鍵詞“組件規范”、“組件設計”、“基礎組件”進行搜索，直到查找到相關目標內容。
2. 對應的交互方式
這兩種搜索場景用戶訴求不同導致用戶體驗目標的不同，則在輸入關鍵詞階段會提供不同的交互方式。
1）已知條目搜索
體驗目標：用戶目標明確，需要更快更精準的提供結果。
交互方式：輸入關鍵字過程中進行搜索行為，實時展示搜索結果。
2）探索式搜索
體驗目標：用戶目標模糊，提供關鍵詞輔助能提供更標準化的關鍵詞便于更精準的查找到內容。
交互方式：輸入關鍵字后即時提供關鍵詞聯想，回車進行結果查詢。
從搜索場景角度出發處于探索式搜索時可提供「關鍵詞聯想」功能提升搜索體驗，但「關鍵詞聯想」在其他產品中也有廣泛的運用。
3. 關鍵詞聯想的運用
1）在內容平臺中以降低用戶輸入成本，提升搜索效率
如：準備在小紅書上查一下冷凍水餃是冷水還是熱水下鍋，在輸入冷凍水餃后就出現大量關聯問題，可直接切換選擇則完成搜索。
在谷歌中搜索“今日天氣”會在面板中直接顯示天氣數據，直接將結果顯示在關鍵詞聯想面板中，減少了跳轉成本。
2）商業化運營的目的
如：在餓了么搜索“奶茶”，則不僅出現帶“奶茶”的商品，還穿插了奶茶果汁排行榜及奈雪、兵立王的商家關聯。其中奈雪多次下單過，所以可能是根據最近購買記錄進行優先展示，然而兵立王我從未下單過也從未瀏覽過出現在這兒大概率是商業曝光。
總而言之，關鍵詞聯想是適用于探索式搜索場景以提升搜索準確度和有效性；同時適用于內容平臺性產品以降低用戶輸入成本；及有營銷訴求的產品以滿足商業化運營。
所以在設計時應當考慮產品目標和用戶場景去設計輸入關鍵詞階段的交互流程，以提供更好的搜索體驗。
三、解析關鍵詞（Query）
在搜索輸入關鍵字過程中會存在拼寫錯誤、語義表達差異等原因導致搜索結果不準確或搜索無內容。所以為了更準確的理解用戶意圖，加強系統的理解能力通常都會設置多種解析規則，對關鍵詞進行預處理、改寫、分詞等，以提供更準確的搜索結果。同時對關鍵詞的解析越精準細致，搜索顯得越智能高效，也能較大提升搜索體驗。
舉個例子：飛書文檔中輸入“wendang”，能搜索出“文檔”的內容；石墨文檔中輸入小寫的“meri”，能搜索出大寫“MERI”的文檔；百度中輸入拼寫錯誤的“appla”，能搜索出Apple相關內容。
以上產品所展示的解析能力為「預處理」、「改寫」、「分詞」三大塊，也是現有產品中最常用的解析能力。當然對于搜索引擎和ChatGPT這類產品會有更專業化更復雜的的解析流程本文暫不涉及，主要是超過我知識范圍了…下文將根據常用的這三塊內容詳細講解。
1. 預處理
預處理指將關鍵詞進行字符轉化、刪除、截斷處理方便后續進行分析。其目的是轉化和簡化關鍵詞，更好的理解用戶意圖，以提供更合適的搜索結果。
預處理具體分為以下幾種能力：
1）拼音轉文字
輸入拼音時可轉化為文字進行結果查詢，如：輸入“chanpinsheji”，將轉化為“產品設計”進行搜索。就從個人日常使用搜索功能而言，常會忘記切換輸入法直接輸入了拼音，此時提供該能力也能進行有效搜索時是能帶來體驗上的驚喜感。
功能雖好，但也不一定產品內所有搜索功能都需要加上拼音轉文字能力，這個也是需要結合當前搜索場景和用戶行為具體分析是否為一個高ROI功能。
如：在一些B端 CRM系統中客服人員會通過搜索客戶名稱進行資料錄入，此時的搜索場景大多是在IM聊天窗口中復制客戶名稱再粘貼到搜索框中從而完成搜索行為。此時的搜索大多不會牽扯到手動輸入，此時拼音轉文字能力作用也不大。
2）大小寫轉換
大寫字母轉換為小寫字母進行結果查詢，即不論用戶輸入大寫或小寫字母都能查詢到對應結果。
如：輸入“f6”，能搜索出大寫“F6”的內容。
該能力適用于帶有字母的結果數據。舉個例子，在ERP系統中有大量的企業物資信息，其中對于一些固定資產通常會以“樓層+設備名+設備編號”來進行命名，如：“F6-iMac-7842”，字段為大小寫字母混排，存在較高的輸入成本。若提供大小寫轉換，則直接輸入“f6-imac-7842”也能出現對應結果。
3）繁簡體轉換
將繁體字轉化為簡體字進行搜索，該能力則適用于涉及到繁體字使用習慣地區用戶，本次就不再贅述。
4）無意義字符移除
無意義字符包括特殊符號（emjio、表情符號、連續的空格符等）和無意義字符（“的”、“了”、“么”、“哈”等語氣組詞）。無意義字符會打包成一個《停用詞庫》作為搜索配置庫存在，且目前有大量的開源《停用詞庫》可直接調用，所以具體停用哪些字符可基于開源詞庫的內容再結合業務訴求進行增刪。
舉個例子，在飛書文檔中輸入“會議”且中間插入多個空格，依舊能搜索出帶“會議”的文檔。
注意看輸入框下方第一行文字“在高級搜索中查看 ‘會 議’ ”，將“會 議+6空格”縮短成“會 議+1空格”，僅保留了一個空格作為分詞符，去掉了多余的空格符。
而在石墨文檔中輸入“設計”能查詢到內容，若中間插入多個空格則搜索無結果。石墨則是將所有輸入內容作為有效字符進行搜索，進而搜索結果為空。
從體驗上來看，飛書文檔通過增加系統搜索規則來減少錯誤輸入導致的無結果，增加了系統容錯性，來提供更多的可能性，減少空數據帶來的失落感。
插入一個關于空格的小細節：
當初寫搜索功能的交互說明時，被測試問道如果輸入連續的空格如何響應？當時想的是誰沒事干輸那么多空格，但作為一個專業的和藹可親的設計師怎么能將心里話說出來呢。所以趕緊看了各大產品的處理方式以便于合理借鑒，發現主要分為以下幾種類型：
- 輸入多個空格后，搜索結果面板顯示無結果，點擊回車無響應
- 不允許輸入空格，輸入非空格字符后才能輸入空格
總的來說，分為兩類一種是前置防錯，直接不允許輸入，在數據結構中大多數情況中不存在多空格數據的存在；另一種是后置反饋，允許輸入任何字符無匹配內容則顯示無結果，這種處理方式更簡單直接，不做任何特殊處理有結果就顯示沒有結果就為空，給予用戶最大的操作自由同時邏輯也統一。
個人角度更偏向第二種，即保證用戶輸入的自由度，通過搜索規則合理去除無意義字符，此時還未有對應匹配內容則應當告知用戶無結果，告知用戶嘗試用其他關鍵詞進行搜索。同時也減少規則的復雜度。
5）長度截斷
即將超過設定長度的關鍵詞進行截斷，減少查詢壓力。如百度的查詢限制為38個漢字，谷歌的查詢限制為32個詞。
總的來說，預處理中的「拼音轉文字」、「大小寫轉換」、「繁簡體轉換」是通過增加系統判斷規則的復雜度來減少用戶輸入的復雜度，降低用戶的輸入門檻和成本，提升用戶操作的自由度。「無意義字符移除」和「長度截斷」則是合理篩查關鍵詞，精簡表達提升搜索結果的準確度。
2. 分詞
分詞是當輸入關鍵詞無法與數據庫完全匹配時，則會將關鍵詞拆分為多個Term（Term可以是詞組也可是漢字）再與數據庫匹配。如：“九轉大腸”無匹配內容時可拆分為“九轉”、“大腸”兩個詞組或拆分為“九”、“轉”、“大”、“腸”四個漢字進行匹配。
分詞的關鍵在于怎么分？在英文語句中“You are awesome.”用空格隔開了三個單詞，若用這句話進行分詞搜索則自然會拆分成“you”、“are”、“awesome”三個單詞。
在中文表達中沒有空格，且中文分詞不合適就會形成不同的語義表達。如“上海市長江大橋”可分詞為“上海市”、“長江大橋”，也可以是“上海市長”、“江大橋”。
目前大多數產品都是采用的基于詞典的分詞方法，即維護一個分詞庫，若輸入的關鍵詞命中分詞庫中的詞語時，則能召回詞語對應的內容。
舉個例子，在飛書文檔中輸入“頭腦”，會出現包含“頭腦”詞語的文檔；若輸入“頭腦暴”，則無結果。這是將“頭腦暴”作為一個詞組參與搜索，沒有命中分詞庫數據庫也無匹配內容。
在石墨文檔的結果匹配中則是將分詞邏輯直接用分隔符顯示出來了。如：輸入“小李的工作內容”首先停用了“的”，然后拆分為“小李”、“工作”、“內容”三個詞組進行結果匹配。
但基于分詞庫進行分詞會存在一定的維護成本，如：出現新詞則需要手動添加等。
隨著分詞技術的成熟，已經形成一套更為智能化的分詞方法和工具服務，會加入深度學習模型分析讓其更智能的分詞。因為這塊過于后端技術化所以不多贅述，有興趣的同學可查看《中文分詞的原理、方法與工具》這篇文章有詳細介紹。
分詞能力廣泛運用于探索式搜索場景的產品中，通過分詞技術將關鍵詞合理拆分重組，以召回更多相關內容，其注重的是查全率。所以在內容資訊產品（如：知乎、語雀、微信搜一搜）中通常都會運用分詞技術召回大量內容以滿足用戶查詢需求。
3. 改寫
改寫指的是將輸入關鍵詞改寫為另一個能與數據內容匹配的關鍵詞，具體可分為三個方向。
- 將拼寫錯誤的關鍵詞糾錯改為拼寫正確的字詞；
- 將不同文字表達但是同義的字詞統一歸為更為標準的字詞；
- 將輸入關鍵詞擴展出與其內容或行為語義相關的字詞列表，推薦給用戶便于對潛在需求挖掘發現。
1）糾錯
將拼寫錯誤的關鍵詞糾錯改為拼寫正確的字詞。如：在知乎輸入拼寫錯誤單詞“appla”，系統自動將關鍵詞修改為“apple”，并展示了對應結果。
相比英文單詞拼寫糾錯，中文字詞的糾錯則更為復雜。如：中文字若通過拼音輸入時就存在模糊音（平翹舌、前后鼻音等）、同音字錯誤；若通過五筆輸入時就存在形近字錯誤等。
在騰訊搜索技術文檔中將錯誤類型分為「Non-word Error」指不存在于詞典中的錯誤字詞；「Real-word Error」指由多個漢字組成的詞語錯誤。且這兩個大類還可以繼續拆分更小粒度的錯誤類型。
當然圖上的錯誤類型是全集，搜索引擎基于產品特性是大面積覆蓋了這些錯誤類型。除搜索引擎的產品則可根據產品定位和場景進行選擇性實現。
如：在釘釘的全局搜索中搜索聯系人就采用了「簡拼」、「漢字+拼音組合」、「混淆音」、「顛倒」等糾錯方式。但這些糾錯能力也僅限于聯系人，針對聊天記錄和文檔里的內容則不涉及。
仔細一想，很合理且必要。
聯系人數量有限，且名字是會存在生僻字，容易拼寫錯誤，且在使用釘釘中搜索聯系人是一個高頻行為，提供關鍵詞糾錯能力，是允許用戶出錯的同時加強系統的判斷能力并提供合適的解決方案呈現給用戶，從而減少不必要的錯誤提示和空頁面。
而聊天記錄和文檔則會因為使用時間不斷累加數據量，若提供過于強大的糾錯能力會召回大量低匹配度內容導致搜索結果不夠簡練準確。
2）歸一
將不同字詞但是同義的字詞統一歸為更為標準的字詞再做數據匹配。其目的是為了解決在表達中存在的語義差異，如：“iPhone手機價格”、“iPhone手機售價”、“iPhone手機多少錢”三種不同的語義都是表達統一含義，則可以將這三種表達都歸一到“iPhone手機價格”的標準字詞。
同停用詞庫，同義詞也會打包成為一個《同義詞庫》，且目前已有開源的詞庫，可在現有業務基礎上進行增刪同義詞。
如：之前設計產品中有針對整棟建筑內所有設備和空間的搜索，其中針對“衛生間”同義的詞語包括“廁所”、“洗手間”、“盥洗室”，所以就設置了將這三類詞語歸一為“衛生間”。這樣在輸入“廁所”時也能查詢“衛生間”的數據內容。
3）擴展
將輸入關鍵詞擴展出與其內容或行為語義相關的字詞列表，推薦給用戶便于對潛在搜索需求挖掘，該功能也稱為關鍵詞聯想。在本文的2.3「關鍵詞聯想的運用」階段對其有描述，在此就不贅述了。
隨著搜索內容越來越復雜和多語義化，解析關鍵詞會越來越重要。只有不斷細化和更新解析規則才能更準確理解用戶意圖，以盡可能獲得更準確的結果，增強搜索結果有效性。
話鋒強硬一轉，插入一個小話題。在網上看了多篇關于搜索的文章，發現大家對于“模糊搜索”和“精確搜索”的定義都有所不同，借此來說說自己的理解。
①精確搜索（=）：即關鍵字和內容完全匹配
例如：輸入“九轉大腸”，只會出現“九轉大腸”，關鍵詞與結果需完全一一對應。
②模糊搜索（like）：即關鍵字和內容不完全匹配也能出現結果，關鍵字與結果部分匹配即可
例如：輸入“九轉大腸”，會出現“九轉大腸俞濤”、“頂級廚師九轉大腸”、“九轉小腸”、“九轉豬肚”、“紅燒大腸”。
舉個例子，來看看知網當中可對搜索結果進行精確和模糊搜索，其搜索結果區別。
同時在解析關鍵詞這一環節中預處理、分詞、改寫這些能力也是對模糊匹配能力的進一步細化，如：輸入拼音、輸入首字母簡寫、同音字等也可進行匹配。
所以在做設計需求時應該明確模糊匹配是需要模糊到何種程度，而不是用該搜索支持模糊匹配一句話帶過。
四、召回
召回指的是關鍵詞經過解析后與數據庫內容進行匹配，尋找到與之匹配內容的過程，也就是系統在篩選符合用戶搜索需求的內容。
在這個階段后端同學會通過倒排索引技術來建立關鍵詞與數據庫的關系，提升搜索查詢效率。簡單來說就是建立類別清晰的目錄便于快速查找目標內容。
所以查詢速度則與該環節強相關，該環節倒排索引建設的越合理查詢速度越快。這塊內容因純為后端技術方向，所以也不多贅述。
五、排序
當在數據庫中查詢到多個結果時，則需要通過排序規則以優先級展示給用戶。合理的排序規則是將結果有效呈現的關鍵因素。
排序可大致分為兩個方向，一種是根據匹配度+數據參數進行優先級排序，如：搜索訂單、任務、事項這類數據時，可優先根據匹配度（如：匹配度越高越靠前），若匹配度一致則再根據訂單、任務、事項的數據參數排（如：創建時間倒序，可根據業務需要選擇具體參數）排序。
如在Coding上搜索“組件”事項，出現了4條包含組件條目的事項內容，其中狀態和優先級一致時，其ID是呈倒序，所以猜測Coding有一條排序的規則是根據ID序號倒序排序。
二種是根據加入多維度算法綜合打分排序，將評分結果越高的搜索結果越靠前。可根據數據類型列舉參數進行計算。用內容資訊類產品舉例，其通常會設置閱讀量、評論率、時效性等數據指標+權重計算得分進行排序。
如：在微信搜一搜中搜索文章、知乎搜索回答都有其一套默認的數據指標排序規則。
隨著搜索能力的成熟，目前也形成了一套專業化的排序方案，詳細內容可參考《一文帶你了解搜索功能設計》，在此也不多贅述。
六、結果呈現
作為搜索功能最后一環，清晰有效的展示搜索結果是其關鍵要素。
目前在各大搜索引擎中都逐步優化成基于關鍵字類型展示不同的結果形式，根據關鍵字類型盡可能多的曝露信息，便于用戶快速觸達和獲取信息，減少跳轉步驟。
如：在谷歌中搜索“日出”則首要出現圖片；搜索“杉木”首要匹配百科鏈接；搜索“iPhone 13”則首要匹配且定位到Apple官網中購買iPhone13的鏈接。
但在其他產品中是如何有效曝露結果信息，讓用戶能更快速有效的選擇內容呢？
來看一下文檔類產品，石墨和飛書，其下拉面板中展示搜索結果，同時也可hover結果條目時出現popover去預覽文檔內容。
再來看看語雀，搜索結果中則是展示了標題和部分內容。整體看起來信息密度過于大，沒有重點，很難識別到重要信息。特別是在查找公開知識庫內容時，從標題和描述文字很難感知具體內容質量，所以需要打開多個文檔查看內容，有較大的查找成本。
總之，在搜索結果呈現界面中應該根據結果形式特點去設計搜索結果頁，或是通過有序分類導航或是以靈活化的結果展示形式等，為用戶提供更可視化的結果，減少用戶查找和跳轉成本。
七、打個總結
本文拆解了搜索這么多能力，那產品內的搜索都需要實現這些能力嗎？
個人認為不是的。
首先不同產品搜索場景不同，重要度不同，其對搜索功能完備度要求也不一樣。
其次在做產品設計過程中因產品商業目標、功能規劃、技術限制等是不可能一次性將功能做完美到極致，這時候就需要設計師從用戶體驗出發結合客觀條件因素限制提出性價比更高的解決方案。或是優先實現核心場景的高頻使用痛點，或是優先實現核心用戶的使用痛點，實現設計價值最大化。
同時當設計師對功能底層邏輯了解的越透徹，在產品和開發面前也更有“議價”的權利，從而提升設計師話語權，更好的讓設計產生價值。
所以打工人追求Work Life Balance，體驗設計師應該追求Business Experience Balance。
參考文章：
- Google 自動完成功能在搜索中的工作原理
- 搜索聯想詞產品實踐系列（一）:定位-評估和召回篇
- 騰訊搜索：搜索中的 Query 理解及應用
- 中文分詞的原理、方法與工具
- 阿里云：智能開放搜索OpenSearch
本文由 @0479 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
