2023年B端交互组件之弹窗篇

B端交互组件之弹窗篇我们常说的用户的认知力量与系统的反馈，这里的反馈许多时候会用到弹窗组件，包括强提示和弱提示。

有时候一个简单的场景需要拆分，我们便会对一个页面进行优化，把一些功能通过弹窗形式来展现；例如：个人信息页面，包含许多分组，主界面是分组的集合，每个分组通过弹窗打开来维护；这样可以把简单的表单简化，分段维护。

交互设计可以简洁理解为把简单转移给系统，把简洁留给用户，让用户更多的感受便捷化、智能化。

类似的状况还有许多，下面我会从操作性和提示性两方面来聊聊B端产品中的弹窗。

一、操作性弹窗

操作性弹窗主要是一些表单类、配置类界面，例如新增、导入、设置等。

有些人可能说新增可以设计成标签页形式，作为独立的页面存在，不过这里是讲弹窗，所以暂不考虑这种状况；啰嗦一句，假如是页签形式，新增提交后，页面要消逝，并且要把值传给父级页面。

比较常见的是弹窗形式，新增提交后，弹窗消逝，值传给父级并自动刷新页面。

1.简洁场景

表单输入项不多，或者页面内容不多的状况，可以看成简洁场景；一个弹窗页面只需要把一个功能完成好，没有太多关联性的操作，例如输入内容不多的新增弹窗。

另外类似于批量查询、导入这类操作，弹窗中还需要再弹个弹窗去执行导入模板的操作，这种状况还是可以归于简洁场景。

小结：简洁场景差不多就是表单内容不多、功能单一、业务简洁的操作性弹窗。

2.简单场景

表单输入内容许多需要分组，或者有许多需要关联的操作，可以看成是简单场景。

要么是一个主体弹窗，包含许多再弹开的弹窗。

如下图所示：

或者是就在一个主体弹窗内，通过分组、TAB、分步等来优化简单业务。

1）弹窗TAB

这里的TAB不是指页签，而是在弹窗内部用TAB进行分组。以前设计CRM系统时，新增会员信息部分就采纳的这种方式。

其实也不代表这种方式有多好，主要是技术上当时弹窗尺寸需要固定，写成公共样式，有的内容许多，有的内容很少，为了兼容多种状况，才考虑这种TAB分组。

如下图所示：

这里有个留意点，就是必填字段问题，由于字段信息都影藏到每个TAB标签中，不能一眼看到哪些字段是必填，以及必填未输入时如何提示，我以前是设计成小三角放在标题右顶部。

如下图所示：

当影藏的TAB标签中有必填字段未填或者其他校验信息提示时，可以采纳红标方式来提示用户，当用户切换到红标TAB时，即可查看弹窗无法提交的缘由；问题全部解决后，红标才会消逝，当前TAB问题则可以直接看到。

2）分组弹窗

在弹窗内将字段信息全部绽开，但是其中一部分字段又属于同一类型的，这时可以采纳分组信息来区分；分组弹窗可以将字段信息条理化，便于用户输入信息，可以理解为提高了用户的认知力量。

字段信息可以全部顺排，也可以按数量横向排列，例如一排摆2个字段，需要依据整体界面结构来设计；另外还需要考虑下系统反馈时的展现方式，例如是放在信息框右侧、底部、浮层提示等。

如下图所示：

3）分步弹窗

在弹窗内部将字段信息按先后挨次分开，这种就叫分步弹窗，这种设计有个要点，就是其次步操作的数据需要第一步来做支撑；假如不完成其次步，无法直接从第一步到第三步。

例如我之前设计的命题系统，一般是要先有大题，才能设计小题。

如下图所示：

可能有人会说，假如字段前后没有关联，是不是就不能用分步弹窗了，一般WEB端是采纳分组方式，移动端可以根据分步来；但是一般都不是必填的，用户可以后面有爱好时再去补充。

例如注册一些APP后，需要选择一些初始设置，以及填写个人资料，不过都可以不填直接跳过。

二、提示性弹窗

为了让用户可以更好地使用产品，需要产品有很好的反馈力量，本次主要说的就是系统的反馈了，也就是提示性弹窗——我们在对系统发出指令后，都盼望系统能给我们正确的反馈，好知道自己做的对与不对，以及如何进行下一步操作等等。

下面我将从三个方面来聊聊提示性弹窗，即弱提示、强提示、二次确认。

1.

弱提示弹窗

从字面上，我们可以得知，这种弹窗对用户的打搅不大，只是做到提示和告知，比如用户操作某个功能后，系统将结果反馈给用户，常见的就是新建胜利、删除胜利等。

不过这里要区分下，用户输入指令给计算机后，计算机运算后得出结果并将结果反馈给用户，这种可以称为toast提示。

用户一些简洁的鼠标操作，例如滑过、点击、悬停等，系统在前台即时给出一些反馈；这种可以理解为广义的弹窗，其实就是一些浮层，我们可以称为tips提示。

1）toast提示

用户点击新建按钮，系统弹出新建弹窗，当输入必填字段并确定提交后，系统会以toast形式提示用户，该新建操作胜利；例如“新建胜利”，该弹窗停留片刻后便会自动消逝，同时新建弹窗消逝，并且会刷新列表并新增一条数据。

以上便是我们常见的新建操作流程，其他操作也是类似的，例如修改和删除等。

这种提示一般会停留个几秒便会自动消逝，并不需要用户进行强确认，用户是不是真的知道了，系统不会去管了。

如下图所示：

2）tips提示

用户将鼠标悬停在输入字段右侧的问号图标上，系统会将字段输入说明以tips形式告知用户，鼠标滑出问号图标的感应区域后，该浮层提示会消逝，再次悬停则会再次消失。

如下图所示：

另外在导航菜单上，假如文字太多，会将多的文字以省略号形式呈现，当鼠标悬停在文字上时，同样会有tips提示消失，展现完整的文字信息。

正常的方式还是需要精简导航菜单文字，这种设计方式只是用来补救糟糕的用户体验的。

还有一个可能用到的地方就是TAB文字了，TAB页签一般是会给一个固定宽度的，文字太多，也是需要用省略号，同理鼠标悬停时可以看到tips提示的完整文字信息。

2.

强提示弹窗

当系统给用户反馈后，并且需要强制用户确认时，就是我们要说的强提示弹窗了。

一些比较重要的通知，例如：系统版本过低某些功能不支持、用户的某些操作会造成一些什么后果等。

一些比较重要的反馈并且需要确保用户已经知道的场景下，我们就可以使用强提示反馈，假如用户不去响应反馈，系统不会让用户进行其他操作，所以我们叫做强提示弹窗。

通常的做法是给一个用户反馈的按钮，例如：确定、知道了等，用户点击该按钮，该提示弹窗则会消逝，这里对于反馈的文字和按钮可以体现出情感化设计，可以劝慰用户被强制操作后的失落心情。

如下图所示：

还有种强提示是需要输入数据的，比如：审批同意时，审批人需要确定一个时间范围，这时系统便会强提示用户输入一个结束日期，当然这只是一种设计方式；也可以把这个结束日期字段放到审批界面去，在做审批同意操作时作为必填字段校验。

3.

二次确认弹窗

一般用户的某些不行逆操作，在操作时需要让用户二次确认；假如用户还是要连续操作，则系统执行该操作，假如用户取消，则关闭该操作。

二次确认弹窗主要是为了避开用户误操作，造成无法挽回的损失，所以一些不行逆的操作进行时，需要用户进行二次确认；同时弹窗的文案也能提示用户当前正在进行某些不行逆的操作，想清晰再打算，给用户一次谨慎思索的机会。

如下图所示：

二次确认比较经典的就是用于删除操作时，由于删除后该数据就彻底找不到了，只能重新建一条一样的数据；假如是通过上游传过来的数据，本系统可能还需要掌握权限，只有特定权限的用户可以删除。有时候为了避开数据丢失，也会有软硬删除之分。

系统删除时，只是放到回收站或者其他特定地方，这种叫软删除；当清空回收站时，就真的不再存储该数据了，这种就叫硬删除。

有些系统可能没有删除功能，依据业务场景，在满意特定条件后系统自动批处理删除掉数据。

三、总结

弹窗可以用来操作数据，也可以用来反馈，详细如何使