从界面模式的角度谈谈反馈设计

　　生活中充斥着各种各样的反馈，而我们就是在这些输入输出中认知事物。本文以界面模式的角度，聊一聊反馈模式，enjoy
　　开灯会有光、开风扇会有风，开电视会有影像生活中充斥着各种各样的反馈，而我们就是在这些输入输出中认知事物。同样，我们向系统输入一些指令，如果没有收到反馈，我们不可能认知一个系统。
　　我之前已经写过一篇文章聊了一下反馈的重要性，当时说的是一种广义的反馈，今天再以界面模式的角度，聊一聊反馈模式。
　　反馈的场景
　　回想一下一些生活场景：当你想让你的男女朋友帮忙倒杯水，会有怎样的情况会发生？
　　可能会这样：
　　又或者这样：
　　在上述场景中，我们可以看出任务是在多轮的执行与反馈中完成的。而且每次反馈都会基于不同的场景。我们来拆解一下：
　　或者
　　可见，在日常生活中，我们可以有8种出现反馈的场景。同理，在人和系统的交互中，也会这8种场景。
　　而每种场景都会有不同的原因、对被反馈者的决策要求和信息输入要求等等。所以，如果界面模式需要覆盖以上场景，单一的反馈模式远远不够，而事实上现有的反馈模式确实是多种多样的。
　　现有的反馈模式
　　1。状态切换
　　状态切换是指用户与界面元素交互的过程中，界面元素的状态发生了变化，比如鼠标悬停到按钮中，按钮会有高亮的显示，当鼠标点击按钮时，按钮又有其他的变化等等。这是一种非常轻量而且常见的反馈模式。
　　而我个人认为这也是一种最基础最重要的反馈模式。好比，我们呼喊一个人的时候会预期他们会作出响应，所以，在我们操作系统的时候，同样也会预期有响应，而状态切换正契合我们这种预期。
　　分享一个经历，在一次用户测试中，我们的系统出现了BUG：用户填写完弹窗上的表单后点击保存，弹窗没有关闭，但仍然出现一个Toast提示保存成功。我原以为这是一个不太严重的BUG，最多只会增加用户的操作步骤去关闭弹窗，不会影响用户整个任务的完成。
　　然而，用户在此弹窗上足足停留了两分多钟，最后得知是因为：他觉得弹窗没有自动关闭就是没有保存成功，但系统仍然提示保存成功，所以很疑惑到底有没有保存成功。同时他不敢关闭弹窗，因为他生怕没有保存，不想重头再来。
　　这个经历提醒我，状态切换能给予用户最直观的回应，一旦反馈缺失即会使用户发生认知冲突，而后果可能会很严重。
　　回到状态切换这种反馈模式，它可以适用于很多场景：收到请求、遇到阻碍、遇到风险请再次确认、等待中、任务完成等等。
　　2。加载
　　加载能表示系统正在运行，需要用户再稍等片刻。通常，都会用一些小动效来表现加载中，以降低用户在等待中的焦虑感，甚至有些产品会以不同的等待时间划分加载动效。例如：去哪儿的加载动效以03秒、36秒和6秒以上，三种时长来提供不同的动效。
　　这样做的好处在于，能持续地给予用户反馈，让用户知道系统确实在运行中，而不是卡死在这里。否则用户可能会频繁地刷新页面，或者直接离开。
　　加载模式可以分为模态加载和非模态加载：模态加载即在加载过程中不允许用户进行其他操作，非模态加载即允许用户其他操作。设计时要特别留意考虑周全，因为很多时候我们会忽略两者的区别，过多地使用模态加载。
　　3。Toast
　　Toast在移动端非常常见，是一个很轻量的反馈模式，打断感弱。Toast适用于：任务完成、遇到阻碍等场景。弊端在于不能承载过多的内容。而且提醒性较弱，用户往往会将其忽略。
　　4。Snackbar
　　Snackbar与Toast提示类似，不同点在于：
　　Snackbar位于界面顶部或底部，对内容的遮挡更弱。
　　可以带有操作按钮允许用户继续操作。
　　能提供不同的颜色，可以用颜色区分信息的重要程度。
　　可以说Snackbar是Toast的加强版，适用于：任务完成、遇到阻碍和提供更多可选方案等场景。
　　5。气泡
　　气泡在移动端和PC端都很常见，适用场景也很广泛，包括：任务不明确、遇到阻碍、遇到风险和提出更多选择。气泡有诸多优点：
　　属于非模态提示，打断感较轻。
　　出现位置在操作区域附近，用户不容易忽略，同时符合菲茨定律，使得用户操作更轻快。
　　可拓展性强，能承载各种样式的内容。
　　而缺点在于空间有限，无法适用于内容较多的情况。
　　6。ActionSheet
　　ActionSheet与气泡提示类似，有同样的适用场景。而且具有更强的拓展性，即使遇到内容较多的情况也游刃有余。由于极高的可拓展性，它不仅仅能用于反馈，还能适配成为各类的界面模式，如信息录入、信息列表、详情展示等等。而且能减少页面跳转，让界面层级扁平化。所以，ActionSheet这种模式也正越来越流行。
　　7。弹窗
　　可以说，弹窗是一个万能的反馈模式，可用于所有的场景。但由于弹窗的打断感极强，所以需要谨慎使用。
　　8。整页反馈
　　整页反馈即使用一整个界面来显示反馈信息，通常用于任务完成的场景。当用户任务的步骤比较多时，可能需要用到整页反馈。如下图，当用户从一个主页面的任务入口进入任务时，他需要执行多个步骤，而当任务完成时，他需要返回主页面而不是上一步骤的页面。
　　这种情况下，整页反馈能让用户离开整个任务，而不是仍停留在任务的某个节点。而在PC端，整页反馈通常会与向导组件一起使用，让用户清楚了解任务的步骤和终点，如下图。
　　9。批量操作反馈
　　批量操作反馈是一个比较特殊的反馈模式，通常在B端产品才能看到。因为B端用户会经常批量操作，但如果将操作后的结果一条条反馈给用户显然不实际，所以批量操作通常是集合式地将信息反馈给用户。
　　一些思考点
　　1。打断感、频次与注意力
　　打断感对用户的注意力有显著影响，打断感越强的模式越能吸引用户的注意力。除打断感外，频次也同样影响着注意力。
　　《逻辑思维》其中一期《这起医疗事故是谁的错？》中举了一实例：在一次诊断中，医生失误开出远超安全标准剂量的药物，医疗系统也给出了警报，但医生却把警报忽略了，而导致了悲剧的发生。但这不能全怪医生，因为一个临床医生每个月面对系统发出的警报有一万七千多条，在这种频次下，谁都会将警报当耳边风。
　　所以，为了让用户能更专注于一些重要的提醒，我们的策略应该是：让打断感强的模式更低频出现，让高频但次要的信息以打断感更弱的形式呈现。如下图，每种场景下的适用反馈模式有多种，模式的打断感从左往右依次增强，我们应该尽量使用靠左的反馈模式。而弹窗作为一种已知的打断感最强的模式，我们应非常克制地使用它。
　　另外，针对一些反馈频次更多的B端产品，我们可以扩展各个模式的颗粒度，让不同重要程度的信息能有更细致的区分。例如下图，antdesign的toast（其称为message提示），将不同的结果按不同的颜色区分，如此一来用户就可以通过颜色分辨他需要关注的信息。
　　2。时间
　　一些反馈模式会带有时间属性，例如Toast，它出现后会自动消失，所以我们需要定义它的停留时间。23秒是现今比较常见的时长，但这种简单的逻辑能覆盖的场景其实非常有限。
　　首先，不同类型的反馈信息，用户的关注程度不一样，所以阅读时间也不一样。例如任务出错比任务成功的内容需要消化的时间会截然不同。
　　其次，反馈内容的长度也会影响时间。较长的文本肯定需要更长的时间去消化，而且较长的问题通常是比较特殊的场景下才出现，不具备通用性，用户理解起来也会更费劲。
　　最后，在高频反馈的场景下，对时间的需求也会不一样。例如，用户操作单次时，Toast停留3秒没有问题，但当用户重复多次操作时，多条Toast就会在提留时间内重叠显示。
　　所以，尽管是一个停留时间，我们也应该对各种场景考虑周到，并归类抽象出共性再定义时间的规则。
　　3。位置
　　在我看来，在移动端反馈的出现位置其实并不是一个需要十分考究的点，因为屏幕就那么大，无论在哪用户都容易发现。但是在PC端却是一个需要考究的问题，因为屏幕会大很多，在一些区域用户很可能感知不到反馈的出现。
　　一些学者已经指出，用户在浏览网页时对各个区域的偏好：中部为最高注视区，而其他区域的关注度从左上角到右下角依次递减，如下图。这是一个非常有用的参考，我们可以根据信息的重要程度来定义反馈模式应该在哪个区，不干扰用户的同时又不被用户忽略。
　　另外一个问题是大屏的趋势。2k屏、4K屏甚至AR、VR等无边界界面的流行，使得屏幕边缘的信息将会越来越弱化，因为它们离视中心会越来越远。这会使得反馈位置的定位方式发生改变：从以屏幕边缘为锚点转向以屏幕中心为锚点。这两种选择会在大小屏切换时呈现不一样的效果，如下图：
　　4。反馈远不止反馈
　　让我们跳出反馈的框架看一看，其实仅仅提供反馈是远不够的：当用户收到一个报错反馈时，他不是想要知道错误的原因，而是需要知道下一步要怎么做；当用户收到一个警报信息时，用户不是想要知道原因，而是要知道如何解决。
　　一种好的反馈模式不仅仅是反馈，更是一种导航，引导用户下一步应该做什么、怎么解决问题。真正能让用户开心的反馈永远只有一个，就是任务成功，所以在给出反馈之前，我们应该好好想想，怎么才能让用户更简单地到达这一步。