后臺全局搜索交互設計案例
搜索看似簡單,但是細節很多,早前寫過一篇關于搜索方面的文章《交互設計基本功:如何設計一個好用的搜索框?》,幫大家普及了搜索方面的知識,但是不同設備、不同場景下搜索功能的設計千差萬別,做好搜索的交互設計,還需要大量的案例實踐。本次帶來了一個后臺全局搜索的設計案例,幫助大家打開思路。
導讀目錄:
- Chapter 1 需求背景
- Chapter 2 需求分析
- Chapter 3 交互設計:搜索一般狀態、搜索異常狀態、其他限制條件
Chapter 1 需求背景
一個類CRM的后臺管理系統,客戶經理可以通過客戶列表檢索名下的客戶,現在增加客戶全景視圖(客戶詳情),點擊列表上的客戶名稱即可打開客戶全景視圖。新的需求是,增加一個全局搜索的功能,通過搜索客戶名稱或者客戶編號即可直達客戶全景視圖。
拿到這個需求之后,是不是覺得很簡單?不就是在頂部顯眼的位置增加一個搜索框嘛,只需要1分鐘就可以搞定,連設計圖都準備好了(見下圖)。然而,我們都知道,搜索功能并非這么簡單,換個說法就是,這樣的設計稿并沒有把所有細節考慮周全,是不可能通過設計評審的。
Chapter 2 需求分析
既然沒有那么簡單,我們拿到需求的第一步還是需要進行需求分析,需求分析的過程和方法見仁見智,這個例子可以用一種自問自答的方法進行需求分析:
- 這個全局搜索的功能是否值得做?——值得,為直達單客戶全景視圖增加了入口,且節省中間先查看列表的步驟,該功能使用頻次高。
- 搜索功能放在哪個位置比較合適?——全局搜索,一般放在右上角比較顯眼的位置(個別網站在頂部中央),遵循web網站的搜索習慣。
- 搜索的數據量大不大?——據了解,每一名客戶經理名下平均有1000名客戶,數據量不大。(這涉及到從數據庫提取數據的效率)。
- 是否有搜索權限控制?——有數據權限控制,客戶經理只能搜索到自己名下的客戶,不能搜索到其他客戶經理的客戶。
- 搜索是模糊匹配還是精準匹配?——精準匹配,客戶經理輸入客戶姓名/編號進行匹配,編號是唯一標識,用于區分同名客戶,精確匹配,同時也意味著可以放棄展示模糊搜索結果頁,從搜索匹配列表中選擇結果。
- 大致的交互流程是怎么樣的?——輸入客戶姓名/編號→選中客戶→跳轉到全景視圖。
Chapter 3 交互設計
1.搜索一般狀態
搜索一般狀態通常指默認狀態、獲取焦點、輸入中、失去焦點4種狀態,只需要把示例圖和說明列示出來,就很容易理解了。
- 默認狀態:輸入框提示語為:請輸入客戶姓名/編號。
- 獲取焦點:獲取輸入光標,提示語不消失。
- 輸入中:①輸入中,實時顯示聯想結果,匹配的詞匯高亮顯示;②鼠標懸浮結果列表時,樣式有變化;③點擊列表結果,在新窗口打開相應客戶全景視圖。
- 失去焦點:保留輸入的內容。
2.搜索異常狀態
本案例中,搜索的異常狀態會分為兩種情形,其中一種是搜索不到客戶,即搜索無匹配的結果,這時需要增加相應的提示,例如“沒有找到相關客戶”;另外一種是客戶經理輸入非法字符,如“#@¥%……&*()”這些,系統是不支持的,這時可以采用輸入非法字符不展示或者用錯誤提示“請輸入中文字符或數字”的方式來規避。
但是,再進一步思考,這兩種異常情形可以合并簡化處理,因為客戶經理的目標是搜索到相應的客戶,而不是完成表單輸入,他輸入的內容不會保存到數據庫,所以不需要強制輸入有效字符,我們可以把兩種情形都歸結為他的輸入“沒有找到相關的客戶”。
統一處理方法為:輸入內容匹配不到結果,或者輸入非法字符,統一醒目提示“沒有找到相關的客戶”。
3.其他限制條件
(1)數據權限
根據需求分析得知,客戶經理只能搜索到自己名下的客戶,不能搜索到其他客戶經理的客戶,交互說明中要增加相應的注明文字。
(2)匹配結果限制
當搜索匹配結果太多時,例如輸入大姓“張”可能匹配到幾百個姓張的客戶,如果全部列出來則需要搜索結果列表出現滾動條,且影響搜索效率,所以限制最多返回10條匹配結果。
(3)限制“Enter”鍵搜索、點擊圖標搜索
由于是精準搜索,需要從匹配結果中進行選擇,而不是根據關鍵詞匹配到一個搜索結果頁,所以限制了使用鍵盤“Enter”鍵和點擊圖標搜索。
以上,就是一個完整的后臺全局搜索的設計案例,它是基于后臺產品的實際場景提供的設計解決方案,不適用于所有場景,僅提供一些設計思路供參考。
作者:夜雨,高級交互設計師,專注金融行業-智能投顧方向,大部分時間在復雜后臺系統中遨游。簡書:夜雨y;微信公眾號:iueuxd。
本文由 @夜雨 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自unsplash,基于CC0協議
“匹配結果限制,最多返回10條匹配結果”,如果返回的10條結果,都不滿意,怎么辦
適當增加條數,要不就讓用戶輸入的關鍵詞更精準
在做數據列表的時候就應該要考慮到數據權限的問題吧?而不是因為增加了搜索功能才去考慮。。。
真的非常棒的一篇文章,簡單的東西也能出彩,作者有心了,謝謝
從簡書追到這里來,向夜雨學習!
我覺得Ok,因為我打得過開發~
厲害了,小姐姐
學習了 , 這樣的原型設計 ,開發爸爸看到了開心的估計要‘自抱自泣’了。
為了盡量避免遭到開發爸爸的毆打,產品、設計日常都要努力為開發爸爸遞水。。。
敬佩,邏輯很嚴禁,說明也很貼切,能簡單明白,贊一個
?? 謝謝支持
做后臺的時候要考慮使用者是誰,如果是自己的產品,交互這塊是不太需要多注意的,而且做后臺是需要有2b的思維的,保證功能性和邏輯性為首要原則,還要做好權限與安全。后臺本身就不是一個特別需要交互的模塊
不是很同意“后臺本身就不是一個特別需要交互的模塊”這句,在同等功能實現的前提下,交互設計能顯著提升后臺系統的使用效率,效率就是生命。
你不結合語境理解我也沒辦法
你不結合語境理解我也沒辦法,做外包你肯定要盡可能考慮交互,你給自己產品做后臺管理,過交互屬于浪費資源
說的大部分贊同,但是交互還是要考慮的,而且交互設計得好的話,能極大提升工作效率。
這個對后臺數據實時查詢要求很高,而且如果后臺數據庫還存在連表的狀態,這個對程序開發來說,可能不受程序員待見!
嗯,要根據自己的項目實際情況來決定
這樣的交互可能并不方便,讓人沒有安全感,我可能想搜出所有的張三,然后查看一下哪個是我要找的張三(比如其中一個是錯誤數據,我要找到并刪除),如果直接跳轉頁面,那么我就沒法對比
金融后臺操作,刪除數據一般要交叉權限,刪除需要經過審核后才能正式刪除。談不上什么安全感。查詢一般戶名可能不是唯一的同名同姓的人多,所以會依據客戶號和賬號去確定這個客戶。
嗯,這位同學解釋得很清楚,這個不是列表搜索,注意應用場景示范~~
嗯嗯,明白了,謝謝樓上,也謝謝樓主~
盡管是一個小需求,但是深挖發現還是有很多容易疏忽的地方。文章思路很清晰,分析得也很到位 ??
?? 共勉之