本文来自我正在写做的新书《决胜体验设计》（暂定名），欢迎大家在写作过程中给我提建议、期望、不足、错误！新书写作完成内容会持续在公众号更新！
本推送是第8章“微交互与设计范式”第2节剩余的内容。
在上篇文章B端产品的微交互与反馈系统设计（上）我们讨论了微交互、反馈系统的概念，并介绍了一部分反馈系统涉及到的组件，本篇继续介绍反馈系统中需要用到的剩余组件和范式，以及反馈系统设计的方法论和要点。
通过本文学习，你应该能够给自己的产品定义一套人机交互反馈系统设计规范，提升产品整体的用户体验！
PS：写作本文时我做了个噩梦，梦到新书还没发行，某原型制作工具将本文作为语料学习理解后，把文中的原创方法论变成了AI能力，产品经理做原型时AI直接给出了设计规范和修正建议，产品经理和设计师不再需要阅读学习本文的方法论。。。
组件：模态对话框和非模态对话框（Modal & NonModal Dialogs）
在窗口程序设计中，窗口界面分为两种，模态对话框和非模态对话框，这是非常重要、核心的基础概念。
模态对话框，是指对话框弹出后，用户无法操作对话框背后的窗口界面。经典的模态对话框例如Excel程序中的保存对话框，如图8-17左图。
非模态对话框，是指对话框弹出后，用户依然可以操作对话框背后的窗口界面。经典的非模态对话框例如Excel中的查找替换功能，用户在查找替换窗口打开后，依然可以操作编辑背后的表格数据，如图8-17右图。
图8-17 Excel中的模态/非模态对话框
模态和非模态对话框是非常重要的概念，因为对话框和弹出窗口本身是软件设计中非常常见的交互组件，产品经理在设计弹出界面时，必须决定界面是以模态还是非模态的形式弹出，模态对话框（或模态窗口）会中断用户操作，而非模态对话框（或非模态窗口）则不会打断用户操作。这两类形态没有好坏对错之分，而应该在不同的场景下选择不同的设计。
理解了模态和非模态的概念，接下来我们介绍SLDS中对话框相关组件。
组件：错误/警告非模态气泡（Error/Warning Nonmodal Popovers）
错误/警告非模态气泡，是SLDS中独有的组件，在其他商业软件中比较少见。该组件以带有指向箭头的气泡框，给用户进行较为明显的提示，组件形态如图8-18。
图8-18 错误/警告非模态气泡：对用户进行指向性强提示
SLDS中该组件有两种样式，分别是黄色的警告框，和红色的错误框，而没有灰色的信息框，说明SLDS认为该组件是针对重要通知情况设计，不应该随意使用，如图8-19。
图8-19 SLDS中非模态气泡的三种样式
图8-20展示了非模态气泡在Salesforce中的实际应用。在表单编辑页面中，如果用户输入数据不符合要求，除了后边要介绍的行内校验提示，当用户点击保存按钮后，表单界面按钮旁边会出现红色的警告图标，上边会弹出警告非模态气泡，提醒用户有哪些字段内容不合规，需要修改后再提交。
图8-20 Salesforce的表单编辑界面点击保存后提示警告非模态气泡
组件：提示框（Alert Dialog Box）
提示框是一种常见的模态对话框，弹出时强行打断用户操作，用户必须点击确定后才会关闭返回原操作界面，如图8-21。
图8-21 提示框：中断用户的强提醒
当然也可以把提示框做成非模态形式，但没有什么意义，如果想给用户提醒又不影响用户使用系统，完全可以采用其他更合理的组件或设计范式实现。图8-22展示了Salesforce产品中的一个模态弹窗提示。
提示框是一种重度提醒，需要谨慎使用,我曾经见到过某些系统，异步处理完某个流程后，居然用提示框告知用户，感受实在不好。既然都是异步操作了，说明用户并不需要马上知道结果，为什么还要用模态对话框大段话用告知结果呢？这就是明显的交互设计问题。
图8-22 Salesforce中的提示框
组件：确认框（Confirm Dialog Box）
确认框是另一种常见的模态对话框，用户操作被打断，用户必须做出选择，从而执行下一步逻辑，如图8-23。
图8-23 确认框：中断用户要求做出选择
确认框常常用在需要用户做二次确认的重要操作场景，例如重要数据的提交，数据的修改，数据的删除，数据的清除等，因为B端产品很多操作场景是不可逆、不可恢复的，如果用户误操作，没有二次确认，会带来难以挽回的损失。图8-24展示了Salesforce产品中删除数据时的二次确认。
图8-24 Salesforce中删除数据时的二次确认
不知道大家还有没有印象，Windows10以前删除文件时都会弹出对话框让用户做二次确认，但是Windows10及以后版本，默认都将二次确认的设置关闭了，刚开始使用Windows10以后，我有很长一段时间都不太习惯这个改变，觉得Windows团队做了一个糟糕的设计，因为私自单方面调整了默认操作逻辑；但后来用习惯以后又觉得挺方便，因为一般用户不太可能以为误操作删除文件，所以二次确认好像确实没有必要，反正现在我也习惯了没有二次确认的文件操作。但这里就带来了两个思考：
1、给用户选择的权利：单方面改变用户的操作习惯往往让老用户很不爽，常见的做法是给老用户一个提示让他自己做选择，而对新用户直接采用新设计，因为新用户还没有形成操作习惯。很多B端软件界面做了重大升级后，往往不敢废弃老的界面，而会并行很长时间。
2、老用户的习惯很难改变：然而一般保留了老的界面和交互，老用户就很难切换到新版本的界面了，即便新版本交互更合理。B端产品经常会遇到一个尴尬的局面：老用户天天吐槽系统难用，但如果你问老用户，要么给你上一套新系统，对方却又连连摆手摇头。解决这类问题，只能耐心的慢慢引导改变，一刀切是不现实的。
范式： 行内校验（Inline Text）
行内校验是一种设计范式，而非标准组件。行内校验，是指用户输入数据时，如果录入内容不符合要求，应该在用户录入过程中（或录入完成焦点离开控件后），在录入组件旁边及时提示，以便用户能快速定位问题修改而不应该等用户点击提交后才得知哪里录入有问题，如图8-23。
图8-23 行内校验：对输入项进行及时校验和提示
行内校验的设计范式已经成为数据录入校验的标准做法，不论是C端还是B端，现在已经很少看到提交时才校验数据的做法，因为这样效率非常低。图8-24展示了Salesforce的表单编辑页面中的行内校验效果。
注意，虽然在前边我们介绍了Salesforce的表单编辑页面在点击保存时，还会通过错误/警告非模态气泡进一步提示录入错误的数据项，但这只是Salesforce很独特的处理办法，大多数产品只需要实现行内校验就足够了。
这里有个小细节，大家可以自己思考一下，当用户录入数据有不符合要求，但是依然点击了提交按钮，此时，系统该如何告知用户录入数据有误呢？是应该弹窗提示呢？还是用Toast呢？还是没有任何提示呢？
图8-24 Salsforce表单的行内校验
范式：空状态（Empty States）
空状态字面意思是用户访问页面没有数据时的情况，作为一种设计范式，是指在没有内容的情况下，界面该展示什么，期望用户了解什么，引导用户做什么，如图
图8-25 空状态：没有数据时该展示什么
空状态有三种典型情况和几种处理方案：
情况一：用户第一次使用。
方案1：对用户进行功能简介和操作引导；
如图8-26，展示了Salesforce Service Cloud产品（客服系统）的工单列表页，作为新用户第一次访问功能，还没有任何数据，在数据结果集区域展示了一张图片logo，下边有两行字：“在这里可以跟踪记录客户服务支持情况：工单可以记录来自不同渠道的客户建议、疑问、问题。”，底部有一个按钮：创建一个工单。（虽然界面右上角就有一个“添加”按钮）。
这样的信息引导，可以减少用户的困惑和焦虑，让手足无措的新用户简单理解功能，并引导用户创建数据感受功能。
图8-26 Salesforce中的空状态设计
情况二：用户进行查询操作，没有查询到结果。
方案2：结果集部分显示未查询到结果（已经很少这样设计）；
方案3：采用方案1的同时弹出一条toast显示没查到结果；
情况三：出现错误，例如断网、数据库链接失败。
方案4：在结果集部分提示网络异常或连接异常（已经很少这样设计）；
方案5：采用方案1的同时在全域通知条中提示系统级错误信息；
整体而言，方案1是低成本保证用户体验的选择，可以作为标准方案采纳推广；方案3和方案5可以依情况选用。
8.2.4 反馈组件的三种提醒程度
以上介绍了若干组件（以及范式），这些组件对用户的干扰程度有轻有重，我们将提醒程度分为三个级别：
轻度：组件和消息会自动消失，用户无需额外操作。
中度：不打断用户，用户可以选择忽略或处理。
重度：用户操作被打断，用户必须响应或者等待足够时间才能继续。
请大家不要往下阅读，先做一个练习，思考并判断前边介绍的组件和范式分别属于哪种提醒程度，这个练习可以增强大家对组件的理解和记忆，从而在后续形成自己的设计思路。
接下来，是我自己的总结归类，当然这个归类并非正确答案，只是一种归类方式，供大家参考，如表8-1。
轻度：因为只有吐司提示会自行消失，所以是最轻度的提醒方式。
中度：全域通知条、页内通知条、错误/警告非模态气泡、行内校验，不会打断用户操作，也不会自行消失，需要用户完成操作，或自发点击关闭，或依据系统状态自动消失。
重度：这类组件、范式会打断用户操作，用户必须等待或者给出反馈，才能继续。提示框、确认框、状态按钮都是典型的重度提醒组件；加载占位图放在这里略有牵强，不过没有更合适的位置，我只是借用地方放在这里。
表8-1 不同组件和范式的提醒强度分类
8.2.5 不同触发时机下反馈组件的选择
不同的提醒程度，对用户的影响干扰区别很大，在不同场景下，采用不合理的组件，会对用户体验产生较大影响，接下来，我们讨论针对不同触发场景，该采用哪些组件。
我把触发场景分为两大类，一类是系统触发，一类是用户交互触发。系统触发场景系统触发又可以划分为两类，分别是系统级通知、模块（页面）级通知。
系统级通知：系统级别的重要信息，包括了公告、严重错误，例如Session过期、网络中断、数据库断连；你可以选择弹窗提示，也可以选择对用户介入较轻的通知条。不过，模态弹窗时刻要谨慎使用，大家可以回想下，是不是有些系统设计，超时不操作会话过期，会弹窗把你踢出系统，这种感受是非常糟糕的，更柔和的做法是进行提示但不踢出，用户还可以浏览之前打开了缓存了的页面。因此，针对系统级通知场景，我推荐的组件是“全域通知条”。
页面级通知：有些时候，用户停留在页面时，有些异步任务执行结束，需要给用户进行信息提示，这些都是针对页面或功能模块级别的提示，在SLDS中，设计了“页内通知条”组件，来呈现这类消息。例如，某个异步下载任务结束。交互触发场景交互触发场景，是由用户通过某些动作产生的触发，例如敲击键盘、点击鼠标、拖拽屏幕等。用户动作出发后，有两种情况，一种是立马反馈结果，一种是执行瞬间等待。首先分析“立马反馈结果”的情况，toB软件，本质上交互操作都是增删改查操作（CRUD，Create，Read，Update，Delete），因此，我将触发时机划分为查询、增加修改、删除三类，每一类又划分出成功和失败两种情况。
查询成功：查询成功后，直接呈现结果，这本身就是一种反馈，所以反馈设计中不用再做其他通知。
查询失败：如果没有查到内容，需要采用空状态 设计范式，给用户进行提示，并引导下一步动作。
增加/修改成功：数据创建成功后，可以采用吐司提示，非常轻度的告知用户已成功。很多toB软件只有创建失败才有反馈，创建成功没有反馈，更优雅的做法，是通过toast弱提醒用户。
增加/修改失败：不论是创建新数据，还是在表单修改老数据，如果保存失败，应该告知用户失败的原因，对于不合规字段，要能清晰提示错误字段。在SLDS中，同时采用了“行内校验”和“错误/警告非模态气泡”来告知用户。
删除操作：一般删除数据需要弹出选择框让用户做二次确认，这是一种习惯性反馈设计。
删除成功：通过吐司提示轻度告知用户即可。
删除失败：如果在列表页删除数据，可以考虑弹出模态对话框提醒用户告知原因，如果在表单删除失败，可以在表单内弱提醒，也可以弹出模态对话框提醒。最后简单说下执行瞬间的反馈设计，如果是页面加载等待，可以采用“加载占位图”，如果是逻辑执行中，可以采用可自行消失的模态对话框，或多态按钮。
将以上各种情况汇总得到表8-2，供大家参考；在实践中，产品经理和设计师团队应该制定自己产品的组件库，以及类似的表格，约定产品不同触发场景下的组件选择规范，从而保证整体交互风格的一致性，避免产品经理凭个人喜好来设计反馈交互。
表8-2 不同触发场景下的反馈组件选择
8.2.6 移动端的反馈组件设计
上边讲到的都是PC端的反馈系统设计，思路同样适用于移动端。
Apple的设计标准组件库是SwiftUI，安卓的是Material3，两者的设计思想和设计组件有很多不同之处，如果可能，需要制定不同的设计标准和规范（大多数B端产品经理并不熟悉不同移动端的最新设计规范，最好由专业的体验设计师协助）。
例如，PC端经典的Toast组件，在安卓的体系中，通过一个叫做Snackbar的小组件来实现，如图8-27。
图8-27 安卓生态用来替代Toast的Snackbar组件
IOS没有官方的Toast组件，需要程序员自己写代码，或采用一些第三方的组件来模拟Toast，比较有名的有Github高分项目MBProgressHUD，如图8-28。
图8-28 GitHub中模拟Toast的IOS开源组件
8.2.7 反馈系统设计的场景四问
我们已经介绍了反馈系统设计三要素，包括出发场景、选用组件和提醒程度，这三个要素，应该设计成反馈系统的用户体验设计规范，要求所有产品经理遵循。
在遵循规范的同时，产品经理设计反馈系统还需要考虑业务场景的上下文，在设计反馈交互的过程中，从用户的视角，时刻思考并回答四个问题：
我在哪里：任何反馈触发前，用户都必须知道在产品的具体位置，从而判断上下文，否则用户会感到困惑和混乱。
刚刚发生了什么：绝大多数反馈都是瞬间给出结果，例如弹出消息，告知成功与否，用户要知道刚才的交互的结果是什么。
正在发生什么：某些时候，事件发生后，执行需要一定耗时，用户需要等待，系统需要告诉用户正在发生什么，例如读取中，支付中；如果预测需要一定的耗时，还应该给用户一个预估时间，例如程序包的安装中，提示安装进度和剩余时间。
将要发生什么：如果需要，还应该给用户下一步动作的引导，或对后续工作的提示。例如，针对会话过期的Toast提示，可以在文本中加入“重新登录”的超链接。
只有同时考虑到用户旅程和操作上下文的反馈系统设计，才是完整的、体验良好的。
8.2.8 反馈系统设计的四个要点
最后，针对反馈系统设计，我们再总结四个设计要点：
时效性：在合适的时机提示合适的内容，并不是所有交互都需要反馈（例如查询成功）。
清晰性：只呈现必要的内容。
引导性：需要的时候，要引导用户下一步该做什么。
跨设备：需要的时候，要在多设备提醒，但是一旦用户已读，其他设备的消息要被消除。
我们将反馈系统设计的三要素、场景四问、四个要点总结在一张图中，方便大家记忆，如图8-29。
图8-29 反馈系统设计总结
