编者按：当产品出现异常情况，如网络异常、用户无权限等异常情况时，产品需要在界面上反馈和指导用户的异常状态，以帮助用户快速获得帮助。


作者以B端产品为例，分析了其异常状态下的产品设计，希望能对您有所帮助。


最近用户对个人跟进的一款产品提出了建议:每次进入页面，页面都是空白的，没有信息，就像没有故障数据一样。


详细了解情况后，发现确实出现了异常。


这是一个查询工具产品入页面的默认查询条件和相应的数据显示需要用户有相应的查询权限。


上述用户反馈的问题是由于账户中没有相应页面功能的数据权限造成的。


错过用户在异常状态下的设计，会导致用户在每次操作后产品界面没有反馈，业务流程中断，停滞不前，然后用户问题：发生了什么？但没有人回答。


一次又一次地复制后，会得出同样的结论：这个东西不能使用，你不能满足我的需求。


在一次又一次的失望中，我们放弃了这个产品，停止了使用，这只是因为我们没有对异常状态做出合理的反馈/指导。


在正常情况下，产品经理应明确定义如何提醒用户在网络异常、用户无权等异常情况下帮助用户恢复正轨。


例如，您可以在界面上提示用户账户权限不足。


请联系管理员或给予技术支持电话，以人工干预的形式帮助无助的用户。


当然，这一观点也暴露出团队只关注主要操作过程和主页的不同状态，而忽略了产品中容易出现的各种异常状态，这是一个不容忽视的问题。


对于以提高效率为目的的B端产品，对异常状态缺乏反馈设计会导致用户不知道发生了什么，长时间停留在原地，无法快速定位问题，最终导致业务处理效率低下。


如果你一直保持现状，从长远来看，即使许多功能在线，这些功能对用户也是无效的。


一、什么是异常？ 异常是正常的相对概念。


在汉典中，正常的解释符合一般情况、规律或习惯。


对于产品而言，正常状态是指在产品使用过程中，交互反馈结果符合业务流程/交互逻辑/用户预期的状态；相反，当不符合业务流程/交互逻辑/用户预期时，则处于异常状态。


例如，我们在百度上搜索正常一词。


页面返回的第一个结果是关于正常的百度百科全书，此时处于正常状态；如果页面一直是空白的，或者页面返回的第一个结果是关于异常的百度百科全书，则为异常状态。


异常状态是由程序运行过程中的外部问题引起的。


在用户操作反馈过程中，可能会受到各种外部因素的干扰。


例如，网络环境因素中最常见的网络连接失败将直接导致数据无法上传和下载，这将意外发生，并影响任何链接。


由于外部因素的产生是不可控的，异常状态的发生也是不可控的。


我们可以通过技术手段避免一些异常，但我们无法控制产品使用中的外部环境因素，因此我们无法避免异常状态，因此我们应该提前考虑可能的异常因素和结果状态。


结合有针对性的场景设计反馈，可以在前端感知地告诉用户，引导用户了解页面的状态和如何做，而不是让用户没有反馈，不知道发生了什么问题，业务流程中断，进一步导致用户焦虑，最终放弃产品。


以上页面空数据为例，对于这种依赖权限系统配置的因素，应提前考虑用户权限不足，让用户意识到当前页面空数据是由于权限不足，可以联系管理员授权，或返回上一页，让用户尽快离开当前功能； 而不是像原来的产品设计那样没有反馈，让用户认为是系统故障造成的页面空白，最后愤怒地发现我抱怨产品不能使用。


二、异常状态设计原则 设计的最终目的是使产品更可用、更容易使用，异常设计也是如此。


当出现异常时，为了避免用户未知，让用户更快地了解当前产品的异常状态和异常原因，减少用户的焦虑。


在异常反馈的设计过程中，可以参考一些一般的用户体验设计原则。


以下是我常用的与异常状态设计相关的设计原则： 1. 状态可见原则 状态可见，是指用户通过界面反馈设计清楚地了解当前系统的状态，特别是当用户第一次清楚地了解当前产品的异常状态。


一般来说，用户对异常没有概念。


如果他们不清楚地告诉用户系统处于异常状态，他们会认为这是正常的，并继续等待结果。


如果没有结果，他们可能会焦虑和易怒。


经过多次重复，他们仍然不知道发生了什么，所以他们可能会离开产品。


因此，在前端界面显示系统状态，不仅可以让用户快速了解他们的状态、过去、当前目标，还可以让用户快速判断下一步，避免浪费用户时间，而不是停留在原地等待，也可以有效减少用户的负面情绪。


例如，以下案例也是由于网络缓慢引起的加载异常。


在没有状态可见的左图中，用户将继续等待进度条的加载。


他们不知道为什么加载了这么长时间，也不敢离开页面，因为他们不知道要等多久； 然而，对于状态可见的右图，用户清楚地知道页面加载失败。


虽然界面没有给出加载失败的原因，但用户已经知道他们处于异常状态，所以他们不会浪费时间等待。


他们会尝试刷新或直接离开页面，这也可以有效避免用户负面情绪的积累。


2. 可退出原则 退出是指当产品处于异常状态时，给用户一个明确的出口可以快速离开当前页面。


对于服务器异常引起的异常状态，用户无法通过个人重复操作恢复正常业务状态，让用户在无法解决的异常页面上重复尝试只会让用户积累负面情绪，无法快速找到出口甚至没有出口，会让用户的情绪立即爆发。


因此，对于用户无法自行解决的异常情况，最好直接给出出口离开产品，而不是让用户无法操作任何东西或做不必要的尝试，这样对用户的情感伤害就会更小。


例如，以下两个例子都是由于服务器异常引起的异常状态，导致产品无法使用，仅通过toast提示用户异常原因，通知结束，让用户停留在原地等待，无法进行其他操作，无其他操作按钮； 相比之下，以对话框的形式明确告知用户服务器异常。


用户了解情况后，点击确认按钮退出产品。


这种形式的信息显示了快速的操作，避免了用户不知道如何离开当前的异常尴尬和负面情绪的积累。


3. 指引性原则 指导原则是指在用户操作前设计指导信息，以防止此类问题，或在用户可能犯错误时提供提示信息，以避免异常。


在产品设计过程中，一些正常的操作可能会导致异常状态，例如用户上传文件时选择的文件超过了系统的限制。


在这种情况下，作为产品设计师，我们不应该看着用户走错了一步。


因为这会让用户不知道，所以显然是按照系统要求的步骤和流程操作的。


为什么操作结果有时成功，有时失败？直到成功/失败多次，用户才能探索潜在的系统规则——文件尺寸不能超过xx，为了提高B端产品的业务效率，让用户在试错中探索系统规则尤为不可取。


因此，在设计过程中，应注意可能导致异常状态的操作，并结合业务情况、设计反馈指导，甚至限制用户的操作，以避免用户的试错。


例如，以下场景是用户上传文件时的界面。


结合业务情况，上传文件有两个要求：excel文件和5MB以内。


从指导原则出发，界面左下角通知用户系统规则，在用户选择文件的过程中，无法选择非excel文件大小超过5MB该文件还将以弹出窗口的形式告知操作失败，有效避免用户在正常业务流程中进行不必要的试错，确保业务效率。


4. 容错原则 容错原则是指当产品处于异常状态时，给用户可以操作和纠正错误的操作功能，使用户能够独立尝试恢复正常的业务轨道。


在导致异常的因素中，有很多是短期常发生，如网络波动加载异常，因为这种异常，可以在短期内自动恢复，恢复正常状态的可能性高，所以我们应该让用户尝试解决，而不是建议离开，从而减少异常状态对业务的影响。


在设计用户的可操作功能时，也要注意不要让用户操作过多，在异常发生前重复操作。


例如，下图显示了下载失败的异常状态。


此时，我们可以清楚地告诉用户上次操作失败，并给出一个重新下载的按钮，以便用户可以再次尝试下载操作，而无需重新选择需要下载的文件，以便用户可以继续原始业务。


以上是个人在实践过程中总结的适用于异常状态设计的原则。


我希望这些原则能帮助你知道它会产生异常状态，但不知道如何设计，并给你一个想法。


三、总结 以上总结了异常状态的设计原则。


与正常状态相比，异常状态相对罕见，容易被忽视，但异常也是设计的一部分。


互动设计师和视觉设计师都应结合业务场景给出异常的表达形式或处理方法，确保产品异常时不中断任务的执行，为异常提供适当的指导，实现产品性能、业务流畅、防错效果的平衡。


当然，公司的特殊业务也会导致非常特殊的异常状态。


欢迎大家交流学习进步。


作者:伯安，微信官方账号:伯安郡 本文由 @伯安 原创，未经许可，禁止转载 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。