xidea的咖啡馆

让产品与用户“心有灵犀”

xidea — Thu, 26 Apr 2012 11:58:10 +0000

　　从一个小故事说起。

　　之前网上曾经对于“要不要做调研”这件事情有过讨论，这其中提到福特曾经这样解读自己的发明：“如果我问我的客户，他们要什么，他们的回答一定是：一匹更快的马。”曾经有朋友以此为例来质疑调研的必要性，甚至将其跟乔布斯扯在一起。

　　事实上，笔者认为这个故事恰恰证明了对于用户行为、用户建议做分析的必要性。其实故事中的“客户”已经明确的表达出了他们的需求，只不过并不是“马”，而是“更快”。汽车的出现及其发展，恰恰是解决了“更快”这个需求，同时也造就了福特的成功。

　　在设计互联网产品时，有时候我们只要细心观察用户的行为，就可以在一定程度上预见这些行为背后的目的。如果在此基础上适当加以设计，往往可以在一些体验细节上获得提升。下面举几个相关的例子来说明：

1、Chrome的标签

　　我们在使用浏览器浏览网页的时候，经常会有这样的应用场景：在一个文章列表页面，我们点击这个页面中的多处链接，每一个链接都增开了一个新标签用来显示文章内容。我们依次阅读这些标签中的内容，阅读完毕后，就会有将这些标签依次关闭的需求。在这样的场景下，如何能够让用户快速有效的关闭多个标签？Chrome设计了这样的一个细节，如图：

　　当标签数量很少的时候（图中1），Chrome将每一个标签设置了一个固定的宽度(大约200像素)。而当不断的有新标签打开的时候，Chrome会缩小每一个标签的宽度，使其能够有足够的空间进行排列(图中2)。在上述场景中，当我们完成了阅读，点击某标签后面的关闭按钮时，我们发现了这个设计细节：标签被关掉了，但是其后剩余的标签并没有及时的调整尺寸，而是向前移动，填补了被关掉标签的位置。这样，我的鼠标在不需要任何操作的前提下，自然的落在了下一个标签的关闭按钮上(图中4)。也就是说，假如用户需要连续关闭5个标签，那么用户只要在第一个标签后面的关闭按钮处，连续点击鼠标5次，就可以了。操作过程完全不需要思考！

　　显然，当我们关闭第一个标签的时候，Chrome根据我们的行为，“猜”到了我们可能有连续关闭多个标签的需求。所以他们设计了这样的一个小细节，极大的提升了这种应用场景下的用户体验。而当用户鼠标移出标签区域的时候，Chrome再次“猜”到，用户的关闭操作应该已经完成了，这时，它才重新计算宽度，并重新排布所有标签(图中5)。

　　相比之下，IE可就没那么聪明了。请看：

　　在IE8中，首先，想要关闭标签，必须先激活它(图中2和3)。其次，关闭后，将马上重新计算各标签的宽度(图中4)。相比之下，Chrome的设计，在这样的场景下，更加能够与用户“心有灵犀”。而在其他的场景下，这种设计也不会有问题。

2、QQ的会话窗口拆分提示

　　在新版本的QQ中，腾讯的设计师做了一处修改，当用户同时打开多个会话窗口时，这些窗口会进行合并，用户可以使用类似标签的控件进行切换。类似下图中的样子：

　　我个人很喜欢这个设计，切换起来很方便。但是有一次，我不小心将其中一个会话拖离了主窗口，类似这样：

　　由于是误操作，我并没有马上反应过来发生了什么。这时，我注意到被拖出来的那个会话窗口上，出现了一个气泡提示。内容是：“赞！你发现了会话窗口拖动的秘密。按住头像还可以拖回去哦，快试试吧。”QQ好像猜到了我的困惑，直截了当的给我提供了相关说明和解决方案。

　　其实对于很多初级用户来说，由于他们对鼠标使用不熟练(我母亲就是这样的用户)，或者，他们的鼠标质量比较差，很容易产生这样的误操作。QQ的提示信息在用户误操作后的第一时间解决了用户的困惑，并且提供了恢复的方法。另外一方面，即使用户不是误操作，这个提示作为一个对新功能的说明，也是很有必要的。

3、某银行的客服电话

　　当我们使用了某机构的服务，或者购买了某商品出现问题时，经常会有打客服电话咨询的需求。如果问题比较复杂，语音程序无法解决的话，我们就需要转人工客服。当咨询量特别大的时候，转接人工客服需要漫长的等待。笔者注意到，不同的机构（或者说不同的呼叫中心服务提供商），对于这个流程的设计，是不一样的。

　　先说一个体验不太好的例子。北京某政府机构的客服电话，转人工服务的大致流程是这样的：

　　也就是说，如果等待时间较长，我不但需要忍受这个过程，还需要每隔30秒按一下1键才能继续。这是一个非常不好的体验。(其实后面还有更崩溃的策略，没在流程图中表现出来。就是：如果连续按多次1键，估计在10次左右吧，会提示：“呼叫失败，请稍后重拨…”然后电话自动挂断。也就是说，我等了很久之后，不但没得到服务，还被强行清除出队列了… 需要重新排队！)

　　那么，在这样的情景下，我们是不是也可以分析一下用户的目的，然后优化一下流程呢？我想答案是肯定的，下面说一个我认为比较优秀的案例。某银行的信用卡客服电话，转人工服务的大致流程是这样的：

　　这是一个我认为比较不错的流程设计。该银行“猜”到，如果一个用户在转人工服务的过程中，连续3次决定继续等待，这证明该用户的态度很“坚决”，很有可能是因为他真的遇到了必须要人工解决的问题。所以这时系统将不再引导他继续按键，而是一直播放等待的音乐，直到有客服接电话为止。

　　由上面的这几个例子可以看出，有些时候即使我们不去做特别专业的用户调研和数据分析，只要我们设身处地的从用户的角度去思考，去推理，去观察用户的行为，就更可能设计出体验更好的产品。

我在UXday上的分享《关于交互设计的3个细节》

xidea — Thu, 29 Mar 2012 07:49:26 +0000

我在百度UXday第九期的聚会上分享的关于交互设计的视频。举例叙述了在交互设计工作中经常会遇到的，但又不那么容易被主要到的3个细节。分别是：

概念内化：以用户听得懂的语言来表达设计。
标准之惑：依照用户具体的使用情境和需求来决定是沿用标准还是创新。
为谁设计：要以用户的需求为中心，避免参杂设计师的主观喜好。

基本上都是我在博客上写过的东西。

具体请访问 http://v.youku.com/v_show/id_XMzcyNjY5MDk2.html

PPT在这里 http://vdisk.weibo.com/s/3AmoW

影响用户体验的4个因素

xidea — Tue, 13 Mar 2012 06:17:58 +0000

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

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

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

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

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

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

　　是在提醒我，卖家发货了。因为这件商品是从广州发出，一般的快递公司到北京需要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浏览器中可以勉强正常使用(页面排版部分乱掉暂且不计)，如果使用Firefox、Chrome等浏览器，不仅一些页面的排版会乱掉，还会出现查询信息无法显示的情况。如图所示：

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