弹窗、对话框，随你怎么称呼，这些小窗口出现在屏幕上从来都不是理所当然。虽然它们是你应用中一些相对较“小”的元素，却扮演着影响用户体验的重要角色。

一方面，它们可以帮助用户度过应用内的旅程。另一方面，处理不当时，它们也会使用户感到挫败。

有幸的是，弹窗比较成熟，容易实现。用适当的手段和规范可以轻易改善它们。我们这篇文章要讨论的就是这个。

由于并非所有弹窗形式都相同，我们把它分解为5种常见类型，并且总结了每一种的优化“准则”。遵循这些指南，你一定可以使你的弹窗更好地达成目标。

“推荐给朋友”和“为应用打分”弹窗

你当然希望用户量增长、提升好评率、增加病毒式传播的可能。谁不想呢？但是你要了解，多数用户不会向朋友推荐你的应用，或者给它打分，除非他们觉得这么做会得到有价值的回报。

Uber的奖励弹窗

“但是，推荐给朋友是如此简单轻松的任务啊！为什么用户不会大发慈悲，帮助一款小软件成长呢？”很不幸，现实没有这么简单。

注意我们刚才用的词是“任务”。这就是多数用户看待“推荐给朋友”和“为应用打分”的方式——看成任务。互换原则就在此时发挥作用。大概来说，就是你得给予用户某些东西，然后才能向他们索取。可以是通勤应用中的免费出行，或者是某种总体价值和乐趣。最好对这些弹窗使用A/B测试，让它们以不同时机出现在用户旅程的不同位置。这能让你更好地获得重要的统计数据，了解最终应该在何时何地放置弹窗。

同时也一定要确保，从你的应用中转到App store、社交媒体频道、或消息平台的过程尽可能流畅。获得一个推荐链接对于用户真的是“简单”的事情吗？在Wi-Fi和移动网络环境下，整个流程的运转有何差别？有许多重要因素需要考虑。花时间分析和优化这两种弹窗，你肯定能收获更高满意度、活跃度和更多新用户。

记住，“[聪明地]索取，你才会有回报。”

“推送通知”弹窗

推送通知是一个超有价值的手段，能使用户保持投入、反复使用。对许多用户来说，推送通知已经成为了他操作一款应用的主要媒介。不必再打开应用，用户通过推送通知满足他们大部分需求。于是，获取和保持向用户发送通知的权利，应该是用户粘性与留存策略中的一个重要方面。

在Android系统中，方式很直接：推送权限请求会作为AndroidManifest.xml的一部分，用户在安装前会看到所有需要获取的权限。

在iOS上就是另一回事了。iOS的权限弹窗必须由应用内的代码触发，会向你的用户展示一个这样的弹窗：

图片来源：Xtremepush.com

如果用户点按了“不允许”选项，对你来说就相当于玩完儿了。除非用户手动进入权限设置，否则拒绝权限是不可逆转的。所以让你的用户按下“允许”权限至关重要。

我们推荐两种方式，来尽可能保有最多的通知推送许可：

1. 尝试创造一个你自己的、应用自带的权限弹窗，让你评估用户接受推送通通知的意愿。这会让你更加理解用户的行为和偏好，把权限获取留到某个用户真的愿意点“允许”的时机。
2. 仅仅在在你认为最相关和最有说服力的时候请求权限。在此时此地，真的有需要获取通知权限吗？在权限请求提示中，借助当前环境清晰地向用户作出解释。

数据权限弹窗

推送通知权限和数据获取对话框一脉相承。同样，对于这些特殊弹窗的用户体验，我们都是在讨论iOS应用。数据权限弹窗包含对位置、日历、联系人信息、提醒事项和相册的请求。移动开发者必须小心翼翼，因为请求数据权限不是一系列勾选框那么简单。

来源：Developer.apple.com

苹果在他们的权限请求指南中提到：“虽然人们赞赏移动应用获取个人信息所带来的便捷，但他们也希望能掌控自己的私密数据。例如，人们喜欢自动给照片标记上地理位置，或者找到附近的朋友，但他们也想要一个能关闭此功能的选项。”

要使这类弹窗保持相关、显而易见。别设计一个请求用户地理位置的计算器——别这么做。

使用苹果在弹窗中提供的文字位置，描述你的应用为何需要这些信息，即使你自己认为原因显而易见。在某些特定的、相关的用户操作之后，再请求适合的权限，也是一个好方法。比如说，用户使用你的应用创建了一段视频，并且想要分享给朋友。只要用户点了“在Facebook上分享视频”按钮，这就是弹窗请求用户社交媒体账号权限的绝佳时机。用户更容易接受权限，因为它提供了清楚的解释，“要想达成A，必须先完成B”。

想要深入研究，请看我们的一篇文章，讨论如何使数据权限不那么令用户望而生畏。

“错误”弹窗

除了向用户索取权限，弹窗也是开发者向用户表达信息的一种重要手段。尤其是关系到应用内的错误。

世事无常，总有错误出现。错误中的错误是最不该发生的。这么说是什么意思？就是说你的弹窗不能让用户感到迷惑，使得已经发生错误雪上加霜。

我们来举个例子，比如用户的收货地址写得不合逻辑，所以当他们在支付时就会发生“错误”。如果你的弹窗里写着：“发生了错误：支付无法完成”，用户就不得不试图猜测错误的原因。相反，你应当利用这个时刻告诉用户为什么错误会发生，收货地址中具体哪一项需要更正。必须要了解，用户任何的猜测和挫败，可能被一个弹窗放大，最终影响潜在的转化。

而且，对于那些需要用户操作的错误，我们不仅仅告诉用户错误发生、该做什么，还需要引导他们前往相关的操作界面。坚持使用清晰的措辞来准确表明操作（抹掉、撤销、前往的我个人信息界面），而不是使用模糊的文案，例如“是”或“否”。

如果应用中发生了技术性错误，你可以利用弹窗来触达用户，告诉他们你正在努力解决问题。这给你的应用增加了一丝人性，同时向用户表明你在乎他们的个人体验。

想了解“反馈”类弹窗的更多秘诀，我们建议你读Nick Babich的这篇文章，讨论对话框设计的5条重要原则。

挥洒你的才华

我们不是要粉饰任何事情。最终有些用户仍然会看到这样的弹窗：

图片来源：OSXdaily.com

但也并非人人如此。你有能力轻松改善弹窗，让使用与转化增长。首先，要确保你拥有一个移动应用数据分析平台，例如这个，Appsee，能使你监控它们的表现和用户体验效果。这些洞见可以让你自信满满地迭代、测试和验证。弹窗可能名声不怎么样，但利用深思熟虑的策略，它们会给你的移动应用带来重大转机。

作者信息：Hannah Levenson

原文链接：http://usabilitygeek.com/mobile-app-pop-up-guidelines/

译文链接：http://colachan.com/post/3563

当你将弹窗设计及使用得恰到好处时，它们就会是非常有效的用户界面元素。它们能帮助用户快速且便捷地达成目标。然而当错误使用时，弹窗却会困扰你的用户。知晓如何设计弹窗，会帮助你在使用时避免那些可能对用户造成的困扰。
 

什么是弹窗？

弹窗是一个为激起用户的回应而被设计、需要用户去与之交互的浮层。它可以告知用户关键的信息，要求用户去做决定，抑或是涉及到多个操作。弹窗越来越广泛地被应用于软件、网页、以及移动设备中，它可以在不把用户从当前页面带走的情况下，指引用户去完成一个特定的操作。

图1，会话过期弹窗
 

现在让我们来看看有哪些优秀的弹窗设计和使用方法。
 

原则1. 减少干扰

由于弹窗会中断操作，要尽可能地少使用弹窗。突然出现的弹窗会强迫用户去停止他们当下正在进行的任务，并转而专注于弹窗中的内容。在继续之前，用户必须要面对这个弹窗，否则将无法对弹窗之下的页面进行操作。当这个用户必须要确认一个关键的操作时，这就是好的，但是在大部分情况下弹窗是不太有必要的，甚至会引起用户反感。
 

需要确认

在你需要用户去互动才可继续时，或当犯一个错误的成本会很高时，使用弹窗是最合适且最合理的。

图2，这里告知了用户一个情况，需要用户确认
 

不要突然打开弹窗

在用户没有做任何操作时突然打开弹窗，是非常糟糕的设计。许多网站用订阅框来轰炸它们的用户，就如下面的例子：

图3，诸如此类的弹窗给没有键盘的用户造成了数不清的麻烦
 

弹窗的出现应该永远基于用户的某个操作。这个操作也许是点击了一个按钮，也许是进入了一个链接，也可能是选择了某个选项。
 

小结

• 不是每个选择、设置、或细节都有必要中断用户当前的操作。
• 弹窗的备选方案有菜单以及同框内的扩展，这两种控件都可以保持当前页面的延续。
• 可不要突然跳出弹窗，应该让用户对弹窗的每次出现都有心理预期。

原则2. 弹窗应与现实世界相关连

弹窗应该使用用户的语言（用户熟悉的文字，短语和概念），而不是一些系统特有的专有名词。
 

表述清晰的问题和选项

在弹窗的内容区域，应该使用一个表述清晰的问题或陈述，例如“清除您的存档？”或“删除您的账户？”总之，应该避免使用含有歉意的、模凌两可的、或者是反问式的语气，如“警告！”“你确定吗？”

图4，左边的弹窗提出了一个很模凌两可的问题，并且这个操作可能影响的范围并不明确；右边的弹窗提出的问题相当明确，它解释了此次操作对用户的影响，并且提供了指向清晰的选项
 

尽可能不要给用户提供可能产生混淆的选项，而应该使用那些文意清晰的选项。大部分情况下，用户应该能够只通过弹窗的标题和按钮，就了解他们有哪些选项。

反例：这个按钮的文字“不”的确回答了弹窗内的问题，但是并没有直接告诉用户点击后会发生什么。

图5，安卓的系统弹窗 来源：MATERIAL DESIGN
 

改成这样：肯定的操作文字“放弃” 很明确地指示了选择这个选项的后果。

图6，安卓的系统弹窗 来源：MATERIAL DESIGN
 

提供重要的信息

一个弹窗不应该把对用户有用的信息说得含糊不清。举个例子，如果一个弹窗要让用户确认删除某些条目，就应该把这些条目都列出来。

图7，这个弹窗很简要地指明了这个操作的结果
 

另外，避免使用“了解更多”按钮去连接到帮助文档；在弹窗同一页面展开则是更好的选择。如果还需要显示更多的信息，则将其放在进入弹窗之前的页面。
 

提出有（关键）信息的反馈

当一个流程结束时，记得显示一条提示信息（或视觉反馈），让用户知道自己已经完成了所有必要的步骤。

图8，在完成一个操作后成功的例子
 

小结

• 在弹窗中使用语意清晰的问题和选项。
• 设计促进操作完成的弹窗。
• 在操作完成后，提示用户操作已经完成了。

原则3. 讲求极简

别试着把太多东西挤在一个弹窗内。要保持干净和简约（遵从KISS原则）。然而极简主义并不意味着被局限住，你提供的所有信息都该是有价值并且与之相关的。
 

元素与选项的数量

弹窗绝不应该只是部分显示在屏幕上。因此不要使用有滚动控件的弹窗。

反例：巴克莱银行的付款处理弹窗包括了许多的选项和元素，部分的选项只有滚动后才能看到（特别是对于屏幕通常较小的移动设备）

图9，来源：巴克莱
 

好的例子：Stripe使用了一个简单并且聪明的弹窗，只显示了最基本的信息，这样不管在桌面端上还是移动屏幕上看起来都会很不错。

图10
 

操作的数量

弹窗不该提供超过两种选项。第三个选项，例如下图的“了解更多”，有可能会将用户带离此弹窗，如此用户将没有办法完成当前的任务。

图11，“LEARN MORE”操作将用户从这个弹窗指引到其它页面，进而把当前的弹窗置入一个不确定的状态
 

勿将多个步骤放置在一个弹窗内

把一个复杂的任务分解成多个步骤是一个极好的想法。然而这也会给用户传达一个信号，这个任务太复杂了，以至于根本没法再一个弹窗界面中完成。

图12
 

如果一个交互行为复杂到需要多个步骤才能完成（如下图的例子），那么它就有必要单独使用一个页面（而不是作为弹窗存在）。

图13，有多个步骤的弹窗 来源：DRIBBBLE
 

小结

• 如果你发现你在很努力地把许多元素挤进一个弹窗，这通常代表弹窗已经不是最优的设计方案了。
• 将那些不必要的、不能够帮助用户完成任务的元素或内容从弹窗中去除，以达到简化的目的。
• 尽量避免在弹窗内安置多个步骤。

原则4. 选择适当的弹窗种类

弹窗大致分两个大类。第一大类为吸引用户关注的模态弹窗，强制用户与之交互后才能继续。模式弹窗通常被用在独立、强制的流程中：

• 当不需要上下文就可以决定怎么做的时候。
• 需要明确的“接受”或“取消”动作才能关闭。在点击这种弹窗的外部时，它并不会关闭。
• 当我们不允许此用户的进程处于部分完成状态（即用户必须完成此进程才可做其他任何的操作）。

第二大类则是非模态弹窗，它允许用户通过点击或轻触周围就可关闭。

第一种模式弹窗只在特别重要的交互操作时才须使用，（比如：删除帐户，同意协议）。

图14，模态弹窗：用户必须输入“DELETE”才能确认删除
 

另外移动系统的弹窗通常是模态的，并且含有如下的基本元素：内容，操作，和标题。

图15，安卓模态弹窗
 

原则5. 视觉一致性

弹窗下的背景

当打开一个弹窗时，后面的页面一定要稍微地变暗。它有两个功能，第一它把用户的注意力转移到了浮层上，第二它让用户知道后面的这个页面是不再可用的。

图16，安卓的模态弹窗
 

在调节背景深度时要注意了。如果你把它变得太暗，用户就没法看清背景的内容。如果你调得太浅，用户可能会认为这个页面仍然可操作，并且甚至不会注意到弹窗的存在。
 

清晰的关闭选项

在弹窗的右上角应该有一个关闭的选项。许多弹窗会在右上角有一个“x”的按钮，方便用户关闭窗口。然而，这个“x”按钮对于一般的用户而言并不是一个显而易见的退出通道。这是由于“x”按钮通常较小，它需要用户准确地定位到该处，才能够成功的退出，而这一过程通常很费事。

因而让用户通过点击非模态弹窗的背景区域去退出，就是一个更好的方法。

图17，TWITTER同时使用了点击X按钮和点击背景区域的退出方式
 

避免在弹窗内启动弹窗

应该避免在弹窗内再启动附加的小弹窗，这是因为此举会加深用户所感知到的网站或app的层级深度，从而增大了视觉的复杂性。

图18，反例：弹窗中的弹窗
 

小结

• 在大部分情景下，都允许用户通过点击或轻触来关闭弹窗（除了模态弹窗）。
• 应该避免在弹窗内再启动附加的小弹窗（即弹窗中的弹窗）。

总结

希望这些有关弹窗的使用案例和使用方法还算有趣，并能在你们设计原型时派上用场。要记住，用户体验是为用户而做的设计，而非为技术。要想知道什么样的设计最适合你的用户、最适合他们将进行的任务，其实不是一件难事：你只需要模仿那些领先产品的弹窗，然后找到你的用户做一些相关的测试。

英文原文：NICK BABICH, UX DESIGN: 5 ESSENTIAL UX RULES FOR DIALOG DESIGN

原文地址：http://babich.biz/5-essential-ux-rules-for-dialog-design/

译文地址：http://ddc.dianrong.com/?p=467