** 摘要:** 本文详述了管理后台列表页的设计原则和技巧, 对于新手有很大的学习价值.
无论是什么类型的产品, 几乎都会出现「列表页」, 前台部分的列表页设计技巧已经有很多的介绍了, 下面我以「电商系统」为例, 谈谈业务后台的列表页设计原则和技巧.
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 总结
列表页知识点就讲到这里了, 基本只要掌握了这些技巧, 设计一些常规的列表页已经是没有问题了, 如果遇到业务逻辑更加复杂的情况, 再根据情况判定, 但是万变不离其宗, 规则就是那么几条. 这里再总结一下:
业务列: 要克服「代码思维」, 放什么内容, 不是看我们有什么, 而是用户需要什么.
默认排列顺序: 先来的排后面, 后来的排前面.
操作: 宜少不宜多, 有需要才往上放.
[原文链接]
来源: https://juejin.im/post/5c00dc39e51d454342716909