软件设计中的易用性

软件设计中的易用性摘要：这篇文章介绍了软件设计中“易用性”的概念并解释了为什么它在软件设计项目中应该是一个重要的部分。介绍应用“易用性”到软件开发中“易用性Usability（又被译为可用性）”这个词在软件开发中表现为这样一种方式，即把用户而非系统置于开发过程的中心。这种被称为“以用户为中心进行设计”的概念，是指从设计过程的开端便把用户所关注的东西包含于其中，并规定用户应该是任何设计决定中最重要的因素。这种“以用户为中心进行设计”的方式最显著的方面便是易用性测试。在易用性测试中，用户对产品界面进行交互式的测试，并与开发、设计人员交流他们的观点和所关注的问题。这篇文章讨论了“易用性”的概念及为什么它应该是软件设计项目中重要的组成部分。第一部分解释了在软件开发中“易用性”意味着什么，它跟产品价值的其他衡量标准如何相关。第二部分阐明了“易用性”的重要性及怎样把“以用户为中心进行设计”的原则包含于开发过程中等常见问题。这篇文章的末尾提供了一份有关的书籍、文章、组织名单，这份名单可以帮助你更多地了解易用性及如何把之应用于你的项目。这篇文章中的大部分原则都适用于零售软件（retailsoftware）的开发和内部应用软件(internalsoftware)的开发。当你深入阅读时，请注意象“用户”和“产品”这样的词，思考它们和你自己的项目之间的关系，思考那些产品最终用户的需求。定义易用性容易使用“易用性”是一个衡量标准，用来衡量使用一个产品完成指定任务的难易程度。这跟“功能性（utility）”、“喜欢（likeability）”这些相关的概念是不一样的。易用性Vs功能性（Usabilityvs.Utility）决定一个产品能否被用户接纳的关键是它是否有用，即实际使用它能否完成设计人员原本期望用户去完成的目标。“有用(Usefulness)”这个概念可以进一步分为“易用性(utility)”和“功能性(utility)”。尽管这两个词是相关的，但它们却是不可以相互替换的。功能性是指产品完成任务的能力。产品被设计为能完成更多的任务，那么产品的功能性就越强。让我们看看80年代末微软的MS_DOS版文字处理程序，该程序提供了很多很强的文字编辑功能，但是要求用户必须学习并记住很多神秘的按键才能完成任务。象这样的程序可以说具有很高的功能性（它们提供给用户很多必要的功能）但易用性很低（用户必须花大量时间和精力去学习、使用它们）。与此形成对照的是，一个设计得很好、简单的应用程序，比如计算器程序，很容易使用，但却没有提供多少功能。这两种特性对于产品被市场接纳都是必要的。二者都是产品“有用”这个整体概念的组成部分。明显地，如果一个程序非常容易使用但却没有什么功能，没有人会有理由去使用它。而如果给用户一个功能非常强大的程序，但却很难使用，那么用户将很可能会抵制它或者寻求其他替代物。易用性测试帮助你确定用户能否容易地执行特定的任务。但是，它并不能直接帮助你确定产品本身是否有价值或有功能。（用户在易用性测试中也许会主动提供跟功能性有关的评论，但是任何这样的评论应该通过别的、更加可靠的研究方法来验证）。喜欢它Vs使用它（LikingItvs.UsingIt）在一个产品中“受人喜欢”总是一个令人想要的特性。如果人们喜欢这个产品，他们更可能会去使用它并推荐给他人。但是你应该小心，不要把“受人喜欢”和“易用性”混淆。人们经常会因为一些跟产品的易用性和功能性无关的理由而喜欢一个产品。他们常常因产品的式样外观或相信产品能赋予他们某种身份而被吸引。人们倾向于喜欢易于使用的产品，但你并不应该因此断定一个受人喜欢的产品是易用的。易用性是关于用户能否使用产品来完成他们需要完成的任务。易用性测试主要衡量产品的性能，而非用户对它的偏爱。但是，可以用标准化的问卷调查测定用户对产品之间的偏爱。发现Vs弄懂Vs效率易用性有很多方面，但传统上这个词特别是指“发现”、“弄懂”、“效率”等特征。“发现（Discovery）”涉及用户根据需求去查找产品的某项功能（feature）。易用性测试可以测定用户找到某项功能需要花多长时间及用户在查找过程中会犯多少错误（找错位置）。“弄懂（Learning）”涉及这样一个过程，即用户通过这个过程弄懂怎样去使用某项已发现的功能特点去完成手头上的任务。易用性测试可以测定这个过程需要多长时间及用户学会这个特点会犯多少错误。“效率（Efficiency）”涉及一个时候，在此刻用户已经“精通”产品的功能并且不再需要进一步学习便可以使用它。易用性测试可以确定有经验的用户去使用某项功能特点所执行必须的步骤需要多长时间。手头上任务的性质和用户执行任务的频率强烈影响易用性的这三个基本方面。有些功能很少被使用或者太复杂以至于用户本质上必须每次都重新学习它，对于这些功能，微软经常通过向导（wizard）方式来引导用户。口号不起作用软件设计人员有时会认为象“让产品更易用“这样的简单口号将帮助解决易用性问题。面对易用性的积极态度是重要的，但只有让普通用户对产品进行适当的易用性测试，才能提供给设计人员要创造出一个能满足用户需要的产品所需的有关信息。“让产品更易用”应该是每一个软件设计人员的座右铭，但是只有当设计人员明白”易用性“的含义这句话才有意义。对普通用户进行测试是确定易用性最可靠的方式。经常被问到的问题(FAQ)为什么我应该关心？如果你还没有把对易用性的考虑包含进你的产品设计过程中，你也许想知道为什么它是必须的或值得要的。归根结底，根本不进行任何易用性测试工作就可以发布一个可以运行的、没有错误的产品肯定是可能的，但是把“以用户为中心”的设计原则包含到设计过程中，会制造出一个在很多方面都被改进的产品。进行易用性测试的最佳理由是减少用户寻求技术支持服务电话的数量。糟糕的易用性是用户打软件技术支持服务热线的主要原因，每一家软件公司的信息服务经理知道产品支持是多么地昂贵。再者，向用户收取支持服务费用将增加用户对产品潜在的不满意。如果用户觉得很容易使用你们的产品，他们将不需要经常拨大技术支持服务电话。对于为内部使用开发的软件，把易用性作为开发过程中的重要部分的另一个最好理由是可以减少培训费用。一个很易用的产品比一个不重视易用性的产品让用户更加容易学习。用户能更快地学会功能特点，能更长时间地记得他们所学会的，这跟减少培训费用和培训时间直接相关。易用性测试帮助提高用户对产品的认可程度。用户的认同源自于多种因素，包括“易用性”、“功能性”、“喜欢”。对于零售产品，用户的认可经常与重复购买或忠诚度直接相关，这意味着用户很可能向其他人推荐产品。对于内部使用的程序，用户的认可关系到用户是否愿意使用该软件，去完成能帮助提高生产率的任务。增强的易用性是能提高用户认可度的因素之一。易用性能帮助把你的产品和竞争者的产品区分开来。如果两个产品在功能方面几乎是一样的，更易用的产品将可能被认为是更好的。另外，微软的Windows®风格外观和相应的编程规范造就了一致的基本用户界面，所以提供相似功能的很多程序看上去和用起来都很类似。这些相似性意味着，易用性方面的的细小差异可以对用户的偏爱有很大的影响。最后，请记住：每个产品最终都会得到易用性测试。用户每次使用你的产品就是在进行易用性测试，用户通过不断地使用或很少使用产品的行动来给予他们的“裁决”。在产品发布到市场之前测试产品，你可以确保用户对产品的体验将是正面的。它花费多少？软件设计人员和项目经理经常担忧启动以用户为中心的设计过程及进行适当的易用性测试将需要无法接受的的时间和金钱。事实上，聚焦于用户所花费的时间和金钱常常是相对较小的，而且与不聚焦于用户所导致的花费相比肯定是较小的。例如，考虑一下在开发周期的后期对设计进行修改所花费的时间和金钱，与早期进行修改所需的花费（那个时候产品还在绘图板上）之间的对比。如果你等到beta时期才把产品交给用户进行易用性测试，你也许会发现自己忙于把已经花了很多时间所开发的程序分解为多个部分。如果你等到产品实际发布之后，然后根据负面性的反馈才去变更或向糟糕的设计提供技术支持，会因为很高的产品技术支持费用或用户的不满，使得代价非常高。一项合理的易用性研究通常可以在两个星期左右内完成，可大大地减少随后在开发周期中变更所导致的费用。进行测试所涉及的费用随产品的性质和欲进行测试的界面多少而异。你可以把易用性测试与代码测试认为是类似的。成功的项目经理在计划一个开发项目时会觉得代码测试是合理的开销，他们不会把它看做是附加在项目日程计划和预算上的额外东西。项目经理更愿意接受代码测试，把之作为正常的开支之一，因为其他替代方式会将昂贵得多。同样地这也适用于易用性测试。我怎么去得到一些易用性?在阅读和理解“易用性”的重要性的时候，软件设计人员有时也被诱惑去“获得一些”易用性，似乎它是一种可以简单地添加，使得一个产品更易用的成份。恰恰相反，易用性应该是设计过程本身的一部分，而不是一种你可以随意添加到过程中的某种东西。易用性专家提到要“聚焦于用户”及“以用户为中心进行设计”的理由是，易用性取决于把用户的需要保持作为设计过程的中心。以用户为中心进行设计必然地涉及到更多的东西，不仅仅只是遵循一套规定在界面上按钮、菜单如何摆放的规则。易用性测试是一个可以检查你的设计工作的机会，它不是一种把易用性“添加”于你的产品中的途径。Gould,Boies,和Lewis(1991)确定了“以用户为中心进行设计”的四个重要原则：•尽早聚焦于客户的需求。设计人员在设计过程的早期就应该专注于理解用户的需要。•完整综合的设计。设计的各个方面应该平行地进展，而非顺序地进行。应该保持产品的内部设计和用户界面需求相一致。•较早地并持续不断地测试。软件设计中目前唯一可行的途径是经验主义式的：只有实际用户认为设计好那么这个设计才是好的。把易用性测试贯穿于整个开发过程，可以让用户在产品发布之前对设计给予一个反馈的机会•反反复复的设计。大问题经常掩盖小问题。设计人员和开发人员应该通过多轮测试反复修正设计。为什么我们应该让用户参与其中？设计人员应该明白他们他们并不是典型用户。他们比一般的普通用户对他们正在开发的软件熟悉得多。对大多数用户而言不清楚或令人糊涂的界面，对一直在开发这个项目的人员而言却是非常清晰的。有些软件设计人员在某种程度上能理解一般用户的感受，但是并没有什么可以替代物可以代替实际用户对产品的真实交互反应。因此，通过尽早聚焦于典型用户的需要并经常根据用户测试修正设计，软件设计人员能创造出更好的设计，作为结果，那就是更好的产品。更好的设计会得到来自用户更好的认可。对于零售软件，增加的购买所带来的好处是明显的：销量增加了。对于为内部使用所开发的软件，来自用户的认可也是重要的：增加的使用会导致生产率的提高和对技术支持需求的减少。从开发过程的开始就明显地让用户参与其中也向他们表明你对他们的关心和需要是关注的，也因此会增加他们去帮助你们开发更好软件的意愿。为什么我不能仅仅遵循指南？微软已经开发出一套windows平台的界面指导规范以确保windows程序具有一致性的外观。其他公司也开发出针对其他平台的类似指南。象JakobNielsen这样的易用性专家已经写了很多关于设计易用的网页方面的文章。有关于这些主题的大量信息可以获得，有时设计人员相信严格地遵循这些指南和标准便是制造出易用的产品所需的全部。关于这种方式存在问题在于指南在本质上就是概括性的。指南必须适用于各种情况，因此并不总是能为你正在设计的特定程序提供了最佳的行动指南。遵循一个写得很好的指南可以帮助你设计出一个一致性的界面，但你不能肯定它就是易用的，除非你让真正的用户对其进行测试。当你使用指南的时候，不要象使用食谱那样去使用它们，不要期待一个指南为你指出可以获得全部最佳结果的道路。两个设计人员可以两种不同的方式实施同一指南，而且两种实施也许都不适合于情况。而且，有时候严格遵循指南会导致一个糟糕的结果，或者导致指南间的冲突。在这些问题真正成为问题之前，只有以用户为中心的设计才能帮助解决这些问题。让我们以另外一种方式来考虑这个问题吧：