列表页构后台使用界面的重组之一,聚合了众多信息并提供操作入口。区别于小的C端产品列表,后台系统的用户希望列表的内又多又全面(表格),但操作时又能支持速(搜索,包含筛选)、准确处理(操作)。这需求貌似些矛盾,但很多场景下,例如客服接待客户时窗口时间极其短暂,既全面获取相关信息,又速应对解决客户问题。因此这需求不仅合理且刚需。
列表页由「搜索」、「表」和「操项」三大基块组成。刚才提到的矛盾点也是由三个模块之前的互相影响和约(面详细阐述)。我们当初由在设计时忽视特定场细节,以及生搬硬套一看来很美很简约的互样式,没有处理三个模块内部以及之间的关系,被用户抱怨说不用。篇文章就将「搜索」、「列表」、「操」三块问题进行分析和定位,盘点一下被淘汰掉的决方案,给大家提供一份避坑指。
注意,不存在「最好」用案,有应具体需求「最合适」解决案。
1. 问题定位
搜索功能的主要问题是,条件特别。果部条件堆叠在屏幕上,严重挤占列表的展示空间,使得首屏留给列表的空间所剩无几。用户在寻找具搜索条件时,仿佛大捞针,耗时费力。
造成搜索条件的原因,一方面是由数据信息量大,度。在非精准搜索的场下,少量的条件不以筛选出特定内容。另外列表由个职责权的用户共用,展示的是各权下条件合集。
设计案要能时满足下3个需求:
- 用户以快速找到搜索条件——控条件的数量;
- 能满足搜索细致程度上要求——搜索条件要充足;
- 将展示区域更多留给表格——避免搜索区域占太多屏幕空间。
淘汰方案1:把搜索条件按照权隐藏
例如职责A的用户展示搜索条件1、2、3、4,职责B的用户搜索条件1、2、5、6。此方案确实能同时满足①②③,但需非常细致的配置作。若组织架构发变动,维护的作很难预估。
淘汰方案2:将搜索条件置列表左侧
这个方案图足需求③,希望保证首屏的展示主体是列表,但其实列表的横向展示空间被挤占了。如果列表宽,那浏览的候就需要频繁的左右滑动。若是备不支持左右滑动(不包含触摸板),用户只能频繁拖动滚动条,想一想这体验就糟。
另外搜索区域的展示布局由块面转变条状,需向下滚动(可能多次)能完整预览所条目,降低了搜索效率。
淘汰方案3:默认显示少数搜索条件,全部条件转移至弹窗内呈
这计后,起来也能足①②③——默认状下的列表确实清爽了不少。
但如果用户需多次切换搜索条件的组合方式时,需多次打+关闭弹窗,增加点击次数。这种方案还需注意一点:搜索条件结果展示之间的具强关联性,需特区域展示当效的搜索条件。
淘汰方案4:隐藏输入框标题,使用占符提示搜索内
某个同学提出这个方案,因是标题在输入框上方,隐藏标题可以使搜索条件排布的更紧密,给列表腾地方。这种计其实挺常见,但前提是输入框数量极少,且为用户所熟知。但后系统有些输入框需要选择「是」或「否」,选择后用户只凭「是」或「否」,可能回想不出这个选项对应的是什搜索条件。
淘汰方案5:缩短输入框列宽,从而增加每行的列数,减少行数
这样可减筛项的行数,目的是在首屏给列表腾地方。但填写至输入框的本只展示前面几个字,影响预览和解。例如在地区的输入框中只显示「浙省杭州…」无法看到「区」、「道」等更详细的重要信息。
最终方案:户可设置展示哪些项,且通过账号记录设置结果
这个案较全解决了问题,个用户都可以根据自己需求和习惯决定展示哪些选项,甚至选项排序。这个案满足了①②③需求,这个需要后端开发支持。
如后台系统数据加载时比较久(不管是数据量大是开发导致),尽量避免采用输入/选择后即执搜索交互样。这可能导致输入/选择后用户都需要被迫等待。如选择N个搜索条件,等待时要乘以N。
欢迎关注者的微信众号:「能呆书房一整天」