产品的极端情况是否需要考虑？.docx

第PAGE\*MERGEFORMAT5页共NUMPAGES\*MERGEFORMAT5页

产品的极端情况是否需要考虑？

即使我们努力把产品的体验做的再顺畅，也难免会遇到一些意想不到的情况，也就是极端情况，那么极端情况我们到底要不要处理呢？开头我先讲个亲身经历的小故事：还记得曾经在一家公司，当我把交互稿输出给开发时，其中一位开发看到我给的“极端情况错误处理”时，他抛出一个大大的疑问，为什么这种情况也要考虑？正常人谁会这样用啊，如果所有场景都考虑的话，那还有尽头吗？我觉得这种不用处理…我听了之后虽然讲了我的看法，他的确也都听了，但就是没那么做，结果就收到客户在我提到的场景下使用产品崩掉的反馈…所以极端情况要不要处理呢？答案是：当然要！一、为什么要考虑极端情况作为一个交互设计师，时刻关注用户体验是最基本也是最重要的。一个业务逻辑单一的产品涉及的体验点也会非常庞大，大到业务流程、信息架构，小到按钮文案、操作提示等，除此之外，还有一些边角极端情况。所以不单单是那位开发同学，相信很多人都会想：梳理正常的逻辑就已经很考验人的思考能力了，也完全可以满足正常的场景了，为啥还要绞尽脑汁的去考虑极端情况，有必要吗？其实非常有必要。因为其实用户对于正常顺畅的操作体验并不会有太深刻的感受，除非你的交互体验登峰造极，但是一旦遇到一些极端情况导致产品可用性出了问题，那么用户很可能会马上卸载这款产品，所以极端情况千万不要漏掉！二、极端情况实例首先呢，我们先看几个常见的极端情况：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页面能做的东西