**摘要：** 本文详述了管理后台列表页的设计原则和技巧，对于新手有很大的学习价值。
无论是什么类型的产品，几乎都会出现「列表页」，前台部分的列表页设计技巧已经有很多的介绍了，下面我以「电商系统」为例，谈谈业务后台的列表页设计原则和技巧。
1 什么是「列表页」
1.1 「列表页」的概念
列表页是一些具有同种属性的内容的聚合。简单讲，在电商系统里面，展示所有商品或订单信息的或相似页面就是列表页。列表页的简单特征就是一行一条数据，和数据库或Excel表格的概念都很像。商品列表页就是一行一条商品信息，订单列表页就是一行一条订单信息。
1.2 「列表页」的类型
根据列表行数据的生成方式，可分为「主动型列表」和「被动型列表」，在阐述这两个概念之前，我们先来区分两种用户的身份，一种是「**使用后台的管理员用户**」，另一种是「**使用前台的终端用户**」，这两类人常常不是同一群人，我们都称之为「用户」，读者需要根据不同场景注意区分。
**主动型列表**：指的是列表中的数据是由管理员生成的，而非终端用户生成。例如「商品列表页」中的数据就是由管理员生成，与终端用户无关，用户在前台看到的商品信息均由后台编辑生成，用户无法变更商品信息。
**被动型列表**：指的是列表中的数据均是由终端用户生成的，而非管理员生成。例如「订单列表页」中的数据就是由终端用户生成，用户选择商品，提交订单，形成订单信息。
主动型列表和被动型列表虽然都是列表页，但是由于其内容的来源不同，所以在设定其产品逻辑方面有很大不同。
2 列表页设计原则
列表页有以下几条设计原则。实际上说原则也并不准确，因为产品设计并没有一个既定的标准，而是这些方法论是由行业前驱提出，并且经过了相关产品、市场的重重考验，被证明了是行之有效的。
第一条：**根据场景提供展示的业务列。**
第二条：**产品新数据行能够便捷地看到。**
第三条：**操作宜少不宜多。**
上面的几条原则可能比较抽象，难以理解，下面我来详细讲解。
3 列表页设计技巧
3.1 列表页构成元素
我们先来看看一个完整的列表页有哪些元素，主体是列表，包含一些对列表的操作，以及搜索。我们重点说明「列表」部分。
第一行为字段名，不出意外一般是：序号、业务列、操作。序号没什么好说的，就是一个1、2、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 总结
列表页知识点就讲到这里了，基本只要掌握了这些技巧，设计一些常规的列表页已经是没有问题了，如果遇到业务逻辑更加复杂的情况，再根据情况判定，但是万变不离其宗，规则就是那么几条。这里再总结一下：
业务列：要克服「代码思维」，放什么内容，不是看我们有什么，而是用户需要什么。
默认排列顺序：先来的排后面，后来的排前面。
操作：宜少不宜多，有需要才往上放。
