「後臺列表頁設計原則和技巧」

**摘要：** 本文詳述了管理後臺列表頁的設計原則和技巧，對於新手有很大的學習價值。

不管是什麼類型的產品，幾乎都會出現「列表頁」，前臺部分的列表頁設計技巧已經有不少的介紹了，下面我以「電商系統」爲例，談談業務後臺的列表頁設計原則和技巧。

1 什麼是「列表頁」

1.1 「列表頁」的概念

列表頁是一些具備同種屬性的內容的聚合。簡單講，在電商系統裏面，展現全部商品或訂單信息的或類似頁面就是列表頁。列表頁的簡單特徵就是一行一條數據，和數據庫或Excel表格的概念都很像。商品列表頁就是一行一條商品信息，訂單列表頁就是一行一條訂單信息。

1.2 「列表頁」的類型

根據列表行數據的生成方式，可分爲「主動型列表」和「被動型列表」，在闡述這兩個概念以前，咱們先來區分兩種用戶的身份，一種是「**使用後臺的管理員用戶**」，另外一種是「**使用前臺的終端用戶**」，這兩類人經常不是同一羣人，咱們都稱之爲「用戶」，讀者須要根據不一樣場景注意區分。

**主動型列表**：指的是列表中的數據是由管理員生成的，而非終端用戶生成。例如「商品列表頁」中的數據就是由管理員生成，與終端用戶無關，用戶在前臺看到的商品信息均由後臺編輯生成，用戶沒法變動商品信息。

**被動型列表**：指的是列表中的數據均是由終端用戶生成的，而非管理員生成。例如「訂單列表頁」中的數據就是由終端用戶生成，用戶選擇商品，提交訂單，造成訂單信息。

主動型列表和被動型列表雖然都是列表頁，可是因爲其內容的來源不一樣，因此在設定其產品邏輯方面有很大不一樣。

2 列表頁設計原則

列表頁有如下幾條設計原則。實際上說原則也並不許確，由於產品設計並無一個既定的標準，而是這些方法論是由行業前驅提出，而且通過了相關產品、市場的重重考驗，被證實了是行之有效的。

第一條：**根據場景提供展現的業務列。**

第二條：**產品新數據行可以便捷地看到。**

第三條：**操做宜少不宜多。**

上面的幾條原則可能比較抽象，難以理解，下面我來詳細講解。

3 列表頁設計技巧

3.1 列表頁構成元素

咱們先來看看一個完整的列表頁有哪些元素，主體是列表，包含一些對列表的操做，以及搜索。咱們重點說明「列表」部分。

第一行爲字段名，不出意外通常是：序號、業務列、操做。序號沒什麼好說的，就是一個一、二、3…的展現，用途只是用於輔助「行」的顯示，無任何的業務邏輯和附加含義。業務列是列表的主要部分，操做指的是對該一行的數據的操做，常見的有：編輯、刪除等等。

主動型列表還有「新增行」操做（對應不一樣業務名稱都不一樣，例如商品列表頁就是「新增商品」），通常被動型列表無「新增行」操做。

3.2 業務列

業務列中須要展現哪些元素呢？單行記錄可能包含多個數據，哪些須要放上去，哪些不須要放上去，哪些須要顯示可是隻須要再深一層顯示，怎麼斷定？

依據就是上述設計原則的第一條——根據場景提供展現的業務列。首先你須要定義這個頁面的用途是什麼，根據設定的用途去展現相應的元素，同時更重要的是，要了解用戶真正須要的是什麼。須要展現什麼內容，不是看咱們有什麼，而是看用戶須要什麼。仍是以「商品列表頁」爲例，這個頁面的用途就是管理商品的（實際上這個頁面自己就叫「商品管理」頁），後臺新增、編輯商品，前臺展現，供用戶購買。一個商品包含如下元素：商品名稱、商品描述、庫存、價格、展現圖、規格、詳情介紹等，顯示這些內容是很難所有都放到列表頁的「業務列」中的，那如何取捨呢？咱們將這個列表頁的用途定位爲：輔助用戶快速找到對應的商品，進行編輯或其餘操做。若是是這個定位的話，那麼只要一個商品名稱就能夠了。

實際上，在業務列中呈現的元素不只僅是「商品名稱」，咱們這裏再引入一個新的概念：主要元素和補充元素（輔助元素）。在這裏「商品名稱」就是主要元素，主要元素和補充元素的區別是即便只保留主要元素，也不影響這個頁面功能的實現。在「商品管理頁」中常見的補充元素還有：封面圖——輔助經過看圖直接找到對應商品，價格，銷量（被動產生數據），庫存等。

咱們在設計頁面時，必定要肯定「主」和「次」，不要一鍋粥的全往上擠。必定要克服一種「代碼思惟」，這種思惟的典型想法就是「這個數據個人數據庫有存，可能也有用戶想要看，爲何不放上去？」，回答仍是「定位」！

咱們再來說講「訂單列表頁」，通常名稱也叫「訂單管理頁」。（可能不少讀者會疑惑，這些列表頁爲何在取名的時候都不帶列表的，關於後臺功能菜單的取名，能夠看個人這篇文章《後臺菜單命名小技巧》）在設置業務列的時候，第一步仍是明確這個頁面的定義和用途，想一想用戶在何時會用到這個頁面，再簡單講，思考「在什麼狀況下，用戶出於什麼目的會主動打開這個頁面」，這個就是找準「用途」的技巧。用途無非就是下面這些：

（1）和買家協商一致，去後臺改價。

（2）看看有什麼新訂單，而後去操做發貨。

（3）退款操做

明確了用途，以後再把對應的業務列往上放就能夠了。

關於「頁面用途」，這裏再講幾句，說說不少新手很容易犯的錯誤，就是「想太多」。會去思考「萬一用戶不當心點到這個頁面，忽然想看某個數據，看不到怎麼辦？」又或者是「若是咱們把這個數據也放上去，這樣若是有用戶想看，就能夠看了」。錯誤太多，不少頗有趣，後面再整一期講講這些常見的「想固然」的想法吧。

還須要特別注意的是，咱們將「用戶須要什麼」的時候，這裏的「用戶」不是指具體的某我的，而是一羣人，準確的講，是帶「佔比數」的一羣人，例如90%的用戶傾向於A方案，10%的用戶傾向於B方案，而A和B方案只能二選一的狀況下，咱們只能選擇A方案，而不是說只要存在一個用戶須要某個功能，咱們就必須往上作。

3.3 默認列表順序

默認排列順序算是一個不算重點的重點，一是由於它重要，很是重要，二是這個技巧特別簡單，幾乎不須要深刻思考。原則中第二條：「產品新數據行可以便捷地看到。」講的就是這裏的默認列表順序。那麼什麼是列表順序呢？

列表一行一條數據，老是須要一個明確的規則去肯定它的排列順序，而不是隨機的，哪條記錄排在前面，哪條記錄排在後面，都是須要制定必定的規則的。那麼怎樣才能讓「產品新數據可以便捷地看到」呢？技巧就是根據所在列表的新數據放在第一，越新的數據排在越前面。再結合「主動型列表」和「被動型列表」的特徵這個技巧還須要必定的優化升級。咱們結合具體例子講解。

商品列表頁，這是典型的主動型列表，全部的數據行都是用管理員用戶主動生成的。首先第一條是毫無爭議的，新增的商品默認排在第一行。還有一個方面是，編輯保存的商品，也是須要從後往前拉的。不然排在後幾頁的商品，編輯後就沒有任何變化。因此將二者組合，默認列表排序規則就是「商品保存時間降序排列」（保存不區分新增仍是編輯）。

不少人可能會想到，商品在前臺的展現順序問題，因此引入「手動排序的序號」概念，這實際上是徹底多餘的，前臺商品的排序最好和後臺排序脫軌，遵循一套排序規則後期維護會很是麻煩。（這一點以後的文章會細講）

訂單列表頁，這是典型的被動型列表，全部的數據都是由終端用戶生成的。因此默認排序規則很簡單，就是「生成訂單的時間降序」排列。

還有一個算是小難點，仍是以「訂單列表頁」舉例，訂單有多種狀態，咱們會在訂單列表頁設立標籤欄快捷查詢，那麼如何制定各標籤欄的默認排列順序呢？其實仍是遵循同樣的道理，就是進入該標籤欄的時間降序。例如訂單的狀態有「未支付」、「已支付」、「已發貨」、「已完成」等等。未支付狀態指的是，訂單已生成，可是用戶未付款，那麼該標籤欄下列表的默認排列順序就是「生成訂單的時間降序」。已支付狀態指的是，用戶已經付款，可是商家尚未發貨，那麼該標籤欄下列表的默認排列順序就是「付款時間降序」。已發貨狀態指的是商家完成發貨，那麼該標籤欄下列表的默認排列順序就是「發貨時間降序」。已完成狀態指的是用戶手動確認收貨或者系統自動確認收貨，那麼該標籤欄下列表的默認排列順序就是「確認收貨時間降序」。

簡單來講，只要記住一點就沒問題了，先進來的排後面，後進來的排前面。

3.4 輔助排列順序

默認排列順序和輔助排列順序的區別是，默認就是直接進入該頁面，不須要進行任何操做就直接展現的，輔助排列順序是須要用戶手動操做，變動排列順序，輔助排列順序通常設定在特定業務列上，點擊可變動按此規則降序或升序排列。設定輔助排列順序的技巧和前面提到的「業務列」同樣，仍是明確頁面定義和用途，這裏不贅述了。例如商品列表頁常見的輔助排列順序有按銷量、庫存、價格排列等。

3.5 操做

常見的操做有：編輯、排序、刪除等等。根據不一樣業務功能的列表頁，操做區按鈕區別很大。下面講講幾個常見的功能。

3.5.1 編輯

對於主動型列表，不少人會情不自禁地加上「編輯」操做，很大程度上這是沒錯的，可是仔細思考，這裏真的須要「編輯」嗎？

編輯操做實際上一條便捷操做，除了保留原有數據外，至關於刪除原有記錄，再新增內容和原來同樣，再修改內容，省去了前兩步。多數列表存在編輯是沒問題的，可是一些會產生不少跟該條記錄強綁定關係的列表，最好編輯和刪除兩個功能都不要有。仍是以電商爲例，遇到節日或者其餘活動，通常會進行促銷打折活動，後臺「活動列表頁」會新增一條活動信息，若是這個活動關聯不少數據，那麼就須要保證這條記錄是不動的，一旦編輯或刪除，原紀錄不在了，牽一髮而動全身，會引起太多麻煩。這時候就不要問「用戶只是想把上次那個活動再改一下弄個新活動，還要新增多麻煩啊，編輯改一下多方便啊，這樣不行嗎？有個用戶就強烈須要。」這種傻問題了。

3.5.2 排序

有些業務邏輯很是簡單的內容，先後臺的展現順序是一致的，這時候就須要排序功能，先後臺同步變更。

3.5.3 刪除

刪除操做是一個比較敏感的操做，若是不是特別必要，儘可能不要放刪除功能。

3.5.4 搜索

是否須要搜索功能，是根據預期產生的數據行數決定了，若是在30條之內，則儘可能別上，30條以上酌情上。

4 總結

列表頁知識點就講到這裏了，基本只要掌握了這些技巧，設計一些常規的列表頁已是沒有問題了，若是遇到業務邏輯更加複雜的狀況，再根據狀況斷定，可是萬變不離其宗，規則就是那麼幾條。這裏再總結一下：

業務列：要克服「代碼思惟」，放什麼內容，不是看咱們有什麼，而是用戶須要什麼。

默認排列順序：先來的排後面，後來的排前面。

操做：宜少不宜多，有須要才往上放。

【原文連接】