首页 > 网站 > WEB开发 > 正文

影响用户体验的4个因素

2024-04-27 14:42:23
字体:
来源:转载
供稿:网友

  随着互联网产品的不断发展,越来越多的人意识到了用户体验的重要性,越来越多的公司成立了UED相关的部门,并且职位划分已相当细致。但是UED中职能的划分,却大部分仅对接界面的层面。事实上,一个互联网产品从策略的产生到最终上线,其中的每一个环节都可能影响最终的体验。总结起来,Henry认为共有4个重要的因素会对最终体验产生明显的影响。它们是:产品策略、用户界面、技术和运营。

  下面分别来说说这4个因素。在说明每一个因素的同时,会举2个跟该因素有关的例子,一个是互联网上的例子,另一个是日常生活中相似的例子。所有涉及到的案例,仅仅在我所能看到的层面(这意味着,我所描述的问题,在我看不到的层面上,可能是合理的做法,或者是有苦衷的),为了说明问题而设置,并仅代表 Henry个人观点。

  一、产品策略(对应职位:产品经理)

  策略是产品的灵魂。产品策略除了决定产品的具体功能外,还对体验有重大的影响。不好的策略可能会伤害用户体验。

  Web上的例子:腾讯拍拍的收货提醒

  我曾在腾讯的拍拍上买过一件商品,在该商品发货的当天,我登录QQ,看到了这样一个提醒:

影响用户体验的4个因素 三联

  是在提醒我,卖家发货了。因为这件商品是从广州发出,一般的快递公司到北京需要3天左右的时间,于是我没理会这个提醒。

  但是,悲剧的是,发货的第2天,我再次登录QQ的时候,依然看到了这个提醒。同样的提示貌似每天登录都会看到,这其实已经对用户产生了骚扰。但问题在于,我不是不想确认收货,而是,我的货还在路上,我根本没有办法“确认收货”。于是我想,万一我要是不小心用了中国邮政平邮,路上走20天,难道我要连续20天看到同样的提示吗…?又或者,我的货物不幸遇到了什么百年不遇的山洪、地震一类的,在路上多耽搁了几天。这时本来我已经很郁闷了,却还要天天面对这个烦人的提醒。并且这个界面上没有明显的“消息设置”入口,我并不知道能否关掉该提示,以及如何关掉。

  这显然是由于产品策略而造成的体验问题。

  解决办法:

  那么,这个收货提醒功能,应该如何设计呢?也许每个人都有不同的想法,我想了一个简单的方法:

  首先,计算出从发货地点到收货地点的距离。然后,需要获得一般的快递公司送货的速度,包括一般情况下可能产生的延时范围(例如发达地区和偏远地区的差异)。然后,大致计算出货物在路上要走的时间。当卖家确认发货后,开始计时,过了这个时间以后,再向买家弹出提示。如果可以跟快递公司合作,取到快递公司的物流数据,在买家签收后再弹,会更加靠谱。并且在提示框内放置明显的设置选项,允许用户屏蔽该信息。如果弹出的信息对于产品整体策略来说很重要,不希望用户轻易屏蔽,则可以考虑将屏蔽选项藏得深一些。

  生活中的例子:中国大陆的交通信号灯

  “红灯停,绿灯行。”这是我们在很小的时候就已经熟悉的规则。但是这句话是对于行人来说的,如果是机动车司机,其实规则并非完全如此。在《中华人民共和国道路交通安全法实施条例》中,第三十八条和第五十一条阐述了机动车转弯时相关的规则,与本例有关的内容,总结如下:

  1、要转弯,需先占道。向左转弯需先进入最左侧车道,向右亦然。

  2、绿灯时,可以左转,也可以右转。

  3、红灯时,只能右转。

  但是这些策略与行人要遵守的规则会有一些冲突。如图:

  首先,对于1号行人来说,在他行进方向为绿灯的时候,他首先要躲避从A车道右转的a1,然后,前进过程中,又需躲避从B车道左转的b1。如果A,B两车道均有大量机动车排队转弯,理论上讲1号行人在不闯红灯、不与机动车抢行的前提下,永远都无法成功走到路的对面。

  其次,我们看2号行人,这里更加悲剧。当他马上就要成功的时候,遇到了从C车道右转的c1。但是,由于C车道旁边的2个车道上的机动车正在等待红灯,所以,它们会阻挡2号行人的视线(扇形部分是他的可视区域)。以至于,对于2号行人来说,C车道上究竟有没有车辆要通行、有几辆,以及下一辆车距离斑马线有多远,他根本就看不到!这意味着,他每次走到此处,都要冒着生命危险试探着跨越C车道。

  还有更悲惨的事情在后面。

  我们看3号行人。当他到达斑马线的后半段的时候,随时可能有机动车b1从B车道向左转弯。而对于此时的3号行人来说,车将从他背后驶来!他或许完全无法预期,下一秒将发生什么!

  虽然我们注意到,在《条例》中提到,以上情况下机动车转弯时,必须是在“不妨碍直行车辆、行人通行”的基础上进行。但是这个策略本身,很难操作和把握。出了问题也不容易界定责任。所以笔者认为,我们的交通信号灯系统的整体策略,是严重影响用户体验的(司机和行人都是用户)。

  解决办法:

  因为存在上述问题,所以,有人发明了带有箭头的信号灯:

  这样,我们按照行进方向,将不同车道的信号分开表示。如上例中,当水平方向有行人通行时,使用红灯禁止水平方向A、B两车道机动车转弯,而保持水平方向其他车道畅通。同时禁止C车道机动车转弯。这样,行人就可以安全的通过斑马线了。同样,当允许转弯时,使用红灯禁止行人穿越。如此便可以保证双方的安全和通畅。

  二、用户界面(对应职位:交互设计师、UI设计师、视觉设计师等)

  影响用户体验的第二个重要因素,是用户界面。在这个层面上,流程、控件、交互、排版、视觉等诸多因素都有可能影响到最终的体验。我们只选择其中一个小的点来举例。

  Web上的例子:掌上百度Android客户端

  「掌上百度」是百度较早推出的移动客户端软件之一。它将百度的几个主要产品(如搜索、贴吧、新闻等)做到一个app中。能够让用户在移动终端上使用百度的主要功能。

  但是个人认为,这个版本的掌上百度应用,仅仅是这几个产品的简单整合,在设计时并没有充分考虑移动平台的特点。实际上该客户端的使用体验,并不比使用移动浏览器直接访问移动版网站好很多。我们仅提取1个简单的点来说明该问题,请看截图:

  这是该应用内置的一个常用网站列表。我们从UI上可以看出,该列表从文字大小、间距、排版等方面来看,依然在沿用传统web的风格。但是,在传统 web上,我们多数情况下使用鼠标来进行操作。鼠标是一种比较精确的指向设备,这样的排版,鼠标足以精确点击。但是在移动设备上,我们需要使用手指进行操作。事实上,笔者用尺量了一下这些链接的尺寸,在我的HTC G7的屏幕上,每个链接的尺寸只有大约4mm×2mm的面积。这个面积,即使是对于女孩子来说,都难以对其进行精确操作。如果是对于手指相对粗大一些的男性,或者考虑实际移动过程中可能产生的干扰(如晃动的车厢),使用体验就更差了,必须很小心才能够点击到想要的链接。

  解决办法:

  事实上,对于现行的Android和ios这类用手指操作的系统来说,列表或许应该考虑设计得宽大一些。比如百度知道的app:

  相对来讲,每一级列表都比较宽大,可以在移动设备上比较容易的进行操作。

  生活中的例子:电梯上的开关门按钮

  我们平时乘坐电梯的时候,经常要操作电梯上的各种按钮。主要的需求有2种,一种是进入电梯后选择自己要去的楼层;另一种,是开门和关门(关门较多)。

  大部分电梯的操作界面上,开关门按钮都是用图形表示的,类似下面:

  但是,大部分电梯上的这两个按钮,使用了相同的图形元素,只是方向不同。加上具体的箭头样式、两个按钮的排列方向并没有行业标准,以至于这两个按钮长什么样,完全由电梯生产厂商决定。在实际操作过程中,我们并不能够马上分辨出这两个按钮的功能(左侧是开门,右侧是关门)。笔者每次进入一个陌生的写字楼的电梯,想按关门键,都要迟疑一下。这不是一种好的体验。

  解决办法:

  事实上,图形并不一样比文字更加直观。两个按钮的识别性较差,可能是因为他们外观太过相似。如果考虑换成汉字,或许会简单明了得多,操作时几乎不需要思考:

  三、技术(对应职位:各种工程师)

  技术是实现产品的工具,也是产品正常运行的基础。如果技术方面出了问题,同样会对最终的体验产生不良影响。这个因素中具体的表现也很多,如前端页面对各种浏览器的兼容性,代码运行效率,服务稳定性等。涉及的范围非常广,我同样只挑选一个点来说明问题。

  Web上的例子:北京市房地产交易管理网

  在这个网站上,可以查询到北京市所有新建商品房的相关信息,包括面积、销售状态、最高价格等。

  但是,该网站只在IE浏览器中可以勉强正常使用(页面排版部分乱掉暂且不计),如果使用FirefoxChrome等浏览器,不仅一些页面的排版会乱掉,还会出现查询信息无法显示的情况。如图所示:

  图中两个浏览器打开的是同一个页面。左侧是IE的结果,右侧是Firefox的结果。我们看到,在左侧图片的右下方,是很多花花绿绿的表格。而右侧图片,同样位置则是一片空白。按照一般的思路,查询出来的数据,应该是后端程序生成的,理论上不应该受不同浏览器兼容性的影响。后来在查看该页面的 HTML代码过程中,发现了这样一行久违的代码:


发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表