后臺產品設計系列:搜索的細節(八)

7 評論 16367 瀏覽 172 收藏 10 分鐘

一個看似簡單的搜索功能,卻包含許多“不為人知”的細節。本篇文章詳細地介紹了后臺產品搜索的相關細節。

魔鬼存在于細節。后臺產品中,搜索是非常常用的功能,幾乎每個數據列表上都會有一個搜索欄,但一個看似簡單的搜索功能,卻包含眾多你想到或想不到的細節。

此篇文章,將詳細介紹后臺產品搜索的那些不為人知的那些事。

一、輸入框搜索

針對數據格式非標準的字段,都會通過輸入框進行搜索,如名稱、概述、正文等。

對于輸入框搜索,需要考慮以下幾個要點:

1. 聚合搜索or分字段搜索

聚合搜索

聚合搜索是指一個輸入框,可以同時搜索多個字段內容。例如下圖中,輸入關鍵詞“人人都是產品經理”,可以對名稱、描述等多個字段進行匹配。

優點

  1. 很方便,一次性能搜索大量數據;
  2. 用戶不用記憶我要搜索的關鍵詞到底在哪個字段

缺點

  1. 同時檢索字段數據多,當數據量很大時,會導致搜索時間過長,影響體驗;
  2. 搜索結果不夠精確,如果只提供聚合搜索,對于用戶清楚的知道搜索關鍵詞在哪個字段的場景不友好

分字段搜索

由于我們的系統隨著時間推移數據會越來越多,同時使用者多為對數據很熟悉的人,所以聚合搜索看似很方便,實則在系統產品中應用并不多。

也就是我們下圖看到的,每個字段單獨給一個輸入框,將搜索精確到字段。

綜合形式

有時候為了覆蓋更全的場景,也可以使用綜合的方式,輸入關鍵詞的同時給出“全部”和其他可能需要搜索字段選項,由用戶自己選擇。

這種方式適用于用戶對數據熟悉程度有深有淺的產品,內部系統適用較少。

2. 模糊搜索or精確匹配

模糊搜索

模糊搜索是只要根據幾個關鍵詞,就會把含這個關鍵詞的數據都顯示出來,即使輸入不完全,也能完成搜索,我們做系統搜索時,基本都是模糊搜索,這種方式體驗更好。

精確匹配

精確匹配需要用戶把搜索數據填寫完整、準確,給用戶帶來較高的記憶成本,主要在兩種特殊場景下會使用:

  • 對接的第三方系統,第三方系統無法提供模糊搜索接口;
  • 搜索數據有保密性要求。這種場景下,不能讓用戶隨便輸入一個關鍵詞就進行匹配,會存在其他信息泄露的風險,例如通過身份證號進行搜索時,用戶必須輸入完整身份證號信息才會進行匹配;

3. 實時搜索or手動觸發

實時搜索

實時搜索是每輸入一個字符就根據已輸入內容進行搜索。這種方式很及時,能讓用戶及時看到結果,搜索體驗會很好,但這種方式意味著實時請求搜索接口,對接口造成一定壓力,當使用人數較多時,容易出現系統報錯,所以即使這種方式體驗會好,我們也很少采用。

手動觸發

手動觸發則需要用戶在輸入完成后點擊“搜索”按鈕進行操作,有時候輸入框頁面上距離“搜索”按鈕較遠,體驗會很差,所以一定要加入“回車鍵”搜索的功能,保留用戶使用瀏覽器的習慣。

4. 歷史記錄加or不加

搜索的歷史記錄主要是方便我們間隔一段時間再次搜索同一條數據。

在很多To C的產品中,會經常使用歷史記錄功能,例如很多電商產品。但我們做后臺搜索時,很少會增加搜索的歷史記錄,這是因為我們每次搜索出的結果是明確的,短間隔時間無需再次進行搜索,對于長時間間隔場景,我們一般會通過數據權限控制讓搜索更方便,所以,后臺產品的搜索一般不需要歷史記錄。

二、單選/復選搜索

單選/復選搜索在有的產品中也叫篩選,功能都一樣。主要用于搜索數據標準化的字段。

1. 搜索樣式

單選搜索

根據選項數量,我們選擇下拉框中是否需要增加“搜索選項”功能,一般選項超過十個就要考慮增加“搜索選項”了,避免用戶查找困難。

復選搜索

復選搜索也比較常見,當我們需要同時查看多種選項數據時,就要使用復選搜索

2. 獨立搜索or聯動搜索

所謂獨立搜索,就是每個篩選項是獨立的,不會因為已選擇的搜索條件而改變,而聯動搜索,則會因已有搜索條件,而改變現有搜索范圍。

例如省市區的聯動搜索,選擇省份后,城市的選擇范圍就在這個省份內,而如果先選擇了城市,那么省份就會默認選擇這個城市所在省份,無法選擇其他。

當多個搜索條件存在關聯性時,我們就應采用聯動搜索,作為產品經理,需要清楚的定義搜索條件間的相互影響、層級關系、數據對應關系。

3. 搜索所有or僅列表數據

有些篩選字段,我們有全部的數據,但列表中只有這個字段部分數據信息。例如用戶通過測試管理系統提bug,我們在篩選哪些人提了bug時,到底是對公司所有人都能選擇篩選還是只篩選提過bug的人呢?

這里一個重要的判斷原則就是未提過bug的人是否以后有提bug的可能,如果以后也有可能,那么應搜索所有人。

三、整體

1. 前端搜索or后端搜索

對于沒有開發經驗的產品經理,是不會思考讓后端搜還是前端自己搜這個問題的。

所謂前端搜索,是后端把所有數據通過接口一次性都返回給前端,每次搜索時前端自己根據已返回數據進行搜索,這種方式主要應用在數據變動頻率低的場景中,而對于變動頻率高的,都會采用后端搜索,即每次有搜索請求,都會通過接口讓后端在數據庫中匹配,以達到及時準確的目的。

2. 能否自定義搜索條件

當系統數據量很大,字段很多時,我們經常需要對大多數字段都要篩選搜索,但我們不可能把所有字段都作為篩選項放在搜索欄中,不僅會占據太多位置,也會影響可讀性和美觀。

另外,不同角色對搜索字段需求是不一樣的,使用頻次也不一樣,所以這個時候我們需要針對篩選條件提供自定義功能,讓用戶根據自己的使用習慣,選擇需要哪些篩選條件和順序。

 

作者:周翔,起點學院深圳1609期產品經理實戰訓練營學員

本文由 @周翔 原創發布于人人都是產品經理。未經許可,禁止轉載。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 我的新書《不枯燥的B端產品實戰課》已上線,更多干貨盡在書里,京東地址:https://item.jd.com/12786741.html

    來自廣東 回復
  2. 請教一個問題,B端軟件歷史數據量達到千萬級,如何滿足歷史數據搜索場景?,F在的思路是提供2種查詢功能,分別去查業務數據庫(最近3個月提交單據的實時數據)+數倉(凌晨定時更新數據,沒有當日新增數據,當日更新數據不準),很惆悵。

    來自浙江 回復
  3. 看完了八篇后臺設計,感覺很受益,作者可以針對后臺設計中的結構設計這個模塊再做一篇嗎~~

    來自北京 回復
    1. 正在寫本B端的書,書中會介紹這部分

      來自廣東 回復
  4. “對于長時間間隔場景,我們一般會通過數據權限控制讓搜索更方便”,關于這一點不是很理解,可以請作者詳細說下嗎~~

    來自上海 回復
    1. 同問+1

      來自廣東 回復
  5. 學習了,都是干貨額全部學習了

    來自北京 回復