本文来自我正在写做的新书《决胜体验设计》（暂定名），欢迎大家在写作过程中给我提建议、期望、不足、错误！新书写作完成内容会持续在公众号更新！
本推送是第8章“微交互与设计范式”第1节、第2节（部分）的内容。
第8章 微交互与设计范式
什么是人机交互的反馈系统？
为什么说反馈系统对产品体验至关重要？
为什么用户总是抱怨消息多到无法阅读？
如何设计良好的消息系统？
如何设计触达系统让用户快速理解上手新功能？
组件和控件有什么不同？
自研系统该不该将组件标准化抽象化？
自研系统和商业化软件交互设计的异同点是什么？
产研部门是否该建设大前端团队？
8.1 微交互与设计范式
8.1.1 什么是微交互
我们已经讨论了几个层面的用户体验。
在功能层面，产品经理通过合理的功能抽象、菜单编排、导航设计，让用户对产品的整体信息框架和功能页面有一个清晰地认知，知道从哪里找到需要的功能。
在界面层面，设计师通过美观的界面元素排版、配色，确保用户以愉悦的心情使用产品，并且能够通过视觉处理，轻松的上手操作产品。
而微交互，研究的是功能层和界面层中间的一层交互逻辑：如何设计界面、元素的互动，让用户顺畅、丝滑的操作，控制产品、完成工作。
根据尼尔森诺曼咨询公司的定义，微交互是 “触发 - 反馈” 配对，其定义包含两点：
（1）触发因素可以是用户操作，也可以是系统状态的变化；
（2）反馈是对触发因素的精准响应，通过用户界面中细微、高度贴合场景（通常为视觉层面）的变化来传递。
在《微交互》（Microinteractions）一书中，Dan Saffer将微交互定义为 “围绕单一用例展开的特定产品场景，它们只负责完成一项核心任务”。微交互是产品主要功能内部及周边的细微细节，通常情况下不易被察觉，只有在设计不佳时才会引起注意。
在书中，Dan Saffer将微交互拆解为四个部分：
触发（Trigger）：启动微交互的事件。可以是用户主动触发（例如点击按钮），也可以是系统主动触发（例如收到新短信）。
规则（Rules）：定义微交互被触发后 “该发生什么” 的指令，例如用户会认为在微信按住讲话按钮后会录入语音。（但实际上国外很多通信软件，是单击按钮进行语音录入，而非持续按住按钮）
反馈（Feedback）：用户通过视觉、听觉或触觉感知到的信息，用于理解规则内容及当前发生的情况，例如用户在微信录入语音时会提示剩余时长。
循环与模式（Loops and Modes）：模式是指针对微交互规则的配置，循环是决定微交互持续时间，包括微交互随时间变化的方式，例如微信语音录入时还剩多长时间界面给用户提示剩余时长。
我们在第1章介绍过用户体验的四个层次，微交互大概处在用户体验设计和界面设计中间的层级，如图8-1。
图8-1 微交互在用户体验的四个层次中所处的位置
我们在第5章介绍过Jesse James Garrett的用户体验五要素，微交互的研究范畴处于范围层和表现层之间，如图8-2。
图8-2 微交互在用户体验五要素中所处的位置
可见，微交互研究的是动态交互的逻辑和体验，对用户在使用操作产品过程中至关重要。对于C端产品来讲，微交互的设计细节甚至能决定一款产品的留存率。
作为B端产品经理，我们不需要像专业交互设计师那样，精雕细琢产品的微交互体验，因为B端产品在人机交互上面临的情况要比C端产品简单很多，但是基础的、良好的微交互设计是保证用户体验丝滑的关键因素之一，我认为可以从三个经典的设计系统入手，定义组件级别的设计规范和标准，从而很好地覆盖B端产品微交的关键场景，这三个系统分别是反馈系统、消息系统和触达系统：
反馈系统研究的是人机交互中机器如何与人反馈互动；
消息系统研究的是软件产品中重要的消息通知该如何设计、推送；
触达系统研究的是软件功能应该如何触达用户，引导用户上手体验并熟悉功能；
这三个系统的设计思想来自于Salesforce的SLDS，非常经典，适合作为B端产品经理设计微交互的指导框架。
8.1.2 微交互中的设计范式
在第6章我们讲过，设计价值观（Design Value）是产品体验设计的灵魂，是形而上学的抽象，设计原则（Design Principle）是产品体验设计的准则，是必须落地执行的规范，设计范式（Design Pattern）则是具体场景的解决方案。
在微交互的研究中，不仅包括经典功能组件的抽象和定义，也包括了互动逻辑的最佳实践，也就是需要遵循的设计范式。经典的设计范式包括分步骤引导、空状态、成就激励、关闭提醒等，我们会将这些设计范式，结合微交互的经典控件和组件设计，融入在接下来的三个设计系统中进一步讲解。
8.2 反馈系统设计
8.2.1 什么是反馈系统
反馈系统，是产品设计人员创造的，实现产品和用户之间连接、沟通的上下文情景，帮助用户理解产品达成目的。
反馈系统甚至可以等同于微交互的全部，因为所有产品微交互都是出发-反馈问题。
广义的反馈系统，包含了视觉反馈（Vision Feedback）、听觉反馈（Auditory Feedback）、触觉反馈（Touch Feedback），如图8-3。
图8-3 常见的反馈模式
左侧图，是四条不同状态的吐司提示，属于典型的视觉反馈；
中间的图，是一款智能音箱，通过AI语音和用户互动，属于典型的听觉反馈；
右边的图，是PS5游戏机的手柄，玩过PS和XBOX的朋友都知道，现在的手柄支持震动反馈，在被敌人击中，或者某些场景下，手柄会产生振动，尤其是PS5，振动的模式很细腻，带给用户非常有趣的体验，这是典型的触觉反馈；PS：本人是个重度主机游戏迷，在写本书时必须时不时搓一会儿XBOX或PS5Pro调节情绪 ￣︶￣。
8.2.2 反馈系统设计的三个要素
B端产品的反馈系统设计，需要分析触发时机、反馈组件、提醒程度三个要素，如图8-4。
图8-4 反馈系统设计三要素
触发时机：在什么情况下触发反馈，一种情况是系统触发的反馈，例如网络中断、系统错误，要告知用户；另一种情况，就是基本的交互反馈，用户在触发了键盘输入、鼠标点击等操作后，系统进行反馈响应。
反馈组件：针对触发事件，设计人员需要选择合适的反馈组件，呈现相应的内容。每个产品，都应该有自己一致的、标准的组件库，并且制定相关规范，针对什么场景、情况，选择什么样的组件或模式，进行反馈。这也是本文讨论的核心内容。
提醒程度：反馈可以很轻量，对用户无任何打扰，例如面包屑提示（Toast），也可以模式很重，需要中断用户操作，例如删除数据时弹出的确认模态对话框（Modal Conirm Dialog Box）。同样的组件、控件，也可能设计出不同的提醒程度，例如通知条（Notification Banner），可以设计成“用户可关闭”或“用户不可关闭”两种模式。当然，不同的反馈组件，本身提醒程度就明显不同。
只要理清楚反馈时机、反馈组件、提醒程度，就可以设计合理的反馈系统，给用户一致的、良好的交互体验。
8.2.3 反馈系统设计的场景四问
作为一名产品经理，我们做任何产品方案设计，都需要具备时刻以用户视角出发，从场景切入思考问题的意识和习惯，在反馈系统设计中，从用户视角，我们要回答四个问题。
我在哪里：任何反馈触发前，用户都必须知道在产品的具体位置，从而判断上下文，否则用户会感到困惑和混乱。
刚刚发生了什么：绝大多数反馈都是瞬间给出结果，例如弹出消息，告知成功与否，用户要知道刚才的交互的结果是什么。
正在发生什么：某些时候，事件发生后，执行需要一定耗时，用户需要等待，系统需要告诉用户正在发生什么，例如读取中，支付中；如果预测需要一定的耗时，还应该给用户一个预估时间，例如程序包的安装中，提示安装进度和剩余时间。
将要发生什么：如果需要，还应该给用户下一步动作的引导，或对后续工作的提示。例如，针对会话过期的Toast提示，可以在文本中加入“重新登录”的超链接。
在交互反馈设计中，我们要始终思考反馈系统三要素与场景四问。
8.2.4 反馈系统的组件和范式
接下来，我们首先介绍反馈系统涉及到的软件功能组件和范式。不论是弹出的对话框，还是一闪而过的吐司提示，都是经典的反馈组件。对于反馈组件的设计，我们没有必要标新立异发明创造，而应该采用成熟的、久经考验的、用户已经非常熟悉的功能形态。
Salesforce作为全球最有名的SaaS软件，在产品功能、组件设计以及方法论输出上，是所有B端产品经理应该学习的标杆，而Salesforce的功能组件，也是我见过最全面、最丰富的组件库。下边，我来给大家介绍Salesforce的SLDS中推荐的反馈组件，我认为所有B端产品，不论是自研系统还是商业化软件，如果能参考并实现部分SLDS中的组件，就可以很好的完成反馈系统的设计。
下边的内容读起来可能有点无聊，但却非常重要，因为你必须理解业界经典的设计规范和丰富的组件库，才能设计自己产品体系的组件与规范库。
组件：吐司提示（Toast）
不论使用C端产品还是B端产品，我们在某些操作后，都可能收到一条在屏幕上弹出几秒后自动消失的提示条，可能会告诉我们某个操作已经完成、某个操作是否成功，这个提示条会自动消失，不需要我们手动关闭，如果你要是一不留神，还可能漏掉这条提示，不过即便漏掉这条提示也无所谓，因为一般这只是一条知会、告知信息，这就是吐司提示，英文叫做Toast，如图8-5。
图8-5 吐司提示：一闪而过的用户提示
吐司提示是一种被广泛应用的组件，之所以叫做吐司提示，是因为这个组件在屏幕上弹出来的那一瞬间，就好像吐司面包完成加热后，从加热机叮的一声弹出来的那一瞬间；这样看来，这个组件的名称还挺形象！如图8-6。
图8-6 吐司提示的名字来源于吐司面包的加热
在SLDS中，吐司提示一共有四种样式，分别是成功提示（绿色）、警告提示（红色）、普通信息（灰色）、警告提示（黄色），呈现时会带有从下往上浮现的动画效果，此外设计人员可以决定提示框是否可以手工关闭，如图8-7。
另外大家注意一个小细节，图中每条提示最开头的小icon是不一样的，icon的视觉设计，在全站应用的统一性和规范性，也是交互设计中非常重要的细节，这是保证交互体验一致性的重要要素之一。
图8-7 SLDS中吐司提示的四种样式
图8-8展示了在Salesforce的Sales Cloud系统中，弹出了一条可关闭的灰色普通提醒的吐司提示，以及一条黄色的警告形式且不可关闭的吐司提示。
图8-8 吐司提示在产品界面中的实际效果
吐司提示的设计和应用，大家要避免以下情况：
提示过多：不合理的设计可能会导致吐司提示弹出太多，例如在某些用户频繁操作的功能中，如果每次操作成功都弹出吐司提示，会导致用户的界面中没完没了的弹出提示。一般吐司提示的弹出形态有两种，一种是一个一个的顺序弹出，等前一个消失后再弹第二个，一种像堆积木一样不停地跟在前一个提示的下边弹出，前边的提示消失后会全部上浮一层。不论是那种弹出形式，不合理的大量弹出，都会让用户非常崩溃。
产生遮挡：一般吐司提示的弹出位置是固定的，并且不允许用户拖拽弹出的提示，如果位置设计不合理，可能会给用户造成困扰。
例如，假设系统重有一个全局有效的快捷入口的按钮，在屏幕右上角的位置（其实我不太喜欢这种浮动的按钮，而且这种按钮最糟糕的设计就是固定在某个位置，他自身本来就可能造成遮挡），但是吐司提示也是在这片位置弹出，弹出后吐司提示会遮挡住快捷入口的按钮，导致用户无法点击快捷入口。如果连着有几条提示，用户必须耐心的等待所有吐司提示消失，才能使用快捷入口的按钮，这就是一种典型的不合理遮挡。
因此，设计吐司提示，必须非常细心的甄别页面已有的组件和元素的位置，思考是否会有不合理遮挡产生。
组件：全域通知条（Scoped Notification Banner）
工作时间比较久的读者可能在一些古老的管理软件中经常见到所谓的跑马灯组件，就是在系统的顶部，有一个文字从右往左不停滚动的组件，俗称跑马灯，这类效果甚至在html中有一个专门的标签，叫做<marquee>。很多古老的软件系统特别喜欢把重要的通知、公告，通过跑马灯的方式不停地在系统顶部显示，其实用户阅读起来既不美观，也不方便，这种土味十足的设计，就像当年门户网站的贴片广告（俗称牛皮癣），已经被淘汰了。
不过，在系统顶部进行重要信息的提示，而不影响用户正常操作，这个交互方式依然值得采用。SLDS中的全域通知条就是这样一个组件，在系统全域级别，展示一个文字条，一般用来呈现重要通知和消息，如图8-9。
注意，这里所谓全域级别，是指这个提示条不是依附于某个页面，而是在全站生效，也就是说你不论跳转到哪个页面，这个通知条永远在顶部位置。
图8-9 全域通知条：系统级的信息告知
在SDLS中，全域提示条一共有三种样式，可以根据需要设计成可关闭或不可关闭，如图8-10。三种样式分别为红色的错误、黄色的警告、灰色的告知。大家仔细观察，可以发现三种样式的icon图标和吐司提示是一致的，保证了视觉体系的一致性。
图8-10 SLDS中全域通知条的三种样式
组件：页内通知条（Page Notification Banner）
如果把全域通知条挪到页面内，就是页内通知条，如图8-11。页内提示条只在页面内呈现，如果用户跳转到其他页面，就看不到这个提示条了。不过如果用户再返回之前页面，如果没有手工关闭页内通知条，则该通知条依然可见。
图8-11 页内提示条：页面级别的信息告知
图8-12是页内通知条的实际使用效果。不论是全局通知条，还是页内通知条，都不应该随意使用，我们在8.2.6节会介绍什么场景下建议使用哪个组件。
提示条不应该随意使用，甚至被滥用。我之前在某国内比较有名的SaaS产品中，见到过某个列表页，将数据导出成功、功能更新通知、页面操作的逻辑规则说明，这些信息一股脑的塞进页面提示条，可以说逻辑非常混乱，让人看起来一头雾水，这就是典型的产品没有场景和组件的设计指导规范，产品经理根据自己兴趣偏好随意使用设计组件导致的结果。
图8-12 页内通知条在产品界面中的实际效果
组件：加载占位图（Skeleton Screen）
在B端产品中，如果用户打开的数据页面数据项过多，例如一个页面可能需要从多张表或者是多个数据库读取数据，就有可能需要有略微的加载等待时间，这不是网络传输速度决定的，而是取决于系统的复杂度。针对这类界面，如果能加一些过渡效果，可以减少用户等待中的焦虑。
第一个经典思路是进度条（Progress Bar、Loading Bar），因为无法预估加载实际进度，可能会采用一个转圈的小icon，代表系统正在加载数据中（俗称菊花转 ）。但我自己对类icon已经有应激反应了，因为每次看到转圈圈的图标总感觉是系统死机了。
另一个经典思路，是给用户呈现一个加载画面，这个画面可以是要打开的列表页或详情页的页面骨架轮廓图，给用户的感觉是页面已经打开，但内容字段信息还在读取中。这类过渡效果叫做加载占位图，这个组件的英文叫做Skeleton Screen，直译的话是屏幕骨架，国内习惯于翻译为加载占位图，如图8-13。
图8-13 加载占位图：页面加载时的过渡效果
图8-14左侧是Linkedin采用了加载占位图的页面效果，右侧是我编辑以后修改成了Loading Bar的页面效果，大家可以感受下哪个效果看起来更舒服一些。我会认为左边的占位图让人感到页面已经加载了一半，很快就能完成加载了（虽然里边的骨架图是假的），而右边的旋转图标，让人感到无穷的等待。
图8-14 页面加载中的两种过渡效果对比
如果要给页面采用加载占位图，占位图需要模拟页面的骨架，这样才会让用户体验起来更真实、顺畅。图8-15是Salesforce产品某个详情页的页面结构（右），以及加载过程中呈现的加载占位图（左）。
图8-15 Salesforce某个详情页的加载占位图实际效果
组件：状态按钮（Status Button）
状态按钮，是指按钮根据状态不同，呈现出不一样的样式和交互效果。如图8-16，演示了一个典型的状态按钮效果，当用户点击“Share”按钮后，系统需要执行一个业务逻辑，而执行完毕前，“Share”按钮被置灰，并且出现一个转圈的图标，直到执行结束，才恢复正常。
图8-16 状态按钮：对点击事件逻辑控制更加精确
状态按钮的典型应用场景如下：
预防错误：用户点击以后，避免错误二次点击带来问题。例如某个表单录入新数据，点击提交后将提交按钮置灰，然后反馈录入成功或失败，并关闭表单（或提示用户是否继续录入新数据），避免用户不小心重复点击提交，可能导致重复数据录入。
等待结果：对于非异步执行的业务逻辑，需要用户等待执行结果，等待时不允许二次操作，可以采用状态按钮。比较典型的场景是确认支付，当用户点击支付后，支付系统在反馈结果前，不允许用户二次点击按钮，但用户可以上下滑动页面浏览相关信息，而不是把整个页面锁死。
防作弊：某些业务场景，需要对用户的行为进行一些限制，避免用户多次快速点击。例如在CRM系统中，公司会在某个时间点释放客户资源，销售需要点击按钮领取资源，可以通过限制按钮点击的速度，防止销售使用按键精灵等工具作弊迅速抢占资源（当然，预防作弊的方法很多，通过将按钮限时置灰只是其中一种简单粗暴的办法）。
