交互设计师是如何思考一个功能的?

  • 经验类型经验/观点
  • 经验属性原创文章
  • 经验版权署名-禁止演绎
10460 11 262 2020-10-12

通过 2 个案例解读交互设计师的功能分析逻辑。


最近,有读者发来一个问题,内容大概是这样:

呆总,这个页面里我画圈的模块现在只有 2 个选项,如果有 15 个选项的话,那我要怎么设计呢?


这类问题其实不难回答,但业务不明确,以至于无法给出符合问题本身的答案。这位读者这么问,应该是想要我直接给出形式上的设计建议。

但是,我不知道这个模块的作用,页面缺少上下文的联系,也就不知道它要解决用户什么问题,更不知道选项变多至 15 个的原因。只能大致猜测是选择其中一种福利,但不知道是在什么情况下的一种选择,以及选择之后,对下面模块内容的影响。

比如,当我看到福利选择,先入为主的会认为如果餐补福利价值 800,交通优惠价值 1000,那所有人应该都会选择交通优惠的额度为 15%,期限选 3 个月吧?

这是我在这个问题中无法理解的部分,导致我给不出明确的方案,所以也就不想随便就给出一些形式上的建议了。

因为我很可能通过上下文的联系与业务的理解,从而去推翻目前这个界面的设计形式,采用另一种更合理的方案。

所以,如果要回答读者这种具有不确定性的问题,几乎就要把所有可能性提出来发给对方,这基本不可能。

而各种业务情况所面对的方案可能性都是不一样的,甚至可能导致产出的方案是相互矛盾的。所以在解决这个问题前,得先知道功能的作用,用户的目的,解决的问题与场景等,也就是业务内容得知晓。

否则,就没办法给出一个清晰的答案,到最后更多就只能是形式上的讨论了。而纯粹形式的考量有时候缺少背后的依据,会浪费掉不必要的时间。

这是许多人如今都存在的一个问题,类似于发一个界面,问交互形式如何改进。

在不知道业务情况与产品功能信息的前提下,一个界面的修改,只能从布局上做优化,而布局的设计通常要知道界面元素的优先级,以及功能所要传递的信息,什么都没有,最终只能讨论形式,是非常表面的。类似于在 dribbble 找设计灵感一样,浮于表面。

这是我在后台收到的绝大多数无法回答的问题的原因之一 —— 问题不够明确。

举个例子。

我常常看到一类读者会去分析某个设计形式的优劣,类似于截一张这样的图,说:这个搜索设计的形式不错,会根据用户搜索的内容通过搜索发现给用户推荐相似的商品。

这一类内容的学习,如果只是这样去做功课,就会陷入跟上面那个问题一样的困境 —— 浮于表面。

一个产品功能,需要搜索发现的时候,当然会放一个搜索发现,也知道它是用来给用户做推荐的。这样的案例收集与说明,几乎没有任何学习的价值。

想要对产品功能做详细的了解,至少要知道,它们依附于某个产品背后的一些规则是怎么样的。

比如,在淘宝里,它是帮用户找到更多匹配的信息,那它的推荐逻辑是怎么样的呢?搜索上限有多少个?是根据目前的搜索行为做推荐还是根据搜索的历史记录做推荐?或者是根据平时浏览的商品做相应的推荐?还要比对搜索前中后,关键词出现的差异。等等。

那如果是在知识付费类产品里做这个功能呢?没有海量数据的支撑,如何给用户的搜索进行另外的内容推荐?怎么通过用户搜索行为去绑定已有课程与搜索发现的规则?

这样深入的去了解,使用,才可能获知这类功能存在的边界情况,对它有一个更全面的了解。

往后如果自己的产品要加入类似的功能,那考量的点就可以有很多,规则的定义具体都是要根据实际的业务情况来看的,不能只留恋于形式。

我通常会在网上看到这样一类文章,大概是「解决问题的通用方法论」,或者「思考问题的通用性法则」类似的内容,一般来说不会去多看几眼,原因是我始终秉承「具体问题,肯定得具体分析」的原则。

可能有许多人会认为,解决问题就是有一种方法的,于是把时间与精力都放在找方法上。

不说这类内容完全没用,但至少就这么去按照别人给出的路径思考问题,重心一定是在路径上,而不是问题本身,这是大多数这类方法论所存在的问题。

类似于番茄工作法,工作 25 分钟,休息 5 分钟…我常常因为深入去思考一个问题,而不知不觉就过去几小时。如果按照这样的工作方法,25 分钟就要被干扰一次,效率反而会下降。

这跟上面聊的内容其实是一样的道理。对于功能设计的思考,也是需要具体考量的,不存在所谓的统一方法去解决问题。

爱因斯坦说过的一句话很符合现在聊的内容,他说:“如果我有 20 天来解决一个问题,我就会用 19 天来定义它,最后 1 天去得出最终的方案。”

但是如今许多设计师往往拿到问题的第一时间,就会打开 sketch,开始表达呈现方式,而不是对问题本身进行思考,或者希望有一个具体的方法,能帮自己想到所谓正确的方案,直接去产出。

要知道,设计是一种「视觉化的思考」,而不是单纯的「视觉化」。当我们打开软件开始画稿时,大部分的研究工作就应该已经完成了,呈现出来的结果是通过严谨地推导所得到的,而不是仅仅为了好看。

但是,现在大多数设计师的工作方式并不是这样。

于是,当我们开始思考它的呈现方式时,应该先回溯一下问题本身的背景与各种情况。


案例:直播间送礼面板的设计差异

读者提问:

最近领导要求对直播间送礼面板做改版,我去找了一些竞品做了分析,发现很多直播间开始支持横屏模式。在横屏模式下,有两种礼物面板的布局形式,第一种是以 B 站为例的送礼面板,由下弹出;第二种是以 Look 直播为例的右侧滑出。是什么原因导致这两种设计的差异呢?

B 站礼物面板

网易 Look 直播礼物面板

大家都知道,B 站文化的核心之一就是弹幕,甚至延伸出了一种弹幕文化类似的说法,虽然我对弹幕不是很了解,但是从中可以看出,弹幕对于 B 站而言,或者说对于 B 站用户而言,是非常重要的。很多时候,它的重要性甚至与直播内容难分伯仲。类似于,一个很好看的视频,少了弹幕,总觉得少点滋味。而一个内容一般的视频,加上有趣的弹幕,也同样能吸引用户的注意。

不知道你是不是也这样,我自己不看弹幕,感受不深,其他 B 站的深度用户是这么跟我说的。大意是,没有弹幕的 B 站是没有灵魂的。

在 B 站,用户对于弹幕的依赖性很强,从这个角度看来,它的直播间礼物面板从下方弹出就比较容易理解了 —— 与弹幕信息互不干涉。

大概是,要设计一个送礼面板,不知道怎么布局,思考过后得出一个结论,一定不能挡住弹幕。那形式选择就很清楚了。

即使和竖屏模式礼物面板设计差异较大也不得不接受这种形式。算是一种「因地制宜」的良策吧?

另外,还可以通过一个细节来验证上面这个观点。

如果去对比 B 站直播间横屏和竖屏的弹幕差异,会发现在竖屏状态下,弹幕经常会撑满整个直播画面。其中送礼气泡与互动区都在画面下方,画面中只有弹幕。

这时候再横过来,会发现弹幕数量即使在很多的情况下,也会离画面底部一段距离。包括送礼气泡也会显示在画面中,但它与底部也会有一段距离。

这时候打开礼物面板,就能发现这个距离的尺寸,正好就是礼物面板的高度。

所以从这点也能看出,是特意分隔开弹幕与面板,为的就是不能让面板挡住弹幕,同样也不能让弹幕影响送礼。

而互动区直接被去掉了,在画面中没有保留。因为互动区的互动信息会以弹幕的形式显示在画面中,至于系统消息,如「谁进入直播间」的提示,在 B 站中的优先级,没有弹幕高,所以在左下角提示,即使送礼面板将其盖住也没什么影响。

这就是 B 站在直播间如此设计送礼面板的原因。

而类似于 Look 直播的横屏模式,礼物面板则是从右侧滑出。

同样的道理,Look 这一类的秀场直播,无论是用户发言还是系统信息,在横屏模式下,都处于左下角的互动区里,因为它没有弹幕,所以侧滑礼物面板是更好的选择。

但是有一些产品,比如快手,会同时留有左下角的互动区与弹幕,那就要衡量自身产品的弹幕优先级,如果优先级不高,优先显示左下角的整合互动区,反而是一种省力的方式。这时礼物面板从右侧滑出,也不会影响整体的页面布局。

快手礼物面板及弹幕消息

而像抖音的部分直播间,在横屏模式下,就只有弹幕,没有互动区。如果仔细观察甚至能发现,抖音的横屏模式下,所有信息都会以弹幕形式出现于屏幕上,包括互动消息,系统提示等,数量多的情况下甚至会填充整个屏幕。这时候点击送礼面板,竟然是右侧滑出。

这样的设计形式对比一下就知道 B 站的横屏模式设计的更为精致,区分了系统提示、弹幕消息、送礼面板等,分布非常明显。而抖音的各个模块相对就比较乱,送礼面板模块的出现又影响了页面内容的其他信息。就导致页面中的信息层级与布局都稍显混乱。

这两个案例有一个知识点,就是「信息优先级决定布局形式」。

什么叫做信息优先级?大致意思就是一个界面上的信息是根据从重要到次要的规则排序的。

比如在直播间,最重要的信息一定是直播内容,其他信息都是根据直播内容附带产生的,正是因为直播内容引发用户打赏欲望,于是点击送礼按钮,弹出送礼面板。

而面板的展示形式还需要根据页面中的其他内容平衡布局,比如弹幕优先级,或互动区优先级等等,它们之间要有序排列,不能互相干扰。比如 B 站与 Look 直播这两类产品的设计差异。

而抖音横屏模式的送礼面板如此设计,将整个页面内容的信息都打乱了,并不可取。

这叫内容聚焦点的缺失,各位要尤其注意。

另外,从内容聚焦点再引出一个知识点,是关于视觉体验的,也就是 UI 在设计类似页面的过程中,需要注意的体验性。

大家能看到上面这张图,B 站的送礼面板高度,是小于半个屏幕的,包括透明度也是,依稀能穿透到直播画面中,虽然有切割感,但还能接受。

而 Look 的磨砂玻璃似的设计,使得画面切割感很严重,导致送礼过程中,超过一半的直播画面被遮挡了。我相信这个过程可能是会影响用户送礼欲望的。比如产生送礼想法,但是精彩时刻,想到点击送礼会遮挡画面,那等会送好了,于是就忘了,或是算了。

像上面的例子中,快手的界面虽然也采用右侧滑出的设计,但是它的送礼面板宽度设计的比较小,正是考虑了上面提到的这个原因。

所以各位在设计直播间类横屏模式的送礼面板时,尤其需要注意文中提到的这几点。

今天这篇文章,通过信息优先级与界面元素的分析,给大家讲解了直播间送礼面板的设计思路。文章内容当然还能扩展,但一篇文章,讲 1-2 个知识点也足够了。

如果对你有帮助,记得三连。

谢谢阅读:)

Powered by Froala Editor

全部评论:11

  • up_up_up

    10-22 16:22

    感觉放在右侧信息更为集中,更容易找到。像B站这种出现在下方,视线要从屏幕左侧往右侧扫。

  • UtopiaNan

    10-16 16:41

    上了呆总的课,果然能看懂呆总的文章了

  • 豆豆的琪琪

    10-15 16:57

    牛妞妞

  • 喵与文

    10-15 11:03

    迷弟观光

  • 法国红酒

    10-14 17:56

    未 满1 8 岁勿入【 www.yoyo9.work 】

  • oni小鬼

    10-14 14:25

    写的很棒!

  • 是腻腻阿

    10-13 18:21

    又学习到了

  • WuGna

    10-13 09:38

    来了大佬

更多作品

发表评论

取消

点击右上角
分享给朋友吧

分享到

取消

每人每天仅限5票,快给你心仪的作品鼓励的一票。

投票