2023年后台列表设计避坑指南（上）

后台列表设计避坑指南（上）列表页是构成后台使用界面的重要组成之一，聚合了众多信息并供应操作入口。

区分于小而美的C端产品列表，后台系统的用户盼望列表的内容又多又全面（表格），但在操作时又能支持快速定位（搜寻，包含筛选）、精确     处理（操作）。

这需求貌似有些冲突，但在许多场景下，例如：客服在接待客户时窗口时间极其短暂，既要全面猎取相关信息，又要快速应对解决客户问题；因此这需求不仅合理而且是刚需。

列表页由「搜寻」、「表格」和「操作项」三大基本块组成。

刚才提到的冲突点也是由这三个模块之前的相互影响和制约（后面会具体阐述）。

我们当时由于在设计时忽视了特定场景细节，以及生搬硬套了一些看起来很美很简约的交互样式，没有处理好这三个模块内部以及之间的关系，被用户埋怨说不好用。

这篇文章就将「搜寻」、「列表」、「操作」三块问题进行分析和定位，盘点一下那些被淘汰掉的解决方案，给大家供应一份避坑指南。

留意，不存在“最好”的通用方案，只有应对详细需求“最合适”的解决方案。

一、搜寻

1.问题定位

搜寻功能的主要问题是，条件特殊多。

假如全部条件堆叠在屏幕上，会严峻挤占列表的展现空间，使得首屏留给列表的空间所剩无几；用户在查找详细搜寻条件时，仿佛大海捞针，耗时费劲。

造成搜寻条件多的缘由，一方面是由于数据信息量大，维度多。

在非精准搜寻的场景下，少量的条件不足以筛选出特定内容；另外列表由多个职责权限的用户共用，展现的是各权限下条件合集。

设计方案要能同时满意下面3个需求：

用户可以快速找到搜寻条件——掌握条件的数量；能满意搜寻细致程度上的要求——搜寻条件要充分；将展现区域更多留给表格——避开搜寻区域占用太多屏幕空间。2.淘汰

淘汰方案1：把搜寻条件根据权限隐蔽。

例如职责A的用户展现搜寻条件1、2、3、4，职责B的用户搜寻条件1、2、5、6；此方案的确能同时满意①②③，但需要特别细致的配置工作；若组织架构发生变动，维护的工作量很难预估。

淘汰方案2：将搜寻条件放置在列表左侧。

这个方案试图满意需求③，盼望保证首屏的展现主体是列表，但其实列表的横向展现空间被挤占了；假如列表很宽，那么扫瞄的时候就需要频繁的左右滑动；若是设备不支持左右滑动（不包含触摸板），用户只能频繁拖动滚动条，想一想这体验就很糟糕。

另外搜寻区域的展现布局由块面转变为条状，需要向下滚动（可能是多次）才能完整预览全部条目，降低了搜寻效率。

淘汰方案3：默认显示少数搜寻条件，全部条件转移至弹窗内呈现。

这样设计后，看起来也能满意①②③——默认状态下的列表的确清爽了不少。

但假如用户需要多次切换搜寻条件的组合方式时，需多次打开+关闭弹窗，大大增加点击次数。

这种方案还需要留意一点：搜寻条件和结果展现之间的具有强关联性，需要在特定区域展现当前生效的搜寻条件。

淘汰方案4：隐蔽输入框标题，使用占位符提示搜寻内容。

某个同学提出这个方案，缘由是标题在输入框上方，隐蔽标题可以使搜寻条件排布的更紧密，给列表腾地方。

这种设计其实挺常见，但前提是输入框数量极少，且为用户所熟知；但后台系统有些输入框需要选择“是”或“否”，选择后用户只凭“是”或“否”，可能回想不出这个选项对应的是什么搜寻条件。

淘汰方案5：缩短输入框列宽，从而增加每行的列数，削减行数。

这样可以削减筛选项的行数，目的也是在首屏给列表腾地方。但填写至输入框的文本只能展现前面几个字，影响预览和理解。例如在地区的输入框中只能显示“浙江省杭州市…”无法看到“区”、“街道”等更具体的重要信息。

3.最终方案

最终方案：用户可设置展现哪些选项，且通过账号记录设置结果。

这个方案较全面的解决了问题，每个用户都可以依据自己的需求和习惯打算展现哪些选项，甚至选项排序；这个方案满意了①②③的需求，但这个需要后端开发的支持。

OneMoreThing：假如后台系统的数据加载时间比较久