后台列表设计避坑指南（下）编辑导语：列表页是后台界面的重要组成之一，上篇说了后台列表设计的“搜索”设计（详情见：后台列表设计避坑指南 上）；本篇继续讲剩下的两个部分的“坑”和必坑指南，我们一起来学习一下。 列表页是构成后台使用界面的重要组成之一，聚合了众多信息并提供操作入口。 区别于小而美的 C 端产品列表，后台系统的用户希望列表的内容又多又全面（表格），但在操作时又能支持快速定位（搜索，包含筛选）、准确处理（操作）。 这需求貌似有些矛盾，但在很多场景下，例如客服在接待客户时窗口时间极其短暂，既要全面猎取相关信息，又要快速应对解决客户问题；因此这需求不仅合理而且是刚需。 列表页由「搜索」、「表格」和「操作项」三大基本块组成。刚才提到的矛盾点也是由这三个模块之前的互相影响和制约（后面会详细阐述）。 我们当初由于在设计时忽视了特定场景细节，以及生搬硬套了一些看起来很美很简约的交互样式，没有处理好这三个模块内部以及之间的关系，被用户抱怨说不好用。 这篇文章就将「搜索」、「列表」、「操作」三块问题进行分析和定位，盘点一下那些被淘汰掉的解决方案，给大家提供一份避坑指南。 注意，不存在“最好”的通用方案，只有应对具体需求“最合适”的解决方案。 列表的主要问题依旧是内容太多带来的：表头字段太多，超出屏幕之外，左右滑动才能完整查看条目内容，导致眼动频繁，增加认知负担。条目太多，批量操作可能要多次翻页。 另外，其他潜在问题也会增加列表展示的复杂性，例如条目之间存在一定相关性——基于某份主合同后续签订几份补充合同（这里不讨论业务逻辑合理性）；那么简单根据签订时间点排序，就无法体现合同之间的关联关系。 在设计时，应着眼于避开内容太多导致的认知负担和操作成本。我们尝试了一些方法来减少信息噪音，抽象来说方法归为两个字——「藏」和「换」。 「藏」，就是隐藏低优先级信息，需要的时候才允许他们出现；「换」就是转换信息呈现的形式；下面我们一一展开。1. 方法一：藏 1）用户来配置展示哪些表头项 和之前提到的搜索区域配置功能类似，允许用户配置表头项，隐藏暂不需要的内容。 △ 设计者 Ashmita Bhattacharyya 2）使用展开行 适合主次层级对比强烈的列表。将重要度低的内容放入展开行内，这样可以避开横向滑动。 但假如同时查看多条展开行，需要多次点击展开。 △ 图片来自 Element UI3、树形数据 使用树形数据可以将...
