后台列表设计避坑指南

后台列表设计避坑指南思维导图将搜索、列表、操作三块问题进行分析和定位，盘点一下那些被淘汰掉的解决方案，给大家提供一份避坑指南。

后台列表设计避坑指南

• 1. 问题定位
  • 搜索功能的主要问题是，条件特别多
    • 如果全部条件堆叠在屏幕上，会严重挤占列表的展示空间，使得首屏留给列表的空间所剩无几
    • 用户在寻找具体搜索条件时，仿佛大海捞针，耗时费力
  • 搜索条件多的原因
    • 一方面是由于数据信息量大，维度多。在非精准搜索的场景下，少量的条件不足以筛选出特定内容
    • 另外列表由多个职责权限的用户共用，展示的是各权限下条件合集
  • 设计方案要能同时满足下面3个需求
    • ①用户可以快速找到搜索条件——控制条件的数量
    • ②能满足搜索细致程度上的要求——搜索条件要充足
    • ③将展示区域更多留给表格——避免搜索区域占用太多屏幕空间。
  • 淘汰方案
    • 淘汰方案1：把搜索条件按照权限隐藏
      • 例如职责A的用户展示搜索条件1、2、3、4，职责B的用户搜索条件1、2、5、6
      • 此方案确实能同时满足①②③，但需要非常细致的配置工作
      • 若组织架构发生变动，维护的工作量很难预估
    • 淘汰方案2：将搜索条件放置在列表左侧
      • 这个方案试图满足需求③，希望保证首屏的展示主体是列表，但其实列表的横向展示空间被挤占了
      • 如果列表很宽，那么浏览的时候就需要频繁的左右滑动
      • 若是设备不支持左右滑动（不包含触摸板），用户只能频繁拖动滚动条，想一想这体验就很糟糕
      • 另外搜索区域的展示布局由块面转变为条状，需要向下滚动（可能是多次）才能完整预览所有条目，降低了搜索效率
    • 淘汰方案3：默认显示少数搜索条件，全部条件转移至弹窗内呈现
      • 这样设计后，看起来也能满足①②③——默认状态下的列表确实清爽了不少
      • 但如果用户需要多次切换搜索条件的组合方式时，需多次打开+关闭弹窗，大大增加点击次数
      • 这种方案还需要注意一点：搜索条件和结果展示之间的具有强关联性，需要在特定区域展示当前生效的搜索条件
    • 淘汰方案4：隐藏输入框标题，使用占位符提示搜索内容
      • 某个同学提出这个方案，原因是标题在输入框上方，隐藏标题可以使搜索条件排布的更紧密，给列表腾地方
      • 这种设计其实挺常见，但前提是输入框数量极少，且为用户所熟知
      • 但后台系统有些输入框需要选择「是」或「否」，选择后用户只凭「是」或「否」，可能回想不出这个选项对应的是什么搜索条件
    • 淘汰方案5：缩短输入框列宽，从而增加每行的列数，减少行数
      • 这样可以减少筛选项的行数，目的也是在首屏给列表腾地方
      • 但填写至输入框的文本只能展示前面几个字，影响预览和理解
      • 例如在地区的输入框中只能显示「浙江省杭州市…」无法看到「区」、「街道」等更详细的重要信息
  • One More Thing
    • 如果后台系统的数据加载时间比较久（不管是数据量大还是开发方式导致），尽量避免采用输入/选择后即执行搜索的交互样式
    • 这可能导致每次输入/选择后用户都需要被迫等待，如果选择N个搜索条件，等待时间要乘以N
  • 最终方案：用户可设置展示哪些选项，且通过账号记录设置结果
    • 这个方案较全面的解决了问题
    • 每个用户都可以根据自己的需求和习惯决定展示哪些选项，甚至选项排序
    • 这个方案满足了①②③的需求，但这个需要后端开发的支持
• 列表
  • 列表的主要问题依旧是内容太多带来的
    • 表头字段太多，超出屏幕之外，左右滑动才能完整查看条目内容，导致眼动频繁，增加认知负担
    • 条目太多，批量操作可能要多次翻页
    • 其他潜在问题也会增加列表展示的复杂性，例如条目之间存在一定相关性
    • 应着眼于避免内容太多导致的认知负担和操作成本
  • 方法一：藏
    • 「藏」，就是隐藏低优先级信息，需要的时候才允许他们出现。「换」就是转换信息呈现的形式
    • 用户来配置展示哪些表头项
    • 和之前提到的搜索区域配置功能类似，允许用户配置表头项，隐藏暂不需要的内容
    • 使用展开行
      • 适合主次层级对比强烈的列表。
      • 将重要度低的内容放入展开行内，这样可以避免横向滑动。
      • 但如果同时查看多条展开行，需要多次点击展开
    • 树形数据
      • 使用树形数据可以将一组有父子关系的数据聚合呈现，类似文章一开始提到的主合同+补充合同的场景
      • 合理的默认排序规则
  • 方法二：换
    • 使用图像代替文字
      • 图像比文字在信息传递上更直观。原因是人们对图像的处理效率远高于阅读和理解
      • 利用清晰易懂的图像可以将信息检索效率提升一个数量级
    • 合理的默认排序规则
      • 常见的排序规则包含时间的正、倒序等
      • 合理的排序规则，决定了首屏是否能呈现对用户重要度更高的内容，以及操作反馈是否可见
      • 用户新创建完成一个新条目后，列表按照创建时间正序排列，刷新后没有任何变化，需要用户翻到最后才能看见，那么这个反馈体验就不太好
      • 可以根据信息的状态设置权重参数，综合计算权重值后，重要度高的信息排在前面
        • 订阅号消息的排序并不是按照更新时间排序
          • 微信的解释是，订阅号消息排列顺序会根据订阅号的优质程度、用户对订阅号的喜爱程度以及群发文章的内容质量等综合因素动态变化。也就是有多个权重参数值叠加，综合排序。
      • 还可以允许用户将任意条目置顶等，例如微信可以将某人或某群组的消息置顶
    • 注意
      • 横向滚动条
        • 横向滚动条在底部的话，可能因为列表条目太多（例如一页展示50条），导致用户未将列表拉到底就看不到滚动条
        • 如果设备是触屏，无法支持左右滑动会非常不便，因此列表顶部也需要展示横向滚动条。
      • 固定列
        • 如果列表支持横向滚动，那么选择列、名称等标识列、操作列等建议固定，便于定位和操作
      • 数字右对齐。
        • 在小数位保持一致的情况下，数字右对齐，更容易对比数字大小
      • 空数据
        • 没有的数据不要为空，可以用符号「-」代替。
• 操作
  • 大致分成两类
    • 批量操作，例如添加/导入、设置/分配、删除、导出等。
    • 针对单条内容的操作，例如编辑、删除、查看等。
  • 批量操作
    • 批量操作相对复杂度高，出错的概率也更大
    • 设计摸索过程中总结出来的防错策略
      • 不建议支持跨页选择
        • 跨页选择首先会增加开发难度及测试复杂度，用户操作也容易出错
        • 比如，在选择过程中，已选择数据的状态可能在外部发生了变化，不再符合批量操作的条件，从而导致任务处理失败
  • 设置处理数目上限
    • 如果数据量太大，系统负担过重，也会增加超时等任务失败的频率。
  • 协助计算
    • 在用户选择过程中动态计算合计值并实时反馈，防止用户提交后才发现无法通过系统的校验条件
    • 例如用户在批量还清多笔账单时，可以在选择页面就提醒用户所选金额超出账户余额限制，而不是在提交后才给用户报错。
  • 异步反馈
    • 有些操作数据量大，处理耗时较长，例如导出全量内容等，可采用异步的反馈方式，以避免耽误用户处理其他任务
    • 依据场景，异步反馈还可采用多种通道保证信息传达给客户，例如系统内提示+短信+邮箱提示等。
  • 单条操作
    • 列表的信息展示，我们会尝试取舍和隐藏。
    • 但关于操作，在很多场景下，尽量全部展示，避免用户需额外点击才能将操作项唤出
    • 原因有二
      • 降低学习成本
      • 提升操作效率。
  • 在展示上，可以使用图标按钮代替文字按钮，但要注意语义一定要准确
    • 不要过于追求创新导致语义和用户心理模型产生偏差
    • 图标除了具有按钮功能，还能提示信息状态，一举两得。
  • 在交互上，如果操作可以在弹窗内解决，尽量不要新开页面。
    • 尤其是连续逐条处理的任务
    • 如果频繁切换页面，用户还要耗费时间重新定位任务条目
• 优秀案例
  • 案例1
    • 图片来自设计者Aaron Iker
  • 案例2
    • 图片来自设计者 Kirill Zhukovsky
  • 案例3
    • 图片来自设计者Asish Sunny，设计方案将部分操作隐藏，不过在很多场景下并不适用