編輯導語：后臺系統(tǒng)在日常工作中是非常重要的，后臺內容的列表足夠全面，可以讓我們快速定位到內容，提高工作效率；本文作者根據自身經驗分享了關于列表頁的“坑”和必坑指南，我們一起來學習一下。

列表頁是構成后臺使用界面的重要組成之一，聚合了眾多信息并提供操作入口。

區(qū)別于小而美的C端產品列表，后臺系統(tǒng)的用戶希望列表的內容又多又全面（表格），但在操作時又能支持快速定位（搜索，包含篩選）、準確處理（操作）。

這需求貌似有些矛盾，但在很多場景下，例如：客服在接待客戶時窗口時間極其短暫，既要全面獲取相關信息，又要快速應對解決客戶問題；因此這需求不僅合理而且是剛需。

列表頁由「搜索」、「表格」和「操作項」三大基本塊組成。

剛才提到的矛盾點也是由這三個模塊之前的互相影響和制約（后面會詳細闡述）。

我們當初由于在設計時忽視了特定場景細節(jié)，以及生搬硬套了一些看起來很美很簡約的交互樣式，沒有處理好這三個模塊內部以及之間的關系，被用戶抱怨說不好用。

這篇文章就將「搜索」、「列表」、「操作」三塊問題進行分析和定位，盤點一下那些被淘汰掉的解決方案，給大家提供一份避坑指南。

注意，不存在“最好”的通用方案，只有應對具體需求“最合適”的解決方案。

一、搜索

1. 問題定位

搜索功能的主要問題是，條件特別多。

如果全部條件堆疊在屏幕上，會嚴重擠占列表的展示空間，使得首屏留給列表的空間所剩無幾；用戶在尋找具體搜索條件時，仿佛大海撈針，耗時費力。

造成搜索條件多的原因，一方面是由于數據信息量大，維度多。

在非精準搜索的場景下，少量的條件不足以篩選出特定內容；另外列表由多個職責權限的用戶共用，展示的是各權限下條件合集。

設計方案要能同時滿足下面3個需求：

• 用戶可以快速找到搜索條件——控制條件的數量；
• 能滿足搜索細致程度上的要求——搜索條件要充足；
• 將展示區(qū)域更多留給表格——避免搜索區(qū)域占用太多屏幕空間。

2. 淘汰

淘汰方案1：把搜索條件按照權限隱藏。

例如職責A的用戶展示搜索條件1、2、3、4，職責B的用戶搜索條件1、2、5、6；此方案確實能同時滿足①②③，但需要非常細致的配置工作；若組織架構發(fā)生變動，維護的工作量很難預估。

淘汰方案2：將搜索條件放置在列表左側。

這個方案試圖滿足需求③，希望保證首屏的展示主體是列表，但其實列表的橫向展示空間被擠占了；如果列表很寬，那么瀏覽的時候就需要頻繁的左右滑動；若是設備不支持左右滑動（不包含觸摸板），用戶只能頻繁拖動滾動條，想一想這體驗就很糟糕。

另外搜索區(qū)域的展示布局由塊面轉變?yōu)闂l狀，需要向下滾動（可能是多次）才能完整預覽所有條目，降低了搜索效率。

淘汰方案3：默認顯示少數搜索條件，全部條件轉移至彈窗內呈現。

這樣設計后，看起來也能滿足①②③——默認狀態(tài)下的列表確實清爽了不少。

但如果用戶需要多次切換搜索條件的組合方式時，需多次打開+關閉彈窗，大大增加點擊次數。

這種方案還需要注意一點：搜索條件和結果展示之間的具有強關聯性，需要在特定區(qū)域展示當前生效的搜索條件。

淘汰方案4：隱藏輸入框標題，使用占位符提示搜索內容。

某個同學提出這個方案，原因是標題在輸入框上方，隱藏標題可以使搜索條件排布的更緊密，給列表騰地方。

這種設計其實挺常見，但前提是輸入框數量極少，且為用戶所熟知；但后臺系統(tǒng)有些輸入框需要選擇“是”或“否”，選擇后用戶只憑“是”或“否”，可能回想不出這個選項對應的是什么搜索條件。

淘汰方案5：縮短輸入框列寬，從而增加每行的列數，減少行數。

這樣可以減少篩選項的行數，目的也是在首屏給列表騰地方。但填寫至輸入框的文本只能展示前面幾個字，影響預覽和理解。例如在地區(qū)的輸入框中只能顯示“浙江省杭州市…”無法看到“區(qū)”、“街道”等更詳細的重要信息。

3. 最終方案

最終方案：用戶可設置展示哪些選項，且通過賬號記錄設置結果。

這個方案較全面的解決了問題，每個用戶都可以根據自己的需求和習慣決定展示哪些選項，甚至選項排序；這個方案滿足了①②③的需求，但這個需要后端開發(fā)的支持。

One More Thing：如果后臺系統(tǒng)的數據加載時間比較久（不管是數據量大還是開發(fā)方式導致），盡量避免采用輸入/選擇后即執(zhí)行搜索的交互樣式；這可能導致每次輸入/選擇后用戶都需要被迫等待；如果選擇N個搜索條件，等待時間要乘以N。

作者：杜小杜，公眾號：能呆書房一整天

本文由 @杜小杜 原創(chuàng)發(fā)布于人人都是產品經理，未經許可，禁止轉載。

題圖來自?Unsplash，基于 CC0 協(xié)議