|
为了避免出现用户所想看的信息被其他海量信息所淹没的情况，设计师或者产研团队需要思考如何做好信息收纳，让拥有厚重信息和功能的产品变得简单清爽且易用。这篇文章里，作者就梳理了如何利用好容器类UI组件达成这一目标的策略，一起来看。  信息量大、操作复杂是B端产品的典型特征。我们如何把具有厚重信息和功能的产品，变得对用户来说清爽易用？ 设计师就像魔术师My dad once told me that graphic design is the art of fitting a newspaper inside a matchbox, and I would say a lot of interface design is the same. ——Tess Gadd《UX cheat sheet: Preview and full display》 “界面设计就是把报纸塞进火柴盒的艺术”，这个比喻真是太妙了！（本土化：把大象装进冰箱的艺术）。怎么把报纸塞进火柴盒？变魔术吗？其实从某种角度上看，我们设计师就是魔术师——在适当的时机展示恰到好处的信息。 而我们用到的道具，就是容器类UI组件。区别于其他类型的组件（比如输入框下拉框），容器类组件就像收纳盒，也就是用来收纳信息和操作的。 咱们今天就来探索一下，如何利用好容器类UI组件，完成“空间膨胀术”，把报纸丝滑地塞进火柴盒。 本文结构本文会分成两部分。
这个决策树不限于提供以下价值：
下面我们正式开始吧~ PART 1：定位问题、设定策略1. 问题所在一个单点数据关联的信息量能有多大？看一个网安行业的例子：  这两个定律告诉我们一个道理：复杂，不会让用户觉得更好用，甚至增加了不必要的内耗。 处理复杂，我们一般有哪些办法呢。  渐进呈现的设计理论有点像C4模型。C4模型是一种软件架构可视化方法。它的独特之处，就是从宏观到微观，设置了多个焦距，来层层递进。  一种是从属关系，或父子关系。 一种是关联关系，数据以某种维度建立了关联。 PART 2：容器，以及如何使用容器1. 关于容器我们如何用容器类UI组件，去放置这些复杂且层层关联的内容？ 以下是我们常见的容器类UI组件。  左下角这里基本是空的，为什么？因为这个是按照组件的最大潜力来摆放的，高维度可以兼容低维度。 值得注意的是，有一些组件在当前页面内，而有些在浮层中。浮层在空间Z轴上有高度，视觉表现为有投影。 容器可以展示信息，也可以用来承载操作。我们把这两个场景分开考虑。首先，我们从信息展示场景开始，分析如何选择容器。 2. 信息展示容器的决策树 关键问题二：是否需要对比参考。 如果需要对比参考，不能使用tabs（选项卡）。因为tabs组件存在“排他性”——只有选中tab的子内容是展示的，未选中的tabs下的内容是被隐藏的。 以购物为例，用户在对几款产品进行对比挑选时，期望在一个界面同时看到几款产品的参数和价格等。如果把产品数据放入各tab中，用户就得在tab间反复横跳，让有限的短期记忆承受巨大压力。  （↑tabs的应用） 关键问题三：是否需要保持上下文。 有这样一个场景：上级单位对多个下属单位进行考核，打分有一定主观性，需要参考其他单位得分。如果跳转新页面进行打分操作，就会断开原有上下文的关系，影响用户操作流畅性。 需要保持上下文的场景中，应避免迫使用户离开父级页面，建议在原页面或浮层中呈现更多信息。 关键问题四：是否频繁往返。 这个一般由任务类型决定，即当前操作是“主线任务”还是“支线任务”。 在主线任务场景中，用户持续前进。比如网购商品，用户在选购商品-确认地址-付费-下单完成···等步骤中环环前行。这时建议使用原页面跳转的方式。 支线任务完成后，一般要回归主任务，也就是存在“往返”，就像从小路回归到大路上。比如清理邮箱：用户阅读处理完一封未读邮件后返回未读列表，继续处理下一条。在这里，“阅读并处理一条邮件”是支线任务，“”清理邮箱”是主线任务。建议给“支线任务”新开标签页处理。  我们一般将操作分成两类：
  （↑案例：tabs嵌套tabs）  （↑案例：抽屉嵌套tabs） 今天的分享就到这里了感谢读到最后的读者们，就用一句话来结束今天的分享吧~ 设计一件东西时，总是要在更大的环境中考虑它——房间里的一把椅子、房子里的房间、环境中的房子、城市规划中的环境。 ——埃里尔·沙里宁 (1873–1950)，芬兰建筑师 本文由 @杜大大杜 原创发布于人人都是产品经理。未经作者许可，禁止转载。 题图来自Unsplash，基于CC0协议。 该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。 |
