[翻译]导致网站可用性差的十个最常见问题

[翻译]导致网站可用性差的十个最常见问题

作者:Experiencesolutions
译者:尚文欢
原文地址:http://www.experiencesolutions.co.uk/blog/2008/09/15/the-10-most-common-reasons-for-poor-usability-part-1/
注:括号【】内的文字为译者自己添加的内容

只有置身事外才能真正发现产品的可用性问题,很容易举出可用性差的例子,但是通常情况下人们并不知道那些造成产品好用或者难用甚至令人愤怒的真正原因。当然,这并不是偶然,大多数优秀的产品都曾进行过深入的用户体验设计以及可用性测试。

下面是我们总结的导致可用性差的最常见原因

1. 过分关注产品功能与技术

在 项目的一开始,很多项目负责人和利益相关人员都希望能够利用最新的技术或开发大量的的功能,功能的开发与测试则受到高度重视,并且通常会有一个专门的项目 小组负责,错就错在未能平衡这些功能与用户真正的需求之间的关系,相反,用户需求被扔到了大部分接口开发完成之后。

【没有数据表明但听过很多设计师抱怨,决策者往往将改善用户体验交给了视觉设计师或者是交互设计师进行最终界面的改善,这让设计师们无从下手】

2. 设计师和工程师的“门户之见”

脱离用户的情况下,设计师和工程师除了自我经验并没有更多想法,仅从自我能力、理解和看法出发进行系统设计。他们常常会深入的做项目却很少怀疑自己的决定,如果产品能够按照他们预想的方式运作那就足够了。

【这里可参考千鸟同学的文章:对设计和技术的误解,顺便提一下最近比较热闹的Doug Bowman辞职事件,在我理解中,G公司受到流量的影响,是一个数据决定设计的公司,而Apple则受到销量的影响,是设计决定数据的公司,人各有志,而G公司也不会因为Doug的离开有所改变】

3. 没人考虑过用户真正需要使用的界面

开发人员很容易陷入项目的细节,并沉浸在如何使产品正常运作的复杂性上。有时候,一个团队很容易做到集中精力于工作细节却不能退一步从用户的角度去质疑自己的设计,了解用户真正的需求,了解用户在什么情况下使用他们的产品,而这些很可能彻底改变设计的方向。

【工程师很容易为了一个细节问题和产品设计师较真,而如果这个设计师在没有实权的情况下,很容易和工程师妥协,不论设计师说话的手段有多高,方向性问题上或许能够说服设计师,针对某个细节,并且是设计师不熟悉的细节,产品很容易被工程师误导而失去本意】

4. 最终拍板的人缺乏界面设计经验

通常,我们会碰到一个能干并且善良的项目主管来为产品最终的界面与运作拍板,但大多数情况下并非如此,这个能够拍板的人往往很少有用户界面设计的经验,并经常不经意间做出那些并不考是否会虑影响用户体验的决定。

【两方面原因,设计师无法担起重任时,项目经理不得不事必躬亲,在双方不信任的情况下自然会出现各种矛盾】

5. 过分关注数据(定量测量)

当一个网站完工后,你会听到项目团队在讨论各种数据,独立访问的数据,注册量,PV数据等等。不幸的是,产品或者网站的可用性却没那么容易度量。与此同时,项目团队或许会意识到一堆被忘记的问题,或者是网站关键页面的低PV,他们却很少能够理解用户的操作方式,什么才是提高的可用性以解决问题的关键。

【数据只能代表过去,只是暂时的,而可用性则是一个长期的,见效慢的过程,做数据很快,而做口碑则需要积累】

6. 太多的决策者

当 一个项目小组中出现太多的决策者或者是一个很大的团队没有清晰的项目领导或角色定义时,这个小组会收到太多相互冲突的关于产品应该如何设计的观点,通常情 况,这个小组会讨论,视图将接口转化成他们自己“认为”的有利于项目的方式,一旦这种未经检查的产品开发方式变成了妥协、投机和自我意识,项目小组将会很 少乃至不会再去理智的检查他们的想法,最终导致失去为用户设计产品以满足用户需求这一目标。

【产品设计师、项目经理、首席工程师,如果这三者都意见不一,如何让工人们做出一个意义明确的产品】

7. 定义不明确的项目目标

在 每接触一个新客户的时候,我们总是惊讶的发现很少有项目有明确的目标。当项目没有确定的目标,这种产品或是服务所呈现的是一种偶然的上升趋势,随着时间的 推移,项目团队失去了信心,而用户则流失于那些并不匹配的特性和功能。平衡清晰的商业目标与清晰的用户目标是提供给用户一贯的好的体验的重要方面。

【明确的目标也要适度,给予工程师与设计师一定的发挥空间,当然,前提是这个工程师和设计师愿意发挥,如果是那种不喜欢创造或者实力还达不到创新,最好是事无巨细交代清楚,否则不仅效率低下,做出来的结果也不好】

8. 没有为提升用户体验提供激励

极 少团队会在产品开发过程中为提升用户体验提供激励,大部分时候,公司采取更为传统或者是以指标(客户满意度、预算、交通、产出等)的方式来奖励团队。显而 易见的是,如果项目小组没有在提升可用性过程中得到奖励,他们将会将工作的重心放在那些可以让他们得到关注和奖励的方面。在项目的开始就以规范的基准建立 可用性测试,这将在任何项目中为测量与激励可用性提升提供一个很好的方式。

【这的确是一个问题,很少有公司会为提升用户体验而给工程师奖励,工程师会认为这是设计师的工作而不会主动去思考,结果仍旧是双反扯皮,妥协】

9. 他们只是没有意识到可用性差而已

很 多客户告诉我们,他们已经知道其产品或者服务的问题出在哪,但他们还是很惊讶我们的报告中出现的那些他们并没有关注过的可用性问题。除非你的确进行了规范 的可用性测试,很难想像问题出在哪。顾客的意见,投诉和网站分析有时可以告诉你出现了问题,但很少能够让你深入了解问题在哪以及为什么会出现问题。这些问 题只能通过观察用户如何使用产品与服务来发现,但很多团队从未这样做过。

【可用性测试的规范很多,去google搜索一下usability checklist就可以了】

10. 见树不见林

我 们都曾经历过以为自己做出那种类似已经很好不能更好的决定的感觉,这在项目的全过程中都有可能发生,人们过于熟悉自己的产品或者服务之后,无法退一步去考 虑全局,因为他们无法再从用户的角度去看整个项目,最终一手导致了差可用性的出现。引入中立的、长期的建议机制是从客观的角度去制定决策以及消除可用性问 题至关重要的解决方式。

做一个好用的产品和服务是很难的,但消除差的可用性则可以从一开始建立目标就开始,贯彻整个项目周期。

posted @ 2011-03-26 10:19  radom  阅读(483)  评论(0编辑  收藏  举报