欢迎光临
我们一直在努力

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

即使我们努力把产品的体验做的再顺畅,也难免会遇到一些意想不到的情况,也就是极端情况,那么极端情况我们到底要不要处理呢?

1 1180 产品的极端情况是否需要考虑?

 

开头我先讲个亲身经历的小故事:还记得曾经在一家公司,当我把交互稿输出给开发时,其中一位开发看到我给的“极端情况错误处理”时,他抛出一个大大的疑问,为什么这种情况也要考虑?正常人谁会这样用啊,如果所有场景都考虑的话,那还有尽头吗?我觉得这种不用处理…

我听了之后虽然讲了我的看法,他的确也都听了,但就是没那么做,结果就收到客户在我提到的场景下使用产品崩掉的反馈…

所以极端情况要不要处理呢?答案是:当然要!

一、为什么要考虑极端情况

作为一个交互设计师,时刻关注用户体验是最基本也是最重要的。一个业务逻辑单一的产品涉及的体验点也会非常庞大,大到业务流程、信息架构,小到按钮文案、操作提示等,除此之外,还有一些边角极端情况。

所以不单单是那位开发同学,相信很多人都会想:梳理正常的逻辑就已经很考验人的思考能力了,也完全可以满足正常的场景了,为啥还要绞尽脑汁的去考虑极端情况,有必要吗?

其实非常有必要。因为其实用户对于正常顺畅的操作体验并不会有太深刻的感受,除非你的交互体验登峰造极,但是一旦遇到一些极端情况导致产品可用性出了问题,那么用户很可能会马上卸载这款产品,所以极端情况千万不要漏掉!

二、极端情况实例

首先呢,我们先看几个常见的极端情况:

2.1 文字超长极限状态

众所周知,文字作为大部分产品中必现的元素,别看它简单,可它的逻辑不少,比如首先是否要设字数限制,其次若设限,那么某些场景是否要显示完整,超长了是折行还是末尾截断等。

解决方案:

现在大部分产品都会设置一个字数上限,即使客户端没有展示,服务端也会有个字数限制。

拿人名举个例子吧,一般处理是首先设置个20字上限,因为主要用户是国内用户,所以大部分不会超过4个汉字,所以尽量让大部分情况能显示的下5个字左右就可以了,超过后就末尾截断,不支持折行,因为大多数情况下如果折行显示页面布局就没法看了。

反例:列表条目文件名称显示做了字数限制,单行显示,但实际几乎没限制,所以鼠标hover显示完整后就灾难了。。。

1 2131 产品的极端情况是否需要考虑?

 

2.2 页面内容空值

产品中有些页面是类似瀑布流的形式,那么就会涉及初始为空的状态,这种时候一定不要放任不管,给用户一个空空如也的页面。

目前看到的产品处理方式大概有三种

1)空值提示:图标+说明文案,一般应用于比较中性无强烈引导操作的页面,例如消息、通知等

1 3108 产品的极端情况是否需要考虑?

 

2)空值提示加操作引导:图标+说明文案+引导操作,一般用于有引导性的页面,例如社交、有交互的场景

1 4105 产品的极端情况是否需要考虑?

 

3)推荐的内容:产品推荐一些内容供用户查看,一般用户内容类产品

1 596 产品的极端情况是否需要考虑?

 

无任何提示(反例)

1 687 产品的极端情况是否需要考虑?

 

具体哪种方式好,不能一概而论,要看产品本身属性和具体场景,这里不做赘述。

2.3 页面内容过多时的加载方式

还有一种情况就是页面内容过多的情况,这里我们不考虑页面展示只考虑进入页面的加载,大家平时估计遇到过点开一个列表页面,就一直在观看“菊花转”(页面内容加载状态),等的时间如果超过5秒可能就会产生焦虑了,再多点时间直接就和产品说拜拜了,那么这种极端情况一般怎么处理呢?

目前比较多的处理方式有:

1)页面框架异步加载:先加载比较快的条目框架,具体内容再填充,比如先加载文字,后加载图片

1 779 产品的极端情况是否需要考虑?

 

2)内容分页加载:比如先展示返回的20条数据,再展示接下来的20条,依此类推

1 867 产品的极端情况是否需要考虑?

 

3)本地缓存:存储一些固定的静态元素到本地,下次直接获取

1 867 产品的极端情况是否需要考虑?

 

2.4 非正常操作

在使用产品时,有些情况下,用户进行了非正常的操作,这时候如果不处理轻则造成内容的混乱,重则直接程序崩溃不可用,这里的非正常操作一般包含两种:

  • 一种是“极限操作”,比如用户在移动端和PC端都登陆了同一账号,然后打开一个页面同时操作不同的任务,就可能直接崩掉;
  • 另外还有一种是“疯狂操作”,用户在一个页面中以单身20年的手速点击一个操作,这时候程序也可能“懵逼”的挂掉。

当然以上说的情况和代码本身的健壮性也有关系,那么在体验角度我们能些什么呢?

可以定义一个统一的规则,比如程序检测到类似情况就出一个提示,因为极端操作情况比较少见,所以我们只要保证程序不崩溃,不影响用户正常使用即可,具体可以根据实际场景处理。

2.5 服务器出错

大家估计都遇到过一个页面:404页面,那这个页面到底什么意思呢?

其实404页面是客户端在浏览网页时,服务器无法正常提供信息,或是服务器无法回应,且不知道原因所返回的页面,当然一般情况不会见到这个页面,所以也是一种相对极端的情况,那有没有必要处理呢?

其实是有必要的,大家可以看下未经处理的404报错页面

1 1048 产品的极端情况是否需要考虑?

 

很明显,提示语很技术,不够通俗易懂、直观明了,那么再给大家看看一些产品的处理案例

1 1181 产品的极端情况是否需要考虑?

1 1239 产品的极端情况是否需要考虑?

 

像以上优秀案例所示,其实404页面能做的东西很多,包括品牌宣传,引导操作,以诙谐幽默方式安抚用户情绪等,所以遇到这种服务器的极端情况还是要处理的。

当然,服务器报错不止404,其他类型的报错可根据发生的概率酌情处理。

三、总结

以上仅仅举了几个极端情况的例子,实际上还会有很多,若想尽量覆盖全极端情况,在设计时可以多多思考,将自己切换成“找茬儿模式”,也可以寻求QA同学的帮助,因为他们在写用例时会考虑的更多。即使努力去想可能发生的极端情况,但是有些极端情况还是可能会遗漏,到真正遇到了才知道,不过其实也说明了那些想不到的极端情况可能发生的概率更小。

总之,有些极端情况一定要处理,尽量做到给用户一个好的体验,但是有些情况其实并不需要投入过多精力去思考该如何提升体验,因为本身就不是正常的产品使用场景,只要在发生的时候保证产品可用性即可,因为还有更重要的产品主线体验需要不断去迭代提升。

你们觉得呢?欢迎一起探讨交流。

 

作者:江浦

来源:人人都是产品经理

 

赞(0)
未经允许不得转载:电商之家 » 产品的极端情况是否需要考虑?

登录

找回密码

注册