即使我们努力把产品的体验做的再顺畅，也难免会遇到一些意想不到的情况，也就是极端情况，那么极端情况我们到底要不要处理呢？
开头我先讲个亲身经历的小故事：还记得曾经在一家公司，当我把交互稿输出给开发时，其中一位开发看到我给的“极端情况错误处理”时，他抛出一个大大的疑问，为什么这种情况也要考虑？正常人谁会这样用啊，如果所有场景都考虑的话，那还有尽头吗？我觉得这种不用处理…
我听了之后虽然讲了我的看法，他的确也都听了，但就是没那么做，结果就收到客户在我提到的场景下使用产品崩掉的反馈…
所以极端情况要不要处理呢？答案是：当然要！
一、为什么要考虑极端情况
作为一个交互设计师，时刻关注用户体验是最基本也是最重要的。一个业务逻辑单一的产品涉及的体验点也会非常庞大，大到业务流程、信息架构，小到按钮文案、操作提示等，除此之外，还有一些边角极端情况。
所以不单单是那位开发同学，相信很多人都会想：梳理正常的逻辑就已经很考验人的思考能力了，也完全可以满足正常的场景了，为啥还要绞尽脑汁的去考虑极端情况，有必要吗？
其实非常有必要。因为其实用户对于正常顺畅的操作体验并不会有太深刻的感受，除非你的交互体验登峰造极，但是一旦遇到一些极端情况导致产品可用性出了问题，那么用户很可能会马上卸载这款产品，所以极端情况千万不要漏掉！
二、极端情况实例
首先呢，我们先看几个常见的极端情况：
2.1 文字超长极限状态
众所周知，文字作为大部分产品中必现的元素，别看它简单，可它的逻辑不少，比如首先是否要设字数限制，其次若设限，那么某些场景是否要显示完整，超长了是折行还是末尾截断等。
解决方案：
现在大部分产品都会设置一个字数上限，即使客户端没有展示，服务端也会有个字数限制。
拿人名举个例子吧，一般处理是首先设置个20字上限，因为主要用户是国内用户，所以大部分不会超过4个汉字，所以尽量让大部分情况能显示的下5个字左右就可以了，超过后就末尾截断，不支持折行，因为大多数情况下如果折行显示页面布局就没法看了。
反例：列表条目文件名称显示做了字数限制，单行显示，但实际几乎没限制，所以鼠标hover显示完整后就灾难了。。。
2.2 页面内容空值
产品中有些页面是类似瀑布流的形式，那么就会涉及初始为空的状态，这种时候一定不要放任不管，给用户一个空空如也的页面。
目前看到的产品处理方式大概有三种：
1）空值提示：图标+说明文案，一般应用于比较中性无强烈引导操作的页面，例如消息、通知等
2）空值提示加操作引导：图标+说明文案+引导操作，一般用于有引导性的页面，例如社交、有交互的场景
3）推荐的内容：产品推荐一些内容供用户查看，一般用户内容类产品
无任何提示（反例）
具体哪种方式好，不能一概而论，要看产品本身属性和具体场景，这里不做赘述。
2.3 页面内容过多时的加载方式
还有一种情况就是页面内容过多的情况，这里我们不考虑页面展示只考虑进入页面的加载，大家平时估计遇到过点开一个列表页面，就一直在观看“菊花转”（页面内容加载状态），等的时间如果超过5秒可能就会产生焦虑了，再多点时间直接就和产品说拜拜了，那么这种极端情况一般怎么处理呢?
目前比较多的处理方式有：
1）页面框架异步加载：先加载比较快的条目框架，具体内容再填充，比如先加载文字，后加载图片
2）内容分页加载：比如先展示返回的20条数据，再展示接下来的20条，依此类推
3）本地缓存：存储一些固定的静态元素到本地，下次直接获取
2.4 非正常操作
在使用产品时，有些情况下，用户进行了非正常的操作，这时候如果不处理轻则造成内容的混乱，重则直接程序崩溃不可用，这里的非正常操作一般包含两种：
- 一种是“极限操作”，比如用户在移动端和PC端都登陆了同一账号，然后打开一个页面同时操作不同的任务，就可能直接崩掉；
- 另外还有一种是“疯狂操作”，用户在一个页面中以单身20年的手速点击一个操作，这时候程序也可能“懵逼”的挂掉。
当然以上说的情况和代码本身的健壮性也有关系，那么在体验角度我们能些什么呢？
可以定义一个统一的规则，比如程序检测到类似情况就出一个提示，因为极端操作情况比较少见，所以我们只要保证程序不崩溃，不影响用户正常使用即可，具体可以根据实际场景处理。
2.5 服务器出错
大家估计都遇到过一个页面：404页面，那这个页面到底什么意思呢？
其实404页面是客户端在浏览网页时，服务器无法正常提供信息，或是服务器无法回应，且不知道原因所返回的页面，当然一般情况不会见到这个页面，所以也是一种相对极端的情况，那有没有必要处理呢？
其实是有必要的，大家可以看下未经处理的404报错页面：
很明显，提示语很技术，不够通俗易懂、直观明了，那么再给大家看看一些产品的处理案例：
像以上优秀案例所示，其实404页面能做的东西很多，包括品牌宣传，引导操作，以诙谐幽默方式安抚用户情绪等，所以遇到这种服务器的极端情况还是要处理的。
当然，服务器报错不止404，其他类型的报错可根据发生的概率酌情处理。
三、总结
以上仅仅举了几个极端情况的例子，实际上还会有很多，若想尽量覆盖全极端情况，在设计时可以多多思考，将自己切换成“找茬儿模式”，也可以寻求QA同学的帮助，因为他们在写用例时会考虑的更多。即使努力去想可能发生的极端情况，但是有些极端情况还是可能会遗漏，到真正遇到了才知道，不过其实也说明了那些想不到的极端情况可能发生的概率更小。
总之，有些极端情况一定要处理，尽量做到给用户一个好的体验，但是有些情况其实并不需要投入过多精力去思考该如何提升体验，因为本身就不是正常的产品使用场景，只要在发生的时候保证产品可用性即可，因为还有更重要的产品主线体验需要不断去迭代提升。
你们觉得呢？欢迎一起探讨交流。
作者：江浦
来源：人人都是产品经理
