软件设计中的可用性

 

软件设计中的可用性

Microsoft Corporation
2000 年 10 月

摘要： 本文介绍了可用性的概念，说明为什么可用性应当是所有软件设计项目中的一个重要部分。

目录

·                     简介

·                     可用性定义

·                     常见问题

·                     资源

---

简介

在工作中体现可用性

在创建软件的环境中，术语 “ 可用性 ” 表示一种方法，它将用户而不是系统摆在过程的中心。这一方法称作以用户为中心的设计，它从设计过程的一开始就将用户关心的问题和意见考虑在内，并提出在任何设计决策中用户的需要都应摆在首位。

这种方法最显著的特点就是可用性测试。在测试中，用户使用产品的界面进行工作，通过界面进行交互，就他们的观点和关心的问题与设计人员和开发人员进行交流。

本文讨论了可用性的概念，并讨论了为什么可用性在所有软件设计项目中都是一个重要部分。本文的第一部分定义了在软件开发环境中可用性意味着什么，以及它与衡量产品价值的其它方面间的关联。第二部分回答了一些常见的问题，包括：为什么可用性很重要，以及如何在开发过程中体现以用户为中心的设计理念等。本文在结尾处列出了一些书籍、论文和组织机构名称，帮助您加深对可用性的了解，并在项目中应用可用性。

本文中讨论的大部分概念在零售和内部软件开发中均有所应用。在阅读本文时，请注意 “ 用户 ” 和 “ 产品 ” 等词语，并思考如何将其应用到您的项目和最终用户中。

可用性定义

易于使用

可用性是衡量使用一种产品来执行指定任务的难易程度的尺度，它与实用性和受欢迎度等相关概念是有差异的。

可用性与实用性

决定产品可接受性的核心属性是其有用性，它用于评价实际使用产品时，是否能达到设计人员期望产品实现的目标。有用性的概念可以进一步划分为实用性和可用性。虽然这些术语间有联系，但它们却不能相互替代。

实用性指产品执行任务的能力。根据设计，产品执行的任务越多，其实用性就越高。

让我们以二十世纪八十年代末问世的典型 Microsoft® MS-DOS® 字处理程序为例。此类程序提供了多种强大的文本编辑和处理功能，但需要用户学习和记忆几十个令人费解的按键后才能执行这些功能。可以说此类应用程序具有很高的实用性（它们为用户提供了必要的功能），但其可用性却较差（用户必须花费大量的时间和精力来学习和使用它们）。与之形成对比的是，一个设计合理的简单的应用程序（如计算器）使用起来很容易，但其实用性却有欠缺。

这两种性质都是一种产品被市场接受所必需的，而且它们都是总的有用性概念的一部分。显然，若程序很好用但没有什么有价值的功能，那么没有人会使用它；如果程序的功能强大但却很难使用，那么用户也很可能会拒绝这个程序而转向其它的替代品。

可用性测试帮助您判断用户使用产品执行特殊任务的难易程度。但是，它并不能直接帮助您判断产品自身是否有价值、是否实用（在可用性测试中，用户可能会主动提出一些关于实用性的意见，但任何意见都应通过其它更可靠的研究方法予以验证）。

喜欢它与使用它

受欢迎度往往表示产品中可取的特性。如果人们喜欢某产品，就更有可能使用它，并将它推荐给其他人。但是，与实用性一样，您一定要小心不要将受欢迎度和可用性混淆。

人们喜欢某产品的原因往往与实用性和可用性无关。他们可能被产品的样式和引人注目的外观吸引，或被心目中所赐予的该产品的地位吸引。人们倾向于喜欢很好用的产品，但这并不是说人们普遍喜爱的产品就是可用的。

可用性是指人们是否可以使用该产品来执行他们需要执行的任务。可用性测试主要用于评价性能而不是评价喜爱程度，但标准化的调查问卷也可以用来衡量人们对产品的喜爱程度。

发现、学习与有效性

可用性包含很多方面，但通常这一术语特指发现、学习和有效性这三种属性。

发现 表示针对某种特定的需要去寻找并找到产品的某一功能。可用性测试可用于确定用户找到某一功能所用的时间，以及在整个过程中用户犯了多少错误（关于定位的错误选择）。

学习 表示用户弄清楚如何运用所发现的功能来完成现有任务的过程。可用性测试可以确定这个过程的长短，以及在学习该功能期间用户犯了多少错误。

有效性 表示用户 “ 掌握 ” 了某项功能，不再需要进一步学习即可使用。可用性测试可以确定有经验的用户使用该功能时执行必要步骤所需的时间。

可用性的这三个基本方面在很大程度上受到当前任务性质和用户执行任务的频率的影响。有些功能的使用频率很低或者使用起来十分复杂，导致用户基本上每次使用时都要重新学习；对于这些功能， Microsoft 通常开发了使用向导，在整个使用过程中对用户予以指导。

光喊口号是不够的

软件设计人员有时以为简单的口号，如 “ 使产品更可用 ” ，就可以解决可用性问题。虽然对可用性的积极态度是重要的，但是只有在具体的产品创建环境中，通过对普通用户进行恰当的可用性测试，才能为设计人员提供所需的信息，使产品可以满足用户的需要。 “ 使产品更可用 ” 应当成为每个软件设计人员的座右铭，但是这句话只对那些了解 “ 可用性 ” 含义的设计人员才有意义。而对普通用户进行测试就是可以找到的最可靠的途径。

常见问题

为什么要强调可用性问题呢？

如果您还没有在产品设计过程中将可用性因素考虑在内，您可能会问：可用性为什么是必要的，或可用性为什么是可取的？毕竟，不进行任何可用性工作，也可能发售一个可以工作的、没有错误的产品。但是，通过引入以用户为中心的设计理念可以使产品在很多方面得以很大改进。

减少用户拨打技术支持电话的次数是执行可用性测试的最佳理由。较差的可用性是用户拨打软件技术支持热线的主因，而每个软件公司主管以及信息服务经理都知道产品支持的成本是多么昂贵。此外，用户不得不寻求技术支持增加了用户对产品的潜在不满情绪。如果用户发现贵公司的产品使用起来十分容易，那么他们就不必频繁地打电话寻求技术支持了。

对于内部使用的软件，之所以将可用性作为开发过程中的一个重要部分，其原因还在于它减少了培训费用。对用户而言，可用性强的软件学习起来比可用性不受重视的产品学习起来要容易得多。用户能够更快地了解产品的各项功能，并能长久地掌握它，这直接减少了培训费用和时间。

可用性测试有助于促进用户对产品的接受程度。有很多因素决定了用户对产品的接受程度，这些因素包括可用性、实用性和受欢迎度。对于零售产品，用户的接受程度往往直接影响对产品的重复购买或对产品的忠诚度，这说明用户可能将产品推荐给其他人。对于内部应用程序，用户的接受程度决定用户是否愿意使用该软件执行任务，而这些软件就是针对这些任务设计的，这有助于提高生产效率。提高可用性是提高用户对产品的接受程度的一个因素。

可用性可将您的产品与您的竞争对手的产品区分开来。如果两个产品在实用性方面从本质上讲是一样的，那么人们很可能认为可用性更好的产品高出一筹。此外，由于 Microsoft® Windows® 的外观和感受以及随附的编程准则划定了基本用户界面的使用区域的标准，因此很多执行相似功能的程序其外观与操作在相当大的程度上是相似的。这些相似性表明，即使可用性上的细微差异也会对用户的喜好产生重大的影响。

最后请记住，每个产品最终都要进行可用性测试。用户每次使用您的产品时，都是在对它进行可用性测试，而他们对可用性优劣的意见将会影响他们是否继续使用该产品。将产品推向市场之前，对产品进行测试，可以有助于确保用户对产品的满意程度。

它的花费是多少？

软件设计人员和项目经理往往担心，如果采用以用户为中心的设计过程并执行适当的可用性测试，恐怕要占用大量的时间并花费大量的金钱。事实上，花费在关注用户方面的时间和金钱通常是相当少的，而且与不这样做而导致的花费相比，这点花费也是微不足道的。

例如，设想一下在开发周期的后期而不是在前期（产品仍处在开发阶段时）对设计进行修正您要花费多少时间和金钱吧！如果您一直等到 Beta 测试时期才使用户接触到产品以便进行可用性测试，就会发现自己不得不将花费了大量时间开发的程序的各部分分拆重做。而若等到产品真正发布时，如果要根据负面反馈进行修改或支持较差的设计，因为产品支持的庞大开销或用户对产品的接受程度较差等原因，很可能要支付高昂的费用。

合理的可用性研究通常只需要两周或更短的时间，并可以显著减少开发周期后期进行修改所需的时间和金钱。进行测试所需的花费将根据您的产品的性质以及所测试的界面部分的不同而有所不同。

可以认为可用性测试与代码测试是类似的。成功的项目经理在计划开发项目时总是会考虑到代码测试。他们并不认为代码测试是项目时间表或预算外的额外部分，而是将代码测试作为开发过程的一部分而计入成本。因为若不进行代码测试，那么花费反而会高得多。对于可用性测试，情况也是如此。

怎样获得可用性？

在理解可用性的重要性基础上，软件设计人员有时试图 “ 获得 ” 一些可用性，就好象可用性是一种成分，他们可以简单地把它添加到产品中，这样产品就更可用了。然而，可用性应当是设计过程本身的一部分，不是您可以在设计过程的随便某一地方添加的 “ 东西 ” 。可用性专家提到 “ 用户关注的 ” 与 “ 以用户为中心的设计 ” 的原因是：可用性取决于将用户的需要一直作为设计过程的中心。以用户为中心的设计根据需要的不同，包含的内容不单单是在界面中按照一组规则，对按钮和菜单布置进行管理。可用性测试是对设计工作进行检查的良机，而不是在产品中 “ 添加 ” 可用性的一种方法。

Gould 、 Boies 和 Lewis (1991) 为以用户为中心的设计定义了 4 个重要的原则：

·                     及早以用户为中心： 设计人员应当在设计过程的早期就致力于了解用户的需要。

·                     综合设计： 设计的所有方面应当齐头并进的发展，而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。

·                     及早并持续性地进行测试： 当前对软件测试的唯一可行的方法是根据经验总结出的方法，即若实际用户认为设计是可行的，它就是可行的。通过在开发的全过程引入可用性测试，可以使用户有机会在产品推出之前就设计提供反馈意见。

·                     反复式设计： 大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。

为什么应当将用户融入进来？

设计人员应当认识到他们自己不是普通的用户。与一般的用户相比，他们对正在开发的系统有着更深入的了解。因此，对大多数用户而言不明确或造成混淆的界面，可能对那些从事项目设计工作的人员来说是非常清晰的。某些软件设计人员可以在一定程度上代表普通用户，但他们绝对不能代替实际使用产品的真正用户。

因此，通过在早期关注普通用户的需要，并根据用户测试结果经常改进设计，以用户为中心的软件设计人员会提出更好的设计，并生产出更好的产品。

更好的设计将得到用户更好的认可。零售软件增加买进点的利益是很明显的：这增加了销售额。对于为内部使用而开发的软件，认可也是十分重要的：买进点增加将导致生产效率增加，并减少了对技术支持的需求。显然，从开发的一开始就将用户融入进来，并向用户表明您看重他们所关心的问题和需求，这将使用户更愿意协助您开发出更好的软件。

遵循这些准则就足够了吗？

Microsoft 为 Windows 计算平台开发了一系列界面准则，以此确保 Windows 程序具有一致的外观和感受。其它公司为非 Windows 计算平台开发了类似的准则，并且象 Jakob Nielsen 这样的专家撰写了大量关于设计可用 Web 页的文章。通过关于这些主题的大量信息，设计人员有时认为生产可用产品所需的全部工作就是严格遵守准则和规范。

这种想法的错误之处在于：准则在本质上是通用的。准则必须应用到各种各样不同的情况之中，因此它不能总是针对您正在设计的特定的应用程序制订最佳的行动方案。遵守一组合理编写的准则有助于您设计出风格一致的界面，但是您不能保证它是可用的，除非通过真正的用户对它进行了测试。当您的确要使用准则时，不要象使用详尽的说明书一样，希望根据准则执行的方法所生成的所有结果都是最好的。两个设计人员可以用两种不同的方法实施同一个准则，而两种实施方案对特定情况却不一定同等适用。而且，有时候严格遵守准则可能导致很差的结果，或在准则之间发生冲突。只有采用以用户为中心的设计，才可以在问题产生前排除它们。

对这个问题的另一种理解方式是：应当使以用户为中心的设计理念成为设计决策的决定因素，而不是以用户界面准则为决定因素。

是否需要创建可用性实验室？

不要以为可用性测试就意味着创建昂贵的实验室，在天花板上安装摄像机，安装单向镜，以及采用其它以小组为中心的设陷技术。的确，进行大量测试的公司通常认为建立专用的实验室十分方便，并且可用性顾问往往可以为客户提供各种各样的设施和设备，但您也可以在各种各样的设置和环境中执行有用、有效的可用性测试。

一种方法只需要一个测试人员（该测试人员对有人参与的研究工作与数据收集十分精通），在用户工作时坐在用户后面观察用户如何执行任务，这在会议室或办公室里就可以轻而易举地办到。 Dumas 和 Redish (1999) 提供了大量关于使用观察法进行测试的信息。

随着可用性测试的进一步进行，您可以添加诸如摄像机、单向镜等设备，或其它帮助实时观察和记录用户显示器的工具。不必一下子添加所有的设备，即使一件一件地添加，也可以使您从可用性测试中获得更多有价值的东西。

另一种方法是，您可以将测试外包给可用性顾问。关于为您寻找合适顾问的几点提示信息，请参见下文的 “ 我如何开始？ ” 。

我如何开始？

一旦您决定将以用户为中心的设计原理运用到您的开发过程中，就需要决定是自己雇佣可用性专业人员还是将可用性测试外包给供应商。

可用性专业人员协会 (UPA) 有一份供应商指南，有助于找到为您执行测试的可用性顾问。

有些咨询部门还可以帮助您创建您自己的可用性实验室或开发内部的可用性程序，在您的设计过程中引入可用性理念。

如果您宁愿自己雇佣可用性专业人员，那么 Human Factors and Ergonomics Society 有职业介绍服务，使您可以找到潜在的雇员。很多可用性专业人员还属于 ACM Special Interest Group on Computer-Human Interaction (SIGCHI) 和 UPA ，您也可以在他们的出版物和会刊上刊登招聘广告。

无论您选择哪种途径，请记住：您将要雇佣的是测试服务人员，而不是那些自己访问您的界面，并告诉您界面上有哪些错误的人员。设计人员不是普通用户的原则同样也适用于可用性专业人员。