设计碎碎念:如何为「多层目录」选择恰当的呈现形式

在设计中后台产品时,我们会碰到各种需要多层目录(或级联选择)的场景。

最近在应对多层目录的需求时踩了小坑,好在后来意识到问题,及时修正了方案。不聊问题,先来看看常见形式:

形式一:多层目录

常用于文件或报表索引,层级深度为3-4,模块位于侧边导航处,每层可点击+展开/收起。
confluence.jpg

bdp 个人版

  • 信息层级清晰直观
  • 左右映射,索引与内容一致性
  • 直接了当,随时在不同内容间切换
  • 界面冗余
  • 分散用户注意力
  • 索引易被遮挡,需Hover或横向滚动

形式二:产品服务List

常用于控制台/产品官网,特点是深度为1-2层,Hover即出现,平铺展示所有项目。

aliyun

baiduyun

  • 平铺全集,便于发现和寻找服务
  • 内容区足够大,极少存在遮挡
  • 默认收起,不占页面空间
  • 仅适用于1-2层深度

形式三:级联选择

常见于控制台导航栏选择服务或表单级联选择框,深度较自由,一般为2-3层。

aliyun 级联选择

antdesign 级联选择框

  • 便于一次性选择
  • 可承载较多选择项,兼容性佳
  • 不利于频繁切换

形式四:分步选择

常用于较谨慎表单操作,将3-4甚至更多层级打散,页面每次平铺显示本层内容,逐层确定。

##应用
最近一次应对这个问题时,首先尝试的是多级目录这一最原始的手法,考虑到于内容易被遮挡,便努力尝试了其他方式,包括级联选择、平铺展示全集、打散分步选择等能想到的各种方法。想了一圈,有找到「看起来」更好的方式,但中后台产品最重要的还是业务逻辑,于是最后又回到了原点,选择了多级目录。


控制台类产品设计往往建立在已有的设计规范/原则的基础上,然而即使是同一控制台的不同模块,在形式上也未必完全一致,即实际解决方案没有那么「漂亮」。十全十美的规范不存在,如果强行套用,就要以牺牲部分用户体验为代价了。

粥一 wechat
扫一扫关注我的公众号,随时与你分享最新文章