上文为大家介绍了平台规范中的弹框类型，那么我们又该如何判断在哪些场景中需要用弹框？需要的话又需要哪种类型的弹框？针对这些疑问，笔者将展开进一步分析。

上一期我们讲解了平台规范中模态、非模态框的类型以及它们的使用 *** 。可回顾：《掌握“弹窗”设计规范，打造优质用户体验》。

可知道了平台规范中的弹框类型之后，你小小的脑袋瓜里有了大大的问号：了解得越全面，反而无从抉择了…这下该怎么办？

所以这一期我们来讲一下弹框的正确打开方式。最重要的还是，在每一次控件进阶专题中，我们都要学会透过表面，探索它们背后值得我们学习的设计策略。

一、你确定你需要这个弹框吗？

在讲解如何正确使用弹框之前，我想让你先思考一个问题：你真的需要这个弹框吗？

有时候当我们知道了一个控件为什么被定义出来，我们就会掉进惯性思维的陷阱当中。比如我们知道了弹框一般用于承载拓展、提示和反馈信息，我们总是会在这些场景下，不假思索地使用它。

但实际上，弹框的使用场景其实是很值得推敲的。在带大家了解弹框的“How（怎么用）”、“What（用什么）”之前，我们应该先明确“Why（为什么用）”。

先说一说产品层面的“Why”吧。

说到微信“好看”功能，喜欢阅读公众号的朋友一定不会陌生（现已根据战略将“好看”改为了“在看”）。“好看”功能的诞生初衷是微信为了突破公众号阅读量下降的瓶颈，让优质内容依靠阅读者自身社交体系，扩散给更多的用户。

最初微信刚推出公众号“好看”功能时，用户点击“好看”后，会弹出一个 Popovers ，引导用户记录下想法，并分享至“看一看”。其好友通过“看一看”这个公共区域，可以了解到最近有哪些不错的公众号内容。该功能既可以让用户以文会友加深粘性，又可以依赖用户主动分享的意愿，给公众号输入更多的流量。

一开始出于新鲜感，“好看”功能吸引了许多用户使用。但后来愿意点击“好看”的用户越来越少，其中当然有许多因素，但微信团队认为：点击“好看”之后弹出让用户记录想法的 Povpovers 增加了用户的行为路径长度，并且给一些不愿意记录想法的用户带来了行为负担，导致越来越多的读者不愿意再点击“好看”。

于是这个 Popovers 成为了一个和产品目标格格不入的控件。在微信后续的迭代中，终于还是在保留“写想法”的功能基础上，替换了这个气泡框。

但产品层面可能更多是PM去考虑的问题。那对于设计师，我们说一说交互层面。

我们前面说到，弹框的作用之一就是给用户带来行为反馈，反馈有利于搭建用户使用产品过程中的信心。但即便是为了不干扰到用户，将反馈机制尽量以非模态框的形式呈现，依然会增加用户认知成本，因为人类认知模型都是从学习到理解再到习惯。

所以在我们设计反馈机制时，有时候可以跳出“使用弹框”的设定，“弹框”仅仅是人类五感中“视觉”这一个层面，我们还可以通过“听觉”和“触觉”来传递用户反馈。

例如现在有许多APP在用户发生文本框输入错误时，会采用文本框晃动+设备震动等触觉反馈。这些交互反馈的含义已经让用户形成思维习惯，在不用阅读理解文字信息的情况下也知道这是一种错误提示。并且可以让产品交互变得更加生动。

所以当你发现你的产品设计中，真的已经有很多弹框的时候，记得问一问自己：我真的需要这个弹框吗？已经没有更好的替代方案了吗？

二、确定要用模态框吗？

解决了“Why（为什么用）”的问题之后，如果你确定当前流程真的需要用到弹框，我们就要来探究“How（怎么用）”的问题了。

上一期文章我们讲到：模态框比非模态框更容易打断用户心流，所以如果不是关系到危险操作，我们应该尽量选择更轻量的非模态框。但凭借我多年使用产品的经验，发现并非模态框的运用场景就一定是承载危险信息，所以如果以这个标准去判断应该选择哪一类弹框，稍微有些以偏概全了。

那么我们该如何在模态框与非模态框之间做选择呢？我总结了一个分析手法。

我调研了许多应用的弹框，发现选择使用模态框还是非模态框可以由以下三个维度依次进行判断：

1. 是否含有交互类操作