编辑导语：大家有没有思考过一个问题，为什么B端产品的页面交互设计师看了很多设计原则也还是做不好B端交互？本文就这就这件事提出了自己的看法，以及给出了一些解决方案，希望能给大家带来一些帮助。推荐对B端交互感兴趣的用户阅读。

长久以来，我们一直强调 B 端设计，最重要的输出产物不在于样式，而是交互。优秀的交互设计可以显著的提升操作效率，更快完成工作任务，从而提升经济效益。

但是要怎么讲清楚它是很痛苦的一件事，理论上的交互原则，和真实工作场景遇到的困难很难匹配。大家会有这种感觉：看再多的分享和原则，也做不好交互。

所以，我们要来探讨一些 B 端交互的基本要求和特点，下面用一些近期的案例做简单的剖析。

在 B 端项目中，所有的工作目标，都是围绕在更好的解决业务问题展开的。一个完整的业务需求，必然是包含大量的组件、流程的共同参与。

我们在设计内容的过程中，往往会掉进过度关注某个单元的细节，而忽略整体对整体业务目标、重点的认知，出现本末导致的问题。

所以，针对每个局部的组件，我们一定要思考它在流程中的重要性，使用频率，使用场景。

比如前阵子分享的学员案例筛选组件，我们将左侧露出的筛选项进行折叠合并，修改成了右图的结果。

光盯着组件看，可以明确的说案例 1 必然是更好操作的，因为筛选内容可见，操作步骤较少。如果你只想到这里，那么必然是没法处理好交互的。

我拿到这个案例的第一件事，实际上就是搞懂这个页面是干嘛用的，处理什么业务，以及了解目前用户的一些基本诉求。

最后得到的结果，就是操作员来到这个页面，主要查看异常的状态和它们的详情。因为列表本身是根据时间排序的，异常状态没有处理的也通常都在前面。

所以，操作员直接查看列表是最高频的操作，并且表头因为支持排序切换，也是高频操作的内容之一。反而顶部的筛选，只有遇到一些特殊情况，需要将历史中的某些条目筛选出来，才会用得到。在正常使用过程中是会被自动忽略的。

而且目前用户的主要反馈也出现，顶部的筛选过高，每次进页面都要下拉才能看见列表，操作极为不便。

基于这样的前提条件，我就一定会压缩顶部筛选区域的高度，确保下方列表的大多数内容在一屏内可以显示完。

那为什么还要改里面的筛选方法而不是简单做个折叠和展示？

还有一个全局化的考虑，就在对一个筛选组件的设计，就是其它所有页面筛选组件样式的基础。这个页面我们只放了七行，其它页面最多的筛选项最高多达一倍。即使做成折叠的，展开后甚至一屏都放不完筛选内容，比如下面这样的示例。

并且，筛选完之后，这个面板折叠还是不折叠，折叠了的话看结果列表就看不到前面选了哪些。不折叠同样也基本看不见，因为列表需要下拉，把上半部分内容隐藏。

所以，最终进行多列排序的设计，就是舍弃最“初步”的便利性，为业务目标让步。同时基于全局的可用性做预判，对一个低频操作的模块减少过度信息的露出，让用户可以高效完成 1 级信息索引（找到选项标题），然后再去做 2 级筛选。

在长期以来的 B 端项目实践中，我都始终践行业务优先的原则，检查处理的方案能不能满足我上面分析的特征，只有满足不了业务需要，我才会去修改它。

而不是虚空树靶，光靠各自的 “觉得” 来讨论，这样的讨论不仅没有质量，而且不会获得有效的结果。

做产品和交互，对用户的理解优先建立在共情和同理心上。

了解用户，最好的方法不是你做了科学的实验，应用完善的理论，而是你自己成为用户！可惜很多设计师都想不明白这个道理，过度追求数据或者调研方式。

在上一个案例中，也有同理心应用的部分，自己作为用户知道这个页面操作的重点，在权衡利弊的过程中你自然知道应该选择什么，放弃什么。

下面再看另外一个学员案例，也是表单，但是是需要用户完整填写的大量表单内容。