通过 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