Search UI 設計模式:從 Quizlet 到 Notion
為什麼搜尋 UI 值得專門研究?
搜尋是幾乎所有產品都會有的功能,但不同產品的搜尋體驗差異巨大。好的搜尋不只是「找到結果」,而是讓使用者能快速理解結果的上下文並做出行動。
我花了一些時間拆解幾個我常用的產品,整理出一些值得注意的設計模式。
模式一:搜尋欄位定位
搜尋欄位的位置直接影響使用頻率和發現性。觀察到三種主要方式:
頂部常駐型
Notion、Slack 將搜尋放在頂部導覽列,隨時可見。這適合搜尋是核心操作的產品——使用者頻繁需要跨內容尋找資訊。
Command Palette 型
Linear、VS Code 使用 ⌘K 快捷鍵觸發搜尋。搜尋不佔據固定 UI 空間,但需要使用者知道這個快捷鍵存在。這種模式近年越來越流行,因為它:
- 節省 UI 空間
- 可以整合搜尋以外的功能(命令面板)
- 對鍵盤使用者非常友善
混合型
有些產品同時提供兩者——頂部有一個搜尋 icon 或簡化的輸入框,點擊後展開完整的搜尋對話框。Notion 就是這種做法。
模式二:搜尋範圍與 Tab 切換
當產品內容類型多元時,如何讓使用者選擇搜尋範圍?
Quizlet 的 Tab 分類
Quizlet 在搜尋結果上方放置明確的 Tab:Sets、Textbooks、Users、Classes。這對 Quizlet 來說很合理——使用者通常明確知道自己在找什麼類型的內容。
Notion 的智慧分類
Notion 則採用更靈活的方式——搜尋結果自動按照相關度排序,混合呈現不同類型的內容(頁面、資料庫、人員),但提供篩選器讓使用者縮小範圍。
模式三:搜尋結果的呈現
結果呈現的品質直接決定搜尋的實用性。
上下文摘要
好的搜尋結果不只顯示標題,還會顯示匹配關鍵字的上下文片段。關鍵字高亮幫助使用者快速確認這是不是他要找的。
即時預覽
Notion 和 Heptabase 在搜尋結果旁邊提供即時預覽。使用者不需要實際打開內容就能判斷是否符合需求,大幅減少來回切換的成本。
鍵盤導覽
對重度使用者來說,能用鍵盤(上下鍵 + Enter)快速瀏覽和選取結果是必備的。cmdk 這個 React 套件就是為此而生。
設計取捨
沒有放之四海皆準的搜尋 UI。選擇哪種模式取決於:
- 搜尋頻率:高頻 → 常駐;低頻 → 隱藏
- 內容類型數量:少 → 混合結果;多 → Tab 分類
- 使用者類型:開發者 → Command Palette;一般使用者 → 可見搜尋框
- 內容結構:結構化 → 篩選器;非結構化 → 全文搜尋
最終,好的搜尋體驗是「讓使用者不需要思考如何搜尋」。