软件设计中的易用性

软件设计中的易用性

摘要：这篇文章介绍了软件设计中“易用性”的概念并解释了为什么它在软件设计项目中应该是一个重要的部分。

介绍

应用“易用性”到软件开发中

“易用性Usability（又被译为可用性）”这个词在软件开发中表现为这样一种方式，即把用户而非系统置于开发过程的中心。这种被称为“以用户为中心进行设计”的概念，是指从设计过程的开端便把用户所关注的东西包含于其中，并规定用户应该是任何设计决定中最重要的因素。

这种“以用户为中心进行设计”的方式最显著的方面便是易用性测试。在易用性测试中，用户对产品界面进行交互式的测试，并与开发、设计人员交流他们的观点和所关注的问题。

这篇文章讨论了“易用性”的概念及为什么它应该是软件设计项目中重要的组成部分。第一部分解释了在软件开发中“易用性”意味着什么，它跟产品价值的其他衡量标准如何相关。第二部分阐明了“易用性”的重要性及怎样把“以用户为中心进行设计”的原则包含于开发过程中等常见问题。这篇文章的末尾提供了一份有关的书籍、文章、组织名单，这份名单可以帮助你更多地了解易用性及如何把之应用于你的项目。

这篇文章中的大部分原则都适用于零售软件（retail software）的开发和内部应用软件(internal software)的开发。当你深入阅读时，请注意象“用户”和“产品”这样的词，思考它们和你自己的项目之间的关系，思考那些产品最终用户的需求。

定义易用性

容易使用

“易用性”是一个衡量标准，用来衡量使用一个产品完成指定任务的难易程度。这跟“功能性（utility）”、“喜欢（likeability）”这些相关的概念是不一样的。

易用性Vs 功能性（Usability vs. Utility）

决定一个产品能否被用户接纳的关键是它是否有用，即实际使用它能否完成设计人员原本期望用户去完成的目标。“有用(Usefulness)”这个概念可以进一步分为“易用性(utility)”和“功能性(utility)”。尽管这两个词是相关的，但它们却是不可以相互替换的。

功能性是指产品完成任务的能力。产品被设计为能完成更多的任务，那么产品的功能性就越强。

让我们看看80年代末微软的MS_DOS版文字处理程序，该程序提供了很多很强的文字编辑功能，但是要求用户必须学习并记住很多神秘的按键才能完成任务。象这样的程序可以说具有很高的功能性（它们提供给用户很多必要的功能）但易用性很低（用户必须花大量时间和精力去学习、使用它们）。与此形成对照的是，一个设计得很好、简单的应用程序，比如计算器程序，很容易使用，但却没有提供多少功能。

这两种特性对于产品被市场接纳都是必要的。二者都是产品“有用”这个整体概念的组成部分。明显地，如果一个程序非常容易使用但却没有什么功能，没

有人会有理由去使用它。而如果给用户一个功能非常强大的程序，但却很难使用，那么用户将很可能会抵制它或者寻求其他替代物。

易用性测试帮助你确定用户能否容易地执行特定的任务。但是，它并不能直接帮助你确定产品本身是否有价值或有功能。（用户在易用性测试中也许会主动提供跟功能性有关的评论，但是任何这样的评论应该通过别的、更加可靠的研究方法来验证）。

喜欢它Vs 使用它（Liking It vs. Using It）

在一个产品中“受人喜欢”总是一个令人想要的特性。如果人们喜欢这个产品，他们更可能会去使用它并推荐给他人。但是你应该小心，不要把“受人喜欢”和“易用性”混淆。

人们经常会因为一些跟产品的易用性和功能性无关的理由而喜欢一个产品。他们常常因产品的式样外观或相信产品能赋予他们某种身份而被吸引。人们倾向于喜欢易于使用的产品，但你并不应该因此断定一个受人喜欢的产品是易用的。

易用性是关于用户能否使用产品来完成他们需要完成的任务。易用性测试主要衡量产品的性能，而非用户对它的偏爱。但是，可以用标准化的问卷调查测定用户对产品之间的偏爱。

发现Vs弄懂Vs 效率

易用性有很多方面，但传统上这个词特别是指“发现”、“弄懂”、“效率”等特征。

“发现（Discovery）”涉及用户根据需求去查找产品的某项功能（feature）。易用性测试可以测定用户找到某项功能需要花多长时间及用户在查找过程中会犯多少错误（找错位置）。

“弄懂（Learning）”涉及这样一个过程，即用户通过这个过程弄懂怎样去使用某项已发现的功能特点去完成手头上的任务。易用性测试可以测定这个过程需要多长时间及用户学会这个特点会犯多少错误。

“效率（Efficiency）”涉及一个时候，在此刻用户已经“精通”产品的功能并且不再需要进一步学习便可以使用它。易用性测试可以确定有经验的用户去使用某项功能特点所执行必须的步骤需要多长时间。

手头上任务的性质和用户执行任务的频率强烈影响易用性的这三个基本方面。有些功能很少被使用或者太复杂以至于用户本质上必须每次都重新学习它，对于这些功能，微软经常通过向导（wizard）方式来引导用户。

口号不起作用

软件设计人员有时会认为象“让产品更易用“这样的简单口号将帮助解决易用性问题。面对易用性的积极态度是重要的，但只有让普通用户对产品进行适当的易用性测试，才能提供给设计人员要创造出一个能满足用户需要的产品所需的有关信息。“让产品更易用”应该是每一个软件设计人员的座右铭，但是只有当设计人员明白” 易用性“的含义这句话才有意义。对普通用户进行测试是确定易用性最可靠的方式。

经常被问到的问题(FAQ)

为什么我应该关心？

如果你还没有把对易用性的考虑包含进你的产品设计过程中，你也许想知道为

什么它是必须的或值得要的。归根结底，根本不进行任何易用性测试工作就可以发布一个可以运行的、没有错误的产品肯定是可能的，但是把“以用户为中心”的设计原则包含到设计过程中，会制造出一个在很多方面都被改进的产品。

进行易用性测试的最佳理由是减少用户寻求技术支持服务电话的数量。糟糕的易用性是用户打软件技术支持服务热线的主要原因，每一家软件公司的信息服务经理知道产品支持是多么地昂贵。再者，向用户收取支持服务费用将增加用户对产品潜在的不满意。如果用户觉得很容易使用你们的产品，他们将不需要经常拨大技术支持服务电话。

对于为内部使用开发的软件，把易用性作为开发过程中的重要部分的另一个最好理由是可以减少培训费用。一个很易用的产品比一个不重视易用性的产品让用户更加容易学习。用户能更快地学会功能特点，能更长时间地记得他们所学会的，这跟减少培训费用和培训时间直接相关。

易用性测试帮助提高用户对产品的认可程度。用户的认同源自于多种因素，包括“易用性”、“功能性”、“喜欢”。对于零售产品，用户的认可经常与重复购买或忠诚度直接相关，这意味着用户很可能向其他人推荐产品。对于内部使用的程序，用户的认可关系到用户是否愿意使用该软件，去完成能帮助提高生产率的任务。增强的易用性是能提高用户认可度的因素之一。

易用性能帮助把你的产品和竞争者的产品区分开来。如果两个产品在功能方面几乎是一样的，更易用的产品将可能被认为是更好的。另外，微软的Windows®风格外观和相应的编程规范造就了一致的基本用户界面，所以提供相似功能的很多程序看上去和用起来都很类似。这些相似性意味着，易用性方面的的细小差异可以对用户的偏爱有很大的影响。

最后，请记住：每个产品最终都会得到易用性测试。用户每次使用你的产品就是在进行易用性测试，用户通过不断地使用或很少使用产品的行动来给予他们的“裁决”。在产品发布到市场之前测试产品，你可以确保用户对产品的体验将是正面的。

它花费多少？

软件设计人员和项目经理经常担忧启动以用户为中心的设计过程及进行适当的易用性测试将需要无法接受的的时间和金钱。事实上，聚焦于用户所花费的时间和金钱常常是相对较小的，而且与不聚焦于用户所导致的花费相比肯定是较小的。

例如，考虑一下在开发周期的后期对设计进行修改所花费的时间和金钱，与早期进行修改所需的花费（那个时候产品还在绘图板上）之间的对比。如果你等到beta 时期才把产品交给用户进行易用性测试，你也许会发现自己忙于把已经花了很多时间所开发的程序分解为多个部分。如果你等到产品实际发布之后，然后根据负面性的反馈才去变更或向糟糕的设计提供技术支持，会因为很高的产品技术支持费用或用户的不满，使得代价非常高。

一项合理的易用性研究通常可以在两个星期左右内完成，可大大地减少随后在开发周期中变更所导致的费用。进行测试所涉及的费用随产品的性质和欲进行测试的界面多少而异。

你可以把易用性测试与代码测试认为是类似的。成功的项目经理在计划一个开发项目时会觉得代码测试是合理的开销，他们不会把它看做是附加在项目日程计划和预算上的额外东西。项目经理更愿意接受代码测试，把之作为正常的开