交互|为什么看再多的设计原则，也做不好B端交互？
编辑导语：大家有没有思考过一个问题，为什么B端产品的页面交互设计师看了很多设计原则也还是做不好B端交互？本文就这就这件事提出了自己的看法，以及给出了一些解决方案，希望能给大家带来一些帮助。推荐对B端交互感兴趣的用户阅读。
长久以来，我们一直强调 B 端设计，最重要的输出产物不在于样式，而是交互。优秀的交互设计可以显著的提升操作效率，更快完成工作任务，从而提升经济效益。
但是要怎么讲清楚它是很痛苦的一件事，理论上的交互原则，和真实工作场景遇到的困难很难匹配。大家会有这种感觉：看再多的分享和原则，也做不好交互。
所以，我们要来探讨一些 B 端交互的基本要求和特点，下面用一些近期的案例做简单的剖析。
一、业务优先的全局思维在 B 端项目中，所有的工作目标，都是围绕在更好的解决业务问题展开的。一个完整的业务需求，必然是包含大量的组件、流程的共同参与。
我们在设计内容的过程中，往往会掉进过度关注某个单元的细节，而忽略整体对整体业务目标、重点的认知，出现本末导致的问题。
所以，针对每个局部的组件，我们一定要思考它在流程中的重要性，使用频率，使用场景。
比如前阵子分享的学员案例筛选组件，我们将左侧露出的筛选项进行折叠合并，修改成了右图的结果。
光盯着组件看，可以明确的说案例 1 必然是更好操作的，因为筛选内容可见，操作步骤较少。如果你只想到这里，那么必然是没法处理好交互的。
我拿到这个案例的第一件事，实际上就是搞懂这个页面是干嘛用的，处理什么业务，以及了解目前用户的一些基本诉求。
最后得到的结果，就是操作员来到这个页面，主要查看异常的状态和它们的详情。因为列表本身是根据时间排序的，异常状态没有处理的也通常都在前面。
所以，操作员直接查看列表是最高频的操作，并且表头因为支持排序切换，也是高频操作的内容之一。反而顶部的筛选，只有遇到一些特殊情况，需要将历史中的某些条目筛选出来，才会用得到。在正常使用过程中是会被自动忽略的。
而且目前用户的主要反馈也出现，顶部的筛选过高，每次进页面都要下拉才能看见列表，操作极为不便。
基于这样的前提条件，我就一定会压缩顶部筛选区域的高度，确保下方列表的大多数内容在一屏内可以显示完。
那为什么还要改里面的筛选方法而不是简单做个折叠和展示？
还有一个全局化的考虑，就在对一个筛选组件的设计，就是其它所有页面筛选组件样式的基础。这个页面我们只放了七行，其它页面最多的筛选项最高多达一倍。即使做成折叠的，展开后甚至一屏都放不完筛选内容，比如下面这样的示例。
并且，筛选完之后，这个面板折叠还是不折叠，折叠了的话看结果列表就看不到前面选了哪些。不折叠同样也基本看不见，因为列表需要下拉，把上半部分内容隐藏。
所以，最终进行多列排序的设计，就是舍弃最“初步”的便利性，为业务目标让步。同时基于全局的可用性做预判，对一个低频操作的模块减少过度信息的露出，让用户可以高效完成 1 级信息索引（找到选项标题），然后再去做 2 级筛选。
在长期以来的 B 端项目实践中，我都始终践行业务优先的原则，检查处理的方案能不能满足我上面分析的特征，只有满足不了业务需要，我才会去修改它。
推荐阅读
- 房价|为什么越来越多的人喜欢在农村建房
- 黏土|为什么国家要禁止红砖建房？看看它的危害你就明白了！
- 房价|合肥二手房卖不掉，挂牌量都快9万套了，房价为什么还不降呢
- 住房公积金|为什么有人宁愿负债百万以上买房呢？
- 房主|为什么有人说回迁房不能买？
- 地暖|为什么开着地暖，地面还会“冷”？
- 回暖|楼市利好不断，为什么购房者迟迟不肯入市？年后房地产会回暖吗？
- 首付比例|为什么重庆的房子不能买来投资？
- 杭州|杭州为什么想吞并绍兴？原因很简单，看一看地铁
- 购房置业|为什么买房要关注物业水平的高低？有4点因素，影响居住和转手