B端穿梭框遭嫌弃，有更好的替代方案吗？

最近有同学把这个方案发给我，让我帮忙看看：

P.S. 为了避免隐私问题，所有方案都是修改内容后重画的。

这是一个挺典型的穿梭框（Transfer），如果你不知道穿梭框是什么，可以看一下Ant Design 的代码案例：

对方的纠结点在于，觉得穿梭框使用挺不方便的，而且还不能排序，但又不知道怎么改。

尝试改方案

这位同学自己改了一版，问我行不行：

上面这个新方案，说实话我第一眼没看太懂。直到看到下面这张操作示意图后，才总算理解：

看完这个方案之后，我的感受是，排序功能是增加了，但……

操作成本没有降低——以前是点击2次，现在是点击后拖动，说不定还更麻烦了。

关键是，认知成本反而更高了——穿梭框好歹还是标准组件，现在真的很难看出拖动操作。

听我这么分析，这位同学越发不知道怎么做了……

所以我决定今天来分享一下这个案例。

主要问题在哪？

可以理解这位设计师不想用穿梭框的心理，穿梭框虽然是很多设计系统都有的标准组件，并没有像表格、表单等B/C通用的组件那么通俗易懂。

对于一个想要C端化，或者对用户体验有高要求的B端产品来说，穿梭框的问题还是挺多的。

我们还是回头去看文章开头那个用穿梭框的方案吧，主要有三个问题：

1.操作暗示不强

如果一个用户从没用过穿梭框，那么第一次来到这个界面的状态很可能是这样的：

最先看到的信息是「新建分组」，其次是「名称」，接下来是「12项」和那些人的名称，再后面是右边的空白框。

经过这么长的路径后，看到空白框的时候，用户可能才反应过来——这是要把左边的人加到右边去。

也就是说，用户开头的困惑时段会比较长。

2.选项露出太少

在弹窗上方穿梭框，上面还有输入框，导致能展示列表的空间很小。

尤其左侧那个列表，如果12个项目是常态的话，一半多都没展示出。

3.操作路径长

用户必须先选择项目然后点击箭头，操作才算分组成功，不能一步到位。

如何解决？

见这位同学找不到方向，我干脆帮忙画了一个新方案。

改动非常大，不过却让对方表示：“醍醐灌顶。”

为了方便大家理解，我做成原型演示一下：

为什么说这个方案能解决以上的三大问题呢？

1.操作暗示不强的问题

对一个没用过穿梭框的人来说，新方案的布局更简单，所以猜出操作方式之前的步骤就比较少一些：

即便脑子转不过弯来，看到「从左侧添加」的文字也总能看懂吧？

2.选项露出太少

新方案的空间更大，能够露出的项目明显更多了：

3.操作路径长

新方案单次点击加入，原地再点一下移除，操作成本明显降低：

而且还支持从右侧的排序和移除：

还有一个小细节——分组名称输入框自动获取焦点的同时，还默认给了一个组名。因为文字是选中态，不想要直接输入新名字即可。

新方案的局限性

标准组件虽然有时不一定是最好用的，但场景使用广泛，而且开发成本低。

新方案开发成本肯定更高一些，图省事的话，还是改回穿梭框吧。

或者你家用户已经习惯原来的方式，那就千万别随便改了。

但这么讨论就没意思了，即不想投入成本又怕用户不习惯的话，那么老老实实拼组件就得了。

咱们既然是讨论产品体验设计，那就不能先用这些条件束缚自己，对吧？

新方案和穿梭框相比，缺少了一个全选功能。

不过这个也有处理办法，如果全选真的很常用的话，找个地方放一个全部添加的按钮和全部移除的按钮即可。

除此之外，选项的不确定性也可能带来风险——如果数量太少左侧会显得有点空，如果数量太多又可能需要搜索。

所以设计之前肯定要搞清楚通常的项目数量范围，既包括分组前的数量，也包括分组后的数量。