为什么看再多的设计原则,也做不好B端交互?

5 评论 6148 浏览 76 收藏 14 分钟

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

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

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

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

一、业务优先的全局思维

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

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

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

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

为什么看再多的设计原则,也做不好B端交互?

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

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

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

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

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

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

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

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

为什么看再多的设计原则,也做不好B端交互?

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

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

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

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

二、同理心和角色目标带入

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

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

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

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

为什么看再多的设计原则,也做不好B端交互?

在右侧的改版里,我把单从横排改成了竖排,从原本省空间的方案改成了不省空间的方案,和上一个案例截然不同。

为什么?看看下面的细节先。

为什么看再多的设计原则,也做不好B端交互?

如果真当自己是用户,看一遍自己做的设计,给自己定个操作的目的,并尝试在这些内容做选择,那么你选择到这种模块,就必然开始混乱起来。

上下的内容离得太近了,比左右同行同级元素还近,这样会极大损害信息识别的效率和操作顺畅度。尤其当我核对前面单选项是否选对的情况,阅读起来更是痛苦。

为什么看再多的设计原则,也做不好B端交互?

而我们把内容进行上下排序,将亲密性表现得更合理,那么操作的舒适度就会显著的上升。至于多出来的高度,作为用户你沉浸在表单输入过程中,为什么会关注多出来的那点高度?

好吧!如果一定要用理论方法来分析,那可以堆砌一堆的理论解释:

  • 亲密/对齐性:上下排序的亲密性可以完美符合左对齐视觉引导,以及不同模块跨度的划分
  • 菲兹定律:左对齐的选框位置距离极短,除了滚动外鼠标就负责上下移动,而不用全屏幕流浪
  • 心流理论:用户视线不要轻易被打乱,就容易沉浸到完成当前目标,而不是关注怎么设计美观
  • ……

理论可以拿来在 PPT 里强化自己方案的说服力,但前提是别自己绕进去,纯粹通过理论的堆积来认为自己设计的是合理的。

再看看下面这种表单页的案例,多列设计来让画布被填满的设计,思考下到底是为了设计而设计,还是为 “用户” 设计?

为什么看再多的设计原则,也做不好B端交互?

三、字段信息整理的必要性

第三点,就是有效的整理需要的设计模块的字段信息。从产品层面去理解该模块的诉求,信息层级,状态类型。

有很多复杂的组件,如果我们直接动手画,是行不通的。主要问题源自需求层面的复杂性,不仅字段非常多,而且它们是有层级关系,集联性质。

比如再看下图的学员案例,一个在公司平台上传公共文件时,进行素材权限编辑和信息管理的组件。

为什么看再多的设计原则,也做不好B端交互?

在这个模块中,包含的功能和可操控的元素非常多。从整个面板的标题开始,作为最顶层的信息,向下可以延伸出不同的子模块和对应的二级标题。

每个二级标题下,还有不同的下级元素。我们不仅要有效处理这些关系,同时还要分析权限的字段内容,它们包含了:权限类型标题、对象、对象权限、选择、删除、添加。

这时候,我就会用文字的方法把这些信息整理出来:

为什么看再多的设计原则,也做不好B端交互?

然后,重新梳理不同层级结构,再完成不同状态的兼顾,缩减无效的按钮,尽可能降低信息的复杂程度。下面是改动后的案例(只做了原型)。

为什么看再多的设计原则,也做不好B端交互?

为什么看再多的设计原则,也做不好B端交互?

交互的很多工作并不在设计软件上,而是要跳出软件和设计稿,去理解实际的产品需求、信息、字段。除了一些树状图外,必要的交互流程图是无法省略的。

多种工具导图和原型的共同作用,才能帮助我们在复杂的需求环境下 “试” 出足够多的方案找到最满意的那一个。

四、检验是说服力的最优途径

最后,就是自己也拿不定主意,或者你的方案就是说服不了产品、开发的常见情况,怎么办?

那就是真实的做测试和投票!

B 端比 C 端最大的优势之一,就是如果真要做用户调研和测试,容易了无数倍。不管是给客户做方案还是做公司内部项目,你的目标用户群体是非常固定而且容易联系的。

当我们在交互方案上僵持不下的时候,就不用纠结或者通过开会的撕逼来做决策。而是把这交互方案的高保真原型做出来,给对应的目标用户做测试。

比如上面表单的案例中,新老两个案例,你都可以快速用 Axrure 或者 Protopie 等软件实现高保真的交互原型,1:1 还原真实操作场景。

你可以从下面制作的初步案例中查看操作结果:

请在电脑端打开,才能还原真实操作:

原案例:https://cloud.protopie.io/p/f20dc7a0eb

改后案例:https://cloud.protopie.io/p/42c51829cd

这时候,方案哪个有效不就根本不用争论,交给目标用户去使用和投票不就明了了嘛?B 端交互方案的决策权,可以由目标用户来主导,而我们要做的就是去建立这样的决策机制,如何快速的来生成不同交互方案,并让目标用户决断。

不要再在无穷无尽的 “你觉得”、“我觉得” 中损耗项目进度了……

五、结语

以上,就是一些 B 端交互设计中的思路实际解决流程。这些也是我最真实的工作状态下解决问题的方案,所以并不想写一大堆理论来欺骗自己了(狗头保命)。

希望大家能从中获得收获!

 

本文由 @酸梅干超人 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 自己测了一下,修改前的这个横排填起来要耗时更多,要左右转动头,修改后的只需要从上往下动眼睛就行了,省事很多

    来自四川 回复
  2. 写得真好、速速更新

    来自北京 回复
  3. 这两个方案最大区别是啥呀

    来自江苏 回复
  4. 写的真好!!

    来自北京 回复
  5. 写的很好!下次还要再写,介绍的很详细,详细的思路实际解决流程

    来自江苏 回复