交互设计师是如何思考一个问题的?

Recommanded by editor
1年前Publish
2262
|
2
|
85
通过 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 的磨砂玻璃似的设计,使得画面切割感很严重,导致送礼过程中,超过一半的直播画面被遮挡了。我相信这个过程可能是会影响用户送礼欲望的。比如产生送礼想法,但是精彩时刻,想到点击送礼会遮挡画面,那等会送好了,于是就忘了,或是算了。


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


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


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

85
Statement: all the content and comments made by netizens in ZCOOL only represent themselves, and do not reflect any opinions and opinions of ZCOOL.
Report
Share
Collect
in to comment
Add emoji
喜欢TA的作品吗?喜欢就快来夸夸TA吧!
All Comments0
杭州 | 产品设计师
Article information
文章标签
收录收藏夹
更多收录此文章的收藏夹