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