「后台列表页设计原则和技巧」

**摘要:** 本文详述了管理后台列表页的设计原则和技巧,对于新手有很大的学习价值。

无论是什么类型的产品,几乎都会出现「列表页」,前台部分的列表页设计技巧已经有很多的介绍了,下面我以「电商系统」为例,谈谈业务后台的列表页设计原则和技巧。

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 总结

列表页知识点就讲到这里了,基本只要掌握了这些技巧,设计一些常规的列表页已经是没有问题了,如果遇到业务逻辑更加复杂的情况,再根据情况判定,但是万变不离其宗,规则就是那么几条。这里再总结一下:

业务列:要克服「代码思维」,放什么内容,不是看我们有什么,而是用户需要什么。

默认排列顺序:先来的排后面,后来的排前面。

操作:宜少不宜多,有需要才往上放。

发表评论