前言
在所有涉及人机交互的产品领域，反馈都是机器传达给用户的最直接的信息，也是提升用户体验的关键因素之一。C端产品由于设备、技术的多样性，导致反馈可以从视觉、听觉、触觉等多方面进行，给用户带来各种不同的感官效果。 但是在B端平台上，更多的产品形态还是在PC网页端操作实现，反馈类组件的使用样式、效果都会受到限制。大多数情况下，B端的反馈组件主要以弹窗形式为主，所以在这篇文章中也以弹窗展开来讲述，也期望能解答设计师在使用弹窗过程中的一些疑惑…
首先我们聊聊大众对弹窗的印象。早在PC的远古时代，满屏弹窗的名场面就时不时会出现。而早期没有自动保存功能的Photoshop，也会经常出现让人绝望的崩溃弹窗，不管点哪个按钮，结果都是直接关闭软件。
经过多年的教育，用户对弹窗早已经产生了条件反射，页面上出现弹窗的第一反应就是：“是不是又出错了？”，同时鼠标的操作就是去找关闭按钮。
既然弹窗的使用效果对于用户而言比较负面，那么设计师在设计当中遇到弹窗时该如何处理呢？接下来重点讲一下规范当中关于反馈弹窗设计要点。
01基本介绍
1.1 什么是模态
在真正开始弹窗设计的讲解之前，先和大家统一个基本概念——“模态”。很多情况下设计师都在讲“模态弹窗”“非模态弹窗”，这里所指的“模态”究竟是什么？
“模态”是英文modal的翻译，词源自于mode，表示“模式的，情态的”。模态弹窗引申为“某一特定状态下的窗体”。接下来就是基于“模态”概念引申出的弹窗的分类。
1.2 弹窗的分类
（1）模态弹窗
在页面流程中，模态弹窗是附属于主窗口的图形控制元素，它创建了一种状态模式，在这种状态模式下，主窗口无法被直接访问。对于用户操作而言，模态弹窗的出现会打断用户的操作行为，强制用户必须进行某种操作，而无法进行其他操作。
因此，如果不恰当地使用“模态弹窗”，则会影响用户操作界面时的“控制权”，容易令用户产生厌恶感，尤其是在用户被动且无前提感知的情况下出现时，这种负面情绪就变得极为明显。
（2）非模态弹窗
非模态弹窗，顾名思义，允许用户在处理非模态弹窗的同时对主窗口进行操作。其不会阻断用户原来的操作流程，用户亦可以不与回应，通常有时间限制，出现一段时间就会自动消失。
那么设计师在设计过程中，如何对两类弹窗进行区分使用呢？
核心点就在于是否打断用户当前操作的流程，并强制用户进行交互。具体使用场景，将会在文章后面一一列举。
1.3 弹窗的组成元素
窗体容器（必需）
标题
主体内容（必需）
可以有很多种类的信息展示，从单一的一行文案到复杂组件集合都可容纳，可视业务需要进行选取应用；
功能按钮
退出按钮
模态蒙层
作为模态弹窗的显著标志，提示用户此时主窗口内容是屏蔽、不可用的。
02设计原则
<br />弹窗的设计原则主要包括：减少干扰、易读性、讲求极简、视觉一致性四个方面。
2.1 减少干扰
众所周知，反馈是需要及时呈现给用户的，但是却不能滥用，尤其在使用模态弹窗这一类高度吸引用户注意力的弹窗时。此时弹窗的出现意味着会极度干扰用户。我们只有当需要呈现的信息足够重要的时候，或者别无选择的时候才使用弹窗进行信息和功能反馈；
另外，反馈是与用户的页面操作行为对应的，一定不是无缘无故突然出现，再加上弹窗本身对于流程的强阻断性，这就意味着反馈弹窗的出现必须基于用户的某个操作，让用户有足够的心理预期。
例如下图中常见的邀请评价弹窗，就会在操作时毫无征兆地出现。在进行手机导航时突然弹出邀请评价的对话框，就会非常打扰用户，并且有可能因为此弹窗导致走错路线。
2.2 易读性
易读性主要针对弹窗中的信息而言。问题描述和选项的文案表述要足够清晰易懂，尤其关键行为的用词要一致；下图中上方的弹窗就是一个反面案例。从图中可以看到，对话框主标题的谓语使用了“删除”，但是文案描述提示的是“务必再次确认”，而最后操作主按钮的文案却是“确定”。先不论“确认”和“确定”的区别，“删除”和“确定”就没法对应上。尽管操作可能会正常进行，但是用户需要耗费更多认识去处理。
另外，我们也建议少用“是/否” 等过于简单的操作按钮文案，如当前弹窗是要执行某个操作，可直接在主按钮上描述具体操作，并且尽量明确告知用户此行为将会带来的后果，给予用户心理预期。下图中下方的案例就比较好地遵守了以上原则。
2.3 讲求极简
“极简”并不是指单纯的减少页面元素，则是通过设计手段减少用户看到的同质化的元素信息，本质在于让用户能够快速识别关键信息，顺利完成操作。
（1）操作按钮的数量尽量控制在两个以内
过多操作按钮，会增加用户的认知和选择决策的负担。如果由于业务或产诉求必须要增加时，则可以使用文字按钮的方式，与核心操作样式区分。如下图上方的案例中的“了解更多”按钮的设计方式，会导致跳转的操作，尽量要避免。
（2）避免用弹窗承载多步骤操作
使用弹窗承载复杂表单信息时，如果表单本身信息过多而需要把弹窗表单拆分步骤时，就会导致弹窗承载内容量过大；加之弹窗的关闭成本相对小，也难以保证用户完成填单的目标，如下图下方案例所示。因此这种情况下则需要考虑更换承载的组件来完成目标。
（3）要避免开启多重弹窗
在上文中已经给大家展示过多重弹窗，是毫无正向体验可言的。设计过程中需要增加屏蔽和限制逻辑，避免弹窗的堆叠出现。
2.4 视觉一致性
一言以蔽之，就是要求在同一个平台里保持相同组件的样式一致。比如下图中主体内容可滚动的弹窗，在组件库中提供了“以色块区分”和“分割线区分”两种样式。而我们在日常设计工作中，在一个平台内保持统一即可。
例如下图中的3个弹窗，他们次按钮的样式视觉强度分别呈从强到弱排列。设计师有时为了引导用户不去点击中断流程的操作（如最下面的“不同意”按钮），特意使用了较弱的按钮样式，而在平台内其他的对话框中，可能又使用回其他样式的按钮。其实原有组件规范中主次按钮的对比区分已经足够明显，这样的考虑倒是显得画蛇添足。
03应用场景
在弹窗的应用场景这部分中，我们主要会按类型来分析各种常见的反馈组件，同时会对一些应用场景细节进行补充说明。
3.1 模态弹窗
（1）Dialog对话框
Dialog对话框是弹窗中最典型的一种形式，适用于承载重要的信息提示、表单填写或者复合组件模块，会中断当前用户的操作流程。一般位于屏幕的中心，需要用户响应操作后关闭。对话框它的特点非常显著，是所有反馈类组件里用户吸引度最强的。下图展示的是对话框的三种主要形态。
依据使用场景和目标的不同，主要有以下几种细分类型：
信息确认类弹窗
是最常用的类型，通常来呈现需要用户确认的重要信息。
表单填写类弹窗
在工单提交等流程类的功能模块也会使用到很多表单填写类的对话框（包括对图片、视频、文档等处理），在此归为表单填写类。
内容展示类弹窗
内容展示类一般只承载较为单一类别的信息内容。下图案例所示的弹窗中承载了一个简单的表格。假如是表格列数很多的情况，同时可以考虑使用抽屉来展示。
宣传类弹窗
适用于重要消息提示和新功能宣传等场景。
（2）Drawer抽屉
Drawer抽屉的形式适用于内容较多的信息展示，可通过设置底部蒙层的形式来控制对当前操作流程的中断与否。抽屉一般从屏幕最右侧滑出，可选择是否中断当前流程（即是否需要用户响应方可关闭）。内容承载量极大是它的显著特点，可承载接近单一页面的内容量。
依据使用场景和目标的不同，主要有以下几种细分类型：
信息展示/回显类抽屉
常与主界面的表格配合使用，用于查看其中条目详情，作为展示、回显信息的模块，这样可以以最低操作成本实现条目查看的目的。
消息提示类抽屉
这一类抽屉相当于消息中心的一个预览区，能实现跳转到消息中心前的消息预览。如果在实际的项目中也有类似需要承载新开页面前的信息预览功能，抽屉类型的弹窗就非常适合。
功能操作类抽屉
需要用户重复打开并操作的内容，也适合使用抽屉。类似的应用场景有对表格中多条目的详情切换查看、平台全局功能（如购物车）等。
复杂功能类抽屉
最后一种是复杂功能类的抽屉，就是多功能模块的整合型抽屉，一般可以用作需要新开标签页的高频操作的替代方案，其实这种抽屉承载信息量已经跟单一页面不相上下了。
3.2 非模态弹窗
非模态类弹窗，可分为警告提示、全局提示、警告提示和气泡卡片四类。
（1）Alert 警告提示
Alert 警告提示，适用于需要引起用户关注的提示，但并不要求用户立即响应。放置区域视具体需求确定，一般为常驻形式出现，允许设置是否可关闭。此类提示的内容承载量不大，可配置标题和描述。
Alert 警告提示按照放置生效的区域，可以分成平台级、页面级和组件级三种。
（2）Message全局提示
Message全局提示，也就是我们常说的toast，它适用于轻量级的操作反馈，不会打断用户当前操作流程的简短消息提示。一般悬浮出现在顶导航下方，会自动消失。它是最轻量的反馈组件。
全局提示出现的位置，基本都位于页面上方居中显示。
（3）Notification 通知提醒
Notification 通知提醒，适用于需要告知用户的重要问题或失败状态，希望用户立即做决策，或者是反馈后台进程的结果；一般以右上角浮层形式出现（也可自定义位置），可动态出现，也可以是常驻形式，允许设置是否可关闭或自动消失。
通常情况下，通知提醒会从导航的消息提醒入口位置出现。
（4）PopConfirm 气泡卡片
PopConfirm 气泡卡片，适用于针对页面内操作/元素的确认提示或简易表单填写，相比模态确认弹窗会更轻量。一般通过点击按钮触发，需要用户响应方可关闭。
气泡卡片的应用场景可以分为两种，分别是确认提示类和表单类，都是针对页面内某个元素弹出的。例如常用的列表管理中的删除功能，又或者轻量的用户反馈模块。这是Dialog对话框弹窗的一个轻量替代方案，在我们使用对话框之前，可以考虑看气泡卡片能否满足需求。
3.3 补充
接下来我们再对一些日常比较困扰B端设计师的问题，进行补充说明 —— 对话框主次按钮的位置问题。这里主按钮的定义是指更希望用户点击的、对用户更有利的操作按钮。
（1）按平台适配
大家可以看到，除了windows以外，MAC和移动端iOS/Android都是把主按钮放在最右侧，如果我们设计的是单平台系统，便可以按照这个大原则来，和大部分的用户认知保持一致。
（2）浏览顺序
结合用户浏览网页时的「Z型扫描模式」以及「古腾堡法则」来进行分析，如果把“确认“按钮放在最右侧，则这将是用户浏览的终点。接下来，分析用户注视点的顺序。如下图所示，从注视轨迹A来看，如果用户最终要点击主按钮，则只需要经历两个注视点；如果是注视轨迹B（主按钮在左的情况），则用户在看完所有选项后，需要多往回移动一次眼球才能完成“确认”的操作，某种程度上增加了操作成本。
（3）参考步骤/流程顺序
从历史的角度来看，在计算机还没普及的时候，游戏机上的横版过关游戏早已确立了从左到右推进的设定，这种设定也是符合人机交互中的流程走向的，在后续的屏幕设置当中也延续了这种习惯。
再类比Progress类步骤组件，把推动完成流程的按钮放置在最右侧也是符合用户习惯的。
最终结合以上三个角度的分析可以得出结论，在设计跨平台的web端系统时，建议统一把主按钮放置在右侧（排除RTL语言系统）。
04总结
通过对弹窗类设计原则的总结，和各个组件的特点分析及应用场景的梳理，希望能让大家在涉及弹窗的设计需求中，能有更迅速的判断和更成熟的细节处理。
若有收获，就点个赞吧
0 人点赞
