2023年B端产品在异常状态下的设计思考

B端产品在异常状态下的设计思考近期个人跟进的一个产品被用户提了看法：每次进入页面的时候，页面空白，什么信息都没有，跟故障了没有数据一样。

具体了解状况后，发觉的确是消失了特别。这是一款查询类工具产品，进入页面已有基础的默认查询条件及相应数据展现，本身需要用户具有相应的权限才能进行查询，前述用户反馈的问题，就是由于账号没有相应页面功能的数据权限导致的。

遗漏了用户在特别状态下的设计，会导致用户在每一次的操作后，产品界面始终没有任何反馈，业务流程中断，停滞不前，然后用户心中会产生疑问：怎么回事？但又无人解答。

一次次地复现后，则会产生相同的结论：这个东西没法儿用，我的需求，你无法满意。在一次次的绝望，放弃这款产品，不再使用，而这仅仅是由于我们没有对特别状态做好一个合理反馈/引导。

正常状况下，产品经理应当定义清晰，在诸如网络特别、用户无权限等特别状态下，产品应当如何提示用户，关心用户恢复正轨。

如上述例子中，可以在界面提示用户账号权限不足，请联系管理员，或给到技术支持电话，通过人工介入的形式，使无助的用户能快速获得关心。

当然这个看法，也暴露出之前团队只专注于主操作流程、主页面的不同状态，却忽视产品中简单消失的各种特别状态的问题，这是一个不容忽视的问题。

对于以提升效率为目的的B端产品而言，缺乏对特别状态的反馈设计，会导致用户遭受某种特别状况时，不清晰发生了什么事，长时间停留在原地，无法快速定位到问题，最终导致业务处理的效率低下。假如始终保持现状，长此以往，就算上线了许多功能，对用户而言这些功能也是无效的的。

一、什么是特别

特别是正常的相对概念，汉典中，解释正常是符合一般的状况、规律或习惯。

对于产品而言，正常状态是指在产品使用过程中，交互反馈结果符合业务流程/交互规律/用户预期的状态；反之，不符合业务流程/交互规律/用户预期时，是特别状态。

例如，我们在百度搜寻“正常”两个字，页面返回的第一个结果是有关“正常”的百度百科，此时是正常状态；假如页面始终是空白，或者页面返回的第一个结果是有关“特别”的百度百科，此时是特别状态。

特别状态，是由于在程序运行过程中发生外部问题导致的，在用户操作-反馈的过程中，可能会被多种外部因素干扰而产生特别。

例如：网络环境因素中最常见的网络连接失败，网络连接失败会直接导致导致无法上传和下载数据，它们会出其不意地发生，并影响任何一个环节。

由于外部因素的产生是不行控的，因此特别状态的发生也是不行控的。

有些特别我们可以通过技术手段避开，但产品使用时的外部环境因素是我们无法掌握的，所以我们始终无法避开特别状态的发生，那么就应当提前考虑可能发生的特别因素及结果状态。

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

照旧以上文中因权限不足导致的页面空数据为例，对于这类依靠权限系统配置的因素我们无法掌握，所以应当提前考虑在用户权限不足的状况下，让用户意识到当前页面空数据是由于权限不足导致的，可以去联系管理员授权，或者返回上一层页面，让用户尽快离开当前功能；

而不是像原有产品设计一样什么都不反馈，让用户以为是系统故障导致的页面空白，最终生气地找到我投诉产品无法使用。

二、特别状态设计原则

设计的最终目的是让产品更可用、更易用，针对特别状态的设计也是如此。

发生特别时，为了避开用户不明所以，让用户更快地知道当前产品处于特别状态，和产生特别的缘由，降低用户的焦虑感，在特别反馈的设计过程中，可以结合场景参考一些通用的用户体验设计原则。

以下是我常用的可以和特别状态设计关联的设计原则：

1.状态可见原则

状态可见，指的是通过界面反馈设计让用户清楚地知道当前系统的状态，特殊是让用户第一时间清晰地知道当前产品处于特别状态。

正常来说，用户对特别是没有概念的，假如不明确地告知用户系统处于特别状态，他们会以为是正常状况并持续等待结果，始终没有结果可能会焦虑、急躁，持续重复多次后操作发觉还是不知道发生了什么，就可能离开产品了。

因此在前端界面将系统状态展现出来，不仅能让用户快速地了解自己处于何种状态、对过去发生、当前目标有所了解，还能让用户快速推断下一步该怎么做，避开铺张用户时间，而不是停留在原地等待，也能有效削减用户的负面心情。

例如下面这个案例，同样是由于网络缓慢导致的加载特别，在不具备状态可见的左图，用户会持续等待进度条的加载，不知道加载了这么久还没加载出来的缘由，不敢离开页面由于不知道还要等多久；

但对于状态可见的右图，用户明确知道页面加载失败了，虽然界面没有给到加载失败的缘由，但用户已经知道现在处于特别状态，就不会铺张时间等待，会尝试刷新或者直接离开页面，也能有效避开用户负面心情的积聚。

2.可退出原则

可退出，指的是在产品处于特别状态时，给到用户明确的出口可快速离开当前页面。

对于诸如服务器特别等缘由导致的特别状态，用户是无法通过个人的重复操作恢复到业务正常状态的，让用户在无法解决的特别页面重复尝试只会让用户积聚负面心情，无法快速找到离开的出口甚至没有离开页面的出口，更是会让用户的心情瞬间爆发。

因此，对于用户自行无法解决的特别状况，与其让用户什么都无法操作，或者做无谓的尝试，还不如直接给到退出出口离开产品，这样对用户的情感损害会更小一些。

例如下面的两个例子，都是由于服务器特别导致的特别状态，致使产品无法使用，仅仅通过toast提示用户特别缘由，告知了就结束了，让用户停留在原地等待，无法进行其他操作，也没有其他操作按钮；

相比之下，明确以对话框的形式告知用户服务器特别，用户在了解状况后点击确认按钮，即退出产品，这样的形式信息展现明白，操作快捷，避开了用户不知道怎么离开当前特别的囧境，和负面心情的积聚。

3.指引性原则

指引性原则，指的是针对一些操作可能会导致特别的状况，在用户操作前，设计指引信息防止这类问题发生，或在用户可能犯错时供应提示信息，避开特别的发生。

产品设计过程中，有些正常操作可能会导致特别状态，如用户上传文件时选择的文件超出了系统限定的大小。

对于这种状况，作为产品设计者，我们不应当眼睁睁地看着用户走到错误的那一步。

由于这样会让用户不明所以，明明都是根据系统要求的步骤流程操作的，为什么操作结果有时候胜利有时候失败，直到胜利/失败多次后，用户才可能摸索出其中潜在的系统规章——文件大小不能超过xx，让用户在试错中摸索系统规章，对于以提高业务效率的B端产品而言，是尤其不行取的。

所以，我们应当在设计过程中，留意到可能导致特别状态的操作，并结合业务状况，设计反馈引导，甚至是对用户的操作进行限制，以避开用户试错。

例如，下面的场景是用户上传文件时的界面，此处结合业务状况，对上传文件有两个要求：excel文件和5MB以内。从指引性原则动身，界面左下方告知用户系统规章，在用户选择文件的过程中，是无法选择非excel文件的，同时对于文件大小超过5MB的文件，也会以弹窗形式告知操作失败，这样能够有效地避开用户在正常业务流程进行无谓的试错，保证业务效率。

4.容错原则

容错原则，指的是当产品已经处于特别状态时，给到用户可以自行操作、订正错误的操作功能，让用户能自主尝试恢复回正常的业务轨道上。

在导致特别的因素中，有许多是短暂持续却常常发生的，例如因网络波动导致的加载特别，由于这类特别状况，是可以在短期内自动恢复的，重新操作后恢复正常状态的概率较高，所以我们应当让用户自己尝试解决，而不是建议离开，这样可以将特别状态对业务带来的影响降到最低。在设计用户的可操作功能时，也应当留意不要让用户进行过多的操作，重复特别发生之前的操作既可。

例如下面图中是下载失败的特别状态，此时我们可以明确地告知用户上一次操作失败了，并给到一个重新下载的按钮，让用户不用重新选择需要下载的文件既可再次尝试下载操作，这样就可以让用户连续原有业务了。

以上是个人在实践过程总结的适用于特别状态设计的原则，盼望这些原则可以在明知道会产生特别状态但不知道如何设计时关心到你，给你思路。

三、总结

以上对特别状态的设