起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識以“跳體操”式思路，設計后臺列表頁
本文筆者將后臺列表頁設計分為三步：“跳”、“體”、“操”。謹記這三步?！疤奔磳Ш铰窐?，能讓用戶快速地查詢和跳走；“體”即管理訴求，能夠讓用戶掌握全局；“操”即功能操作，讓用戶有效率地操作。
我們在設計產品時，常常需要設計列表頁。
純C端產品里列表頁最常見的用處，是用來羅列多條信息記錄，幫助用戶找尋到關心項，并引導至后一級詳情頁去。
而當產品經理面對的是中后臺列表設計需求時，他最需要解決的用戶訴求還是這些嗎？他能通過什么樣的設計方法較好地解決這些訴求？
為讓討論更具有針對性，下文提及的列表指的都是后臺管理系統中，各操作路徑下的一級列表。
一、列表頁的定義
列表是用來重新組織業務內容的信息空間，這些業務內容往往具有同種屬性。
比如：在電商系統里，對象是商品管理，展示所有商品的聚合頁面就是列表頁。最基本的列表頁就是一行一條數據，是多個并行對象的線性展示。因為是產品設計的最基礎元素，市面上流行的前端框架里都少不了提供各類列表頁模板供項目團隊直接拿來套用。
二、列表分類
根據列表頁的用戶不同，常把列表劃分為兩類：主動型列表和被動型列表。
主要對應管理員和c端用戶兩類人：
- 主動型列表：由使用后臺的管理員用戶生成。比如商品列表頁中的數據由管理員（小二或店主）生成，與c端用戶無關。若列表還是一級頁面，還作為至各二級頁面的入口存在。在主動型列表中可二跳性和可操作性更被重視。
- 被動型列表：由使用產品的C端用戶生成。比如銷量監控后臺里的數據，就是由C端用戶生成，每一項都是用戶交易數據的疊加。在被動型列表中管理可視化更被重視
接下來就重點講講后臺列表頁的三個主要設計場景：
- 跳：列表是導航路標，用戶能快速查詢與跳走。
- 體：列表承載管理訴求，用戶能夠掌控全局。
- 操：列表用來功能操作，用戶效率全看操作。
三者連起來就是“跳體（ti）操”口訣。
跳：列表是導航路標，用戶能快速查詢與跳走
不比C端的刻意簡化，后臺管理系統的各個子模塊首頁往往是開門見山，直接將最核心內容列表化地鋪成在使用者面前。
但從信息結構上看，它是列表頁同時也是首頁，承載著分流訴求，是許多更具體功能的入口頁。
比如：這個旅游產品管理后臺的一級頁面，便是兼顧具體產品展示與跳轉分流兩種訴求。
（注：專有名詞“旅游產品”指的是一個具體的旅行套餐，如日本沖繩縣5日4晚私家團，該套餐就是一款旅游產品，是包含交通、住宿、飲食等資源的打包集合）
用戶操作同一后臺會劃分不同場景，上圖后臺中用戶可以通過列表頁導向至編輯、審核、上線流程，每個流程都是獨立的子模塊呈現。列表使用體驗的高低，在這里體現在檢索與跳轉的效率。
圍繞效率提升的產品設計切入點有3個：
篩選區：
篩選項一般與業務列項一一對應，只有具有篩選價值的列項才進入篩選區，且應使用頻率較高的字段放置在前，盡量避免放置在中間位置。
篩選區提供的是路徑漏斗能力，根據后臺操作角色的不同、目的的不同會有不同的篩選組合。
因此，一個比較高級的用法是：當進入列表時去判斷當前用戶角色，并默認出對應的篩選組合，來提升使用者的瀏覽效率——如審核員進入列表，默認為其審核狀態選中非已審核的其他項；半自助游的內容運營進入后臺自動為其選中產品類型為半自助游選項。
當某些篩選組合經常被選擇時，可以提供篩選的保存功能。
排序區：
列表排序通常有一默認邏輯，行業通用的版本是“產品新數據行能夠便捷地看到”——即按時間由近及遠排序。
也正因如此，默認排序在許多時候無法迎合用戶的查詢預期，便要加入輔助排列順序——即手動操作更改排序依據。
基礎的方法就是表頭的列項排序，比如：按照更新時間排序、數量排序。
這里要注意一點，往往容易錯誤地對純篩選項進行排序操作，這樣是不合理、挺傻的一種做法，例如：產品類型只有跟團游和半自助游兩種，但是還去使用排序。
因列表信息展示有限，排序項也可非事先出現在業務列中，當用戶手動選取后的業務列表有對應字段呼應即可，如：下方淘寶按銷量排序前不出現銷量（收貨量），但手動點選后會變更部分項做呼應。
聚合跳轉入口：
篩選和排序都是為了用戶更方便的找到對應業務列，然后進行后續操作或跳轉。
許多后臺被詬病笨重復雜的本質原因是：產品的結構問題和交互問題。
拋開結構復雜度不談，從交互上是能夠做一些額外設計來提高用戶對心理成本較高操作的信心的，比如：增加落地頁的快照預覽，這一般出現在前臺產品中落地頁以圖片為主的列表里，但體驗角度出發下，后臺同樣也能增加，清晰化使用者的心理預期。
預覽可以幫助用戶避免各種錯誤，使應用變得具有自我描述性。
梯：列表承載管理訴求，用戶能夠掌控全局
列表頁提供的另一種重要價值是上帝視角，用戶在列表頁的感覺就像是搭上一把梯子，站在更高的視角了解業務項的全貌。
列表頁首先是結構化的，不論各種旅游產品的描述里，有多少天花亂墜的賣點熱點，非結構化無法抽象的信息基本都不該出現在列表。在上例中，列表中各列項字段所呈現的，是圍繞旅游產品最重要的內容提煉。
其次，字段的選取應隨使用場景進行變化。字段出現的意義不是為了解釋產品，而是為了輔助決策。
同樣是旅游產品，如果是信息維護，列表項應該側重展示信息完成度和審核確認狀態；如果是產品訂單數據，列表項就應側重銷量、流水等數據指標；如果是業務場景較單一、不想把目錄結構復雜度做太高的情況，可以試圖將所有重要字段一并展示，但是要遵循“高聚落、小離散”的特點。
高聚落：指相關的重要字段間應保持相連，聚合展示，成為值得看一眼的視覺焦點。
小離散：指重要信息不能太多堆積在一起，否則會增加閱讀壓力，應該較平均且有空間感地分布各信息塊；彼此之間可以通過字體樣式完成區分。
舉個ZOL中關村產品庫的例子：
雖然這個產品庫是一個c端產品，但和許多電商后臺產品庫也很相似，樣式為內容服務。
沒人規定后臺列表界面只能長得像Excel那樣，一列顯示一個字段。 字段少能描述清楚，則做成excel可更簡潔；若描述不清楚，那就需要通過合理的交互操作和視覺排版來容納下復雜信息展示。
ZOL產品庫這么組織它的信息展示：
- 提煉：數碼產品是精密設備，隨時可以用100個參數描述一臺手機，但用戶在這里只應該閱讀到其最關心的前幾項內容。
- 聚類：參數是對產品多個角度的描述，相關內容應聚合一起展示。zol分了商品描述區、參數區、用戶評論區、價格區四個區間來定義出一臺手機產品
- 排序：視覺布局上應遵循眼動線路徑，也就是用戶掃面頁面的視線移動順序應和用戶理解對象的邏輯一致。商品描述和參數定義出手機的客觀硬件輪廓，用戶評價則是市場對手機的主觀反饋，最后在“怎樣的硬件得到大概怎樣的口碑”后展示其產品定價（因為zol的產品庫的根本目的還是導購）
提煉-聚類-排序方法可以用在各種列表的信息組織思路里，在信息易讀基礎上，實際工作中還會對它有橫向管理的需求，以數據可視化為主。
有2個可視化區：
- 篩選區與列表區之間：以統計性目的為主，因區域空間大可容納多個數字，甚至數據圖譜。
- 列表區（+Hover懸浮彈窗）：列表空間充足時，可把數據曲線放置在列項內；空間有限時，可以以概括數字+懸浮詳情彈窗的交互方式展示數據詳情，達到預覽與管理目的。
操：列表用來功能操作，用戶效率全看操作
后臺列表的操作場景較c端更多，也更重度。列表頁既是分流入口、管理后臺，也是操作后臺。
從最基礎的增刪改，到列項拖動這類交互性功能，幾乎都已抽象進各類前端開發工具包里（如Bootstrap）。但往往越常識的操作功能，需要關注的體驗點越多。
新增：
新增操作比較常規，主要的設計點在于交互選擇上。
根據業務列的復雜度，由簡至繁可以選擇“直接添加在列項”、“打開彈窗錄入”與“跳頁編輯表單”三種。
刪除：
刪除操作在后臺設計中是很危險的存在。
業務列關聯數據庫，關聯代碼邏輯，如果是一個已被調用中的業務列數據被誤刪，輕則導致數據丟失，重則導致系統崩潰。
因此，不論前臺展示上寫的是刪除還是其他什么操作，本質上提供的是“下線”與“隱藏”操作——即邏輯刪除，而非物理刪除。物理刪除值得是文件存儲所用到的磁存儲區域被真正的擦出或者清零，這樣刪除的文件基本沒法恢復。
修改：
以主動型產品列表為例：修改產品配置往往和新建操作高度相似，只不過會加載上默認已配置項。一般把修改寫作“編輯”，理論上只是編輯已有的業務項配置，但也需要非常謹慎地對待，有兩點原因。
第一：編輯項可能正處于激活上線狀態，意味著編輯保存后直接會對線上的數據或活動產生直接影響， 這在后臺業務流程中是被視為非常危險的。一般編輯保存后需要自動關聯下線重走審核流動作，保障線上穩定。
第二：編輯不適用于同一活動不同周期的場景。
以節日活動為例：在兩個時間段里做同一種“兩件7折”活動，不能讓新活動只是在老活動基礎上做一下編輯修改起止時間就結束，因為這個老活動可能關聯了很多數據和商品，需要保證這條記錄是不動的。
編輯操作本質上是一個快速操作，是刪除舊記錄與新增內容與原來一樣，在修改部分的兩個動作組成。一旦與線上邏輯管理的被編輯，原記錄不在了會引發許多麻煩，牽一發動全身。
對操作后臺的用戶而言，需要盡量優化操作邏輯或增加注釋提醒，以幫助新用戶學得快、老用戶不犯錯。
結合《界面設計模式》一書，有如下幾類大類操作模式：
基本動作模式：
- 按鈕組：是把相關的動作組織成一族按鈕，彼此水平或者垂直對齊。這一組按鈕應當擁有相同的視覺設計，當然更重要的可區別對待（如新增按鈕）
- 懸浮工具：上文已經提到，懸浮的閃現即鼠標掠過是會自動加載顯示，內容可以是文字、數據圖片或下一級動作按鈕組合。懸浮工具可以讓整個界面保持干凈整潔，但缺點在于并非一眼可見
進階動作模式：
- 批量：對于多個業務項進行多選并一同完成一項動作。合理的按鈕組設計下，批量操作與單體操作可以共用同一按鈕。
- 分組：若業務項是樹級結構，或需對業務項進行分組管理時，可通過在列表基礎上疊加子列表實現功能訴求。
- 撤銷：為用戶提供一種方式撤銷所執行的一系列操作，是增加用戶安全感的一種做法。
界面設計屬于用戶體驗的結構層，關注體驗的同時一定不能忘記業務邏輯本身。
不論使用什么樣的設計技巧進行列表處理，效率相比其他要素是更應追求的。
我見過無比復雜、疊加多個流程的某大型互聯網公司后臺訂單系統，但據其訂單維護人員評價，一旦上手后發現邏輯清晰，操作高效，如同路由一般聯通客服、財務等多個工作流后臺。
五年沒有優化過界面。所以后臺管理列表頁必須是在運作高效的情況下再去增加體驗、降低操作門檻。而不是“供給思維”，結構怎么合理就一定怎么布局，商品有什么參數就鋪什么，讓用戶自己感受。
作者：王子，原58安居客/攜程用戶產品。
本文由 @王子 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自unsplash，基于CC0協議
導語部分應該是「跳走」，而不是「逃走」。小編領會錯了原作者的意思。一字之差，意思大變。。。