起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識一文詳解B端產品web列表設計
列表是一種數據項構成的有限序列，即按照一定的線性順序，排列而成的數據項的集合，在這種數據結構上進行的基本操作包括對元素的的查找、插入和刪除。
一直設計列表都是從腦子里面固有的慣性出發，比如：之前的列表怎么設計的，新列表也這么設計好了，對自己的決策很少產生懷疑或思考，畢竟感覺是個簡單的列表。
后來某次評審被領導點撥：這個篩選項做成那樣是不是更好，列表那樣展示是不是很好，一臉羞愧，發現自身存在很多問題，比如無法確認哪些元素該有，哪些元素該沒有，想到一個放一個，純屬憑感覺自由發揮，自此決心要研究下列表頁設計。
看了很多別人寫的文章，有一定的收獲，發現列表頁設計看著簡單，其實也有大學問，找時間梳理了下，希望對大家都有幫助 （基本覆蓋了設計列表時可能遇到的問題）。
什么是列表？
這里是百度百科對“列表”的解釋：列表是一種數據項構成的有限序列，即按照一定的線性順序，排列而成的數據項的集合，在這種數據結構上進行的基本操作包括對元素的的查找、插入和刪除。
列表設計的原則
雖然列表設計沒有統一的方法論，但是設計任何產品的時候，最好心里把握一定的原則，這樣能保證有個主心骨，也不至于走偏，基于多年設計經驗，我總結了下列表設計需要遵循的三大原則（對所有列表適用）：
- 基于業務：任何產品都是基于業務、基于場景而產生的，并不是空想出來的，這是大前提。
- 追求效率：效率是指用戶能夠快速地找到自己想要的數據。
- 輔助決策：保證列表所展示的每項信息對于用戶而言都是有用的，能夠起到幫助用戶決策的作用。
B端產品web列表應如何設計
下面具體講講B端產品web列表應該如何設計，主要從其包括的幾個模塊（篩選、排序、列表、操作項、分頁）分別說明：
1. 篩選
提取哪些內容作為篩選條件：
（1）能定位到用戶想要的數據的（不一定需要ID）
即通過篩選條件，用戶能篩選到自己想要的數據，這里要特別說明的是，很多產品設計列表的時候可能會習慣性地放一個ID作為篩選條件，但其實不是所有場景下用戶都會使用ID搜索列表。
天貓商家可能需要通過商品ID去搜索商品，那是因為商家有精確找到某條商品數據的需求，且這個需求只能通過商品ID的搜索滿足（商品名稱很大概率上篩選出來的結果是多條）；但是像對于人才庫（見下圖），一般用戶通過姓名、手機號、郵箱就能定位某條數據，ID就沒有作為篩選條件存在的必要了。
人才庫
（2）符合用戶真實需求場景的
當前列表所在的表單可能包括的字段有很多，不是每一個字段項都需要拿來作篩選條件，評估能作為篩選條件的標準即為：符合用戶真實需求場景，就是說用戶真實場景下會使用這些條件去搜尋自己想要的數據，用戶在當前列表用不到的可以不作為篩選條件，天貓商家后臺“已賣出的寶貝”篩選條件中并沒有價格區間，商家篩選價格區間應該是在客戶運營的時候，而不是在訂單列表，所以此處無需提供價格區間篩選條件。
天貓>已賣出的寶貝
各篩選條件的位置應如何設計？
（1）按用戶使用的頻率由高到低呈現
按頻率呈現的好處在于：用戶頻繁使用的篩選條件能一眼找到。
（2）符合用戶使用的習慣（從上到下，從左到右）
篩選條件過多時（個人覺得超過兩行），像上面的“天貓>已賣出的寶貝”遵循先從上到下，再從左到右的擺放順序，但是如果篩選條件≤兩行時，可以遵循先從左到右，再從上到下的順序，比較符合肉眼查找的順序，如上圖的“人才庫”。
篩選分類：
（1）文本類（名稱或ID等）
這是最常用的一種篩選條件，比如商品名稱、商品ID等。名稱類的一般支持模糊查詢，ID類的一般支持精確查詢。文本輸入框內最好有提示文案，普通的如“請輸入商品名稱”，集合多種查詢條件的如“姓名/手機號/郵箱/標簽”，一來方便用戶輸入時再次確認當前要輸入的內容，二來提醒當前輸入框支持輸入的內容，三來提醒用戶需要的操作（輸入/選擇）。最后，需要提供回車執行搜索功能。
（2）固定選項類
一般為下拉選項，選項過少時，可平鋪展開（如下圖，可將處理狀態直接平鋪展開），平鋪展開的好處是用戶能直接看到選項內容，方便用戶識別選項，且提高了用戶篩選的效率（節省了篩選操作）。
此類選項一般不提供“勾選即執行搜索”功能，理由：用戶可能還需要綜合其他篩選條件一起查詢，執行搜索的過程（動畫或加載時長）可能分散用戶精力或打斷用戶剛才的輸入。
天貓>異常包裹列表（原）
天貓>異常包裹列表（優化后）
（3）時間類
時間類有兩個特殊的地方：
1）存在多個時間篩選條件的情況時，需區分好彼此之間的關系（互斥或可共存）。
沒有找到合適的案例，畫了下大概的樣式，為互斥關系時可以采用如下的樣式，為可共存關系時，直接將多個時間篩選條件列舉出來即可 （不過一般可共存的關系是可以滿足互斥的搜索場景的，不確定真實有沒有僅使用互斥場景的）。
時間相互之間為互斥關系
2）提供快捷選項（根據需求場景確定要不要提供）
時間類的快捷選項包括：昨天、最近七天、最近30天、本年等等，一般報表類的會使用比較多，像下圖的生意參謀，本質上是提高用戶查找數據的效率，還是那句話，具體要不要提供還是要看真實的場景需不需要。
生意參謀
（4）快捷篩選類
一般會提供幾個常用的快捷選項方便用戶直接篩選出想要的結果/過濾不想要的結果，如“天貓>已賣出的寶貝”提供過濾已關閉訂單的快捷選項。
用戶使用此類選項的場景一般是在正常篩選條件之后，也就是說它是作為一個輔助選項，因此快捷選項點擊后需要同時執行搜索操作，查出用戶想要的結果。
具體是否需要提供快捷篩選，還是看實際場景是否需要。
天貓>已賣出的寶貝
（5）篩選tab
我們經?？吹搅斜砩嫌刑峁﹖ab篩選的功能，如“待付款、待發貨、退款中”等，這些tab位置有可能是在正常篩選條件之下，有可能是在正常篩選條件之上，那么什么時候在上，什么時候在下呢？
基于業務，基于場景。
tab在上的情況：
用戶需要一眼能看到所有的概況并且很明確自己想要查找的目標在哪個tab（想查找數據時，會直接到對應tab下查找，不用思考）下時，tab在上，這個時間只需要告訴用戶查詢出來多少最終結果即可，如天貓>寶貝管理。
天貓>寶貝管理
tab在下的情況：
需要看到查詢的結果在各tab下的分布情況時，tab在下，如2號人事>候選人篩選。
2號人事>候選人篩選
tab上是否要展示當前tab下的項目數：
看用戶對當前列表是否有按數字匯總的需求，像待辦事項或想知道概況這種需要提供數字匯總結果，比如人事需要知道目前正式員工，試用員工多少；買家需要知道當前待付款的有多少，待發貨的有多少。
其他：
- 篩選條件什么情況下需要提供保存功能：可能反復多次會使用多個相同篩選條件組合起來查找數據，該種情況下需要保存篩選條件，如人才庫的搜索；
- 篩選條件什么情況下需要提供重置功能：大多數情況下需要通過多種條件（個人覺得≥２）匹配才能找到自己想要的結果，人才庫也是個很好的例子；
- 篩選條件什么情況下需要隱藏部分條件：篩選條件過多（超過兩行），且部分條件很大概率情況下用不到，展示起來反而干擾大多數用戶搜尋其他篩選條件，可以將大概率用不到的條件先收起到，用戶需要時自行展開。
- 篩選條件什么情況下需要問號提示：篩選文案會讓人產生疑問時需要提示問號解釋說明。
京東>商品管理
2. 排序
哪些字段需要提供排序功能：需結合具體場景具體分析，需理解排序背后的用戶場景。一般來說，數字（如價格、銷量等）、權重（商品列表的綜合排序等）、時間（創建時間、入職時間等）這類字段需要提供排序功能，提供正序、倒序排序功能即可。
默認排序：需考慮用戶第一次進入列表的初始化狀態，保證用戶剛進入頁面時大概率能直接看到自己想看的東西（畢竟篩選只是輔助功能）。
3. 列表
提取哪些內容展示在列表：
- 首先明確當前列表所要描述的主體，如商品、活動規則、訂單；
- 其次提取最能簡單描述這個主體的字段，如商品縮略圖、商品名稱、商品價格….
- 最后提取用戶期望從當前列表能直接看到的信息（大概率）。
各字段的位置應如何設計：
- 編號一般前置（不一定所有編號都需要展示，具體需要看編號有無業務使用場景）；
- 能直接代表所要描述的主體的字段前置，如商品名稱、活動規則名稱；
- 特殊的，比如優先級、類型或狀態（可以采用圖標表示的）可以前置，方便一目了然，如JIRA>Backlog；
JIRA>Backlog
- 按用戶關注度由高到低呈現；
- 符合常規思維邏輯。
即符合正常思考或看事物的邏輯，以“天貓>店鋪寶規則列表”為例，活動編號、活動名稱點據1、2列后，緊接著是“活動詳情”，“活動詳情”可以算作是對“活動名稱”的補充，“活動詳情”+“活動名稱”結合可以使用戶大概了解這個活動是干嘛的了，再接著是這個活動哪天開始，哪天結束（活動時間），當前活動的狀態（狀態與活動時間是相對應的，在活動時間之后比較順理成章）。
天貓>店鋪寶規則列表
一頁展示多少條合適：
常規的像excel一樣的列表，一頁最好能在一屏展示，避免用戶來回上下滾動，比如固定為展示10條；
特殊的像訂單列表，兩三個訂單可能就能占據一屏，而且每條的高度不確定，這種情況下不適用以上規則，一頁可能展示10條/20條，都可以。
列表可以有哪些展示形式：
- excel樣式：設計列表時一般都會不自覺地向excel的樣式靠攏，這的確也是大多數列表會采用的樣式；
- 信息聚攏式：沒有人規定一列僅能展示一個信息，因此為了高效地利用列表，也為了信息集中化，方便用戶集中瀏覽，可以將相同的信息聚攏，將列表靈活化，如商品列表、訂單列表。
天貓>訂單列表
- 擬物式：如銀行卡列表的設計，相較于普通的excel樣式，設計成微信>銀行卡（手機端）的樣式會更直觀，當然Web端也可以采用類似的設計。
列表需要展示的字段太多怎么辦？
- 上面提到的信息聚攏是一種辦法；
- 提供自定義表頭功能（僅限用戶可能需要的字段很多的情況），默認展示用戶關注度最高的字段內容，如2號人事>花名冊；
2號人事>花名冊（未選擇表頭）
2號人事>花名冊（選擇表頭）
- 提供左右滾動功能，左右滾動時，需要固定列表最前面的幾列，方便用戶識別當前信息歸屬哪個主體。
其他：列表上下滾動時，標題欄需要固定，方便用戶識別某個內容的含義。
4. 操作項
哪些操作項應該放在列表：
通過列表所能提供的信息就能做的決策性操作，如修改商品名稱、修改商品庫存，大多數操作屬于這一類；相關信息的鏈接功能，如賣家通過點擊旺旺昵稱可直接與買家對話；點擊【詳情】可直接查看對應信息的詳細信息。
操作項的位置應如何設計：
- 一般在最后一列操作項；
- 與某列相關的操作可直接放置在該列中，目標清晰，節省操作列的位置，也方便用戶操作，不用到最后一列找操作項，如上下架，添加備注。
淘寶>異常包裹管理
操作項太多怎么辦：
一般操作列放兩個常用的操作出來，同行或同列展示，剩余的操作（特別是敏感性操作，如刪除）隱藏起來，點擊【更多】進行展示。
淘寶>寶貝管理
批量操作：
- 是否所有的單個操作都需要提供批量操作？不一定，看真實業務場景需要。
- 有了批量操作是否可以不提供單個操作？不沖突，畢竟批量操作還多一個勾選操作。
5. 分頁
分頁需要展示哪些信息：
- 當前結果頁的結果總條數；
- 當前頁所在的位置；
- 快捷跳轉至某頁的功能。
總結
不是每一個列表都會覆蓋以上說的所有的東西，做產品不能簡單的拿來主義，要思考別人那么做背后的意義以及自己產品的真實業務場景，任何東西都是適合自己的就是最好的。
以上，講的不一定是對的。
作者：青檸，微信公眾號：一只進化中的產品汪（pm_move_forward），歡迎交流。
本文由 @青檸 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
贊，很清晰實用，提到的很多點剛好在上個月的新功能中也用到了
作者介紹的很詳細，有收獲
固定選項里第二段是不是描述不太準確啊，應該是一般不提供“勾選即執行搜索”功能吧，這樣才和后面的理由對應啊
敬認真的讀者
比較實用
詳細，點贊
學習了，總結的非常棒。有兩點期望有機會探討或分享：
1.數據導入及導出
2.查看詳情按鈕應該放在操作欄中，還是信息列某個標題中。比如人才庫簡歷詳情。點擊人名進入詳情和點擊查看詳情按鈕進入詳情的區別
受益匪淺 十分感謝
挺好
條理清晰且實用
不錯
很棒的分享，贊！
另，同學有沒有關于數據批量導入導出的心得呀，也屬于列表上下游的東西，期待分享。
干貨 正在糾結后臺相關設計 感謝分享
怎么能看到天貓和京東的后臺呢？
這是WEB版商家端（B端），自己開個店鋪就可以看了。
占公司光，公司開店鋪了
感謝~~有得~~
??
操作太多是否可以考慮使用右鍵菜單
Web端不實用，很多用戶根本不知道，因為按照操作習慣，右鍵出現的菜單會是網頁的選項，而不是B端選項
很好的分享
謝謝支持喲
看到了用戶體驗
是夸獎嘛