在工作中体现可用性
在创建软件的环境中,术语“可用性”表示一种方法,它将用户而不是系统摆在过程的中心。这一方法称作以用户为中心的设计,它从设计过程的一开始就将用户关心的问题和意见考虑在内,并提出在任何设计决策中用户的需要都应摆在首位。
这种方法最显著的特点就是可用性测试。在测试中,用户使用产品的界面进行工作,通过界面进行交互,就他们的观点和关心的问题与设计人员和开发人员进行交流。
本文讨论了可用性的概念,并讨论了为什么可用性在所有软件设计项目中都是一个重要部分。本文的第一部分定义了在软件开发环境中可用性意味着什么,以及它与衡量产品价值的其它方面间的关联。第二部分回答了一些常见的问题,包括:为什么可用性很重要,以及如何在开发过程中体现以用户为中心的设计理念等。本文在结尾处列出了一些书籍、论文和组织机构名称,帮助您加深对可用性的了解,并在项目中应用可用性。
本文中讨论的大部分概念在零售和内部软件开发中均有所应用。在阅读本文时,请注意“用户”和“产品”等词语,并思考如何将其应用到您的项目和最终用户中。
可用性定义
易于使用
可用性是衡量使用一种产品来执行指定任务的难易程度的尺度,它与实用性和受欢迎度等相关概念是有差异的。
可用性与实用性
决定产品可接受性的核心属性是其有用性,它用于评价实际使用产品时,是否能达到设计人员期望产品实现的目标。有用性的概念可以进一步划分为实用性和可用性。虽然这些术语间有联系,但它们却不能相互替代。
实用性指产品执行任务的能力。根据设计,产品执行的任务越多,其实用性就越高。
让我们以二十世纪八十年代末问世的典型 Microsoft® MS-DOS® 字处理程序为例。此类程序提供了多种强大的文本编辑和处理功能,但需要用户学习和记忆几十个令人费解的按键后才能执行这些功能。可以说此类应用程序具有很高的实用性(它们为用户提供了必要的功能),但其可用性却较差(用户必须花费大量的时间和精力来学习和使用它们)。与之形成对比的是,一个设计合理的简单的应用程序(如计算器)使用起来很容易,但其实用性却有欠缺。
这两种性质都是一种产品被市场接受所必需的,而且它们都是总的有用性概念的一部分。显然,若程序很好用但没有什么有价值的功能,那么没有人会使用它;如果程序的功能强大但却很难使用,那么用户也很可能会拒绝这个程序而转向其它的替代品。
可用性测试帮助您判断用户使用产品执行特殊任务的难易程度。但是,它并不能直接帮助您判断产品自身是否有价值、是否实用(在可用性测试中,用户可能会主动提出一些关于实用性的意见,但任何意见都应通过其它更可靠的研究方法予以验证)。
喜欢它与使用它
受欢迎度往往表示产品中可取的特性。如果人们喜欢某产品,就更有可能使用它,并将它推荐给其他人。但是,与实用性一样,您一定要小心不要将受欢迎度和可用性混淆。
人们喜欢某产品的原因往往与实用性和可用性无关。他们可能被产品的样式和引人注目的外观吸引,或被心目中所赐予的该产品的地位吸引。人们倾向于喜欢很好用的产品,但这并不是说人们普遍喜爱的产品就是可用的。
可用性是指人们是否可以使用该产品来执行他们需要执行的任务。可用性测试主要用于评价性能而不是评价喜爱程度,但标准化的调查问卷也可以用来衡量人们对产品的喜爱程度。
发现、学习与有效性
可用性包含很多方面,但通常这一术语特指发现、学习和有效性这三种属性。
发现表示针对某种特定的需要去寻找并找到产品的某一功能。可用性测试可用于确定用户找到某一功能所用的时间,以及在整个过程中用户犯了多少错误(关于定位的错误选择)。
学习表示用户弄清楚如何运用所发现的功能来完成现有任务的过程。可用性测试可以确定这个过程的长短,以及在学习该功能期间用户犯了多少错误。
有效性表示用户“掌握”了某项功能,不再需要进一步学习即可使用。可用性测试可以确定有经验的用户使用该功能时执行必要步骤所需的时间。
可用性的这三个基本方面在很大程度上受到当前任务性质和用户执行任务的频率的影响。有些功能的使用频率很低或者使用起来十分复杂,导致用户基本上每次使用时都要重新学习;对于这些功能,Microsoft 通常开发了使用向导,在整个使用过程中对用户予以指导。
光喊口号是不够的
软件设计人员有时以为简单的口号,如“使产品更可用”,就可以解决可用性问题。虽然对可用性的积极态度是重要的,但是只有在具体的产品创建环境中,通过对普通用户进行恰当的可用性测试,才能为设计人员提供所需的信息,使产品可以满足用户的需要。“使产品更可用”应当成为每个软件设计人员的座右铭,但是这句话只对那些了解“可用性”含义的设计人员才有意义。而对普通用户进行测试就是可以找到的最可靠的途径。
常见问题
为什么要强调可用性问题呢?
如果您还没有在产品设计过程中将可用性因素考虑在内,您可能会问:可用性为什么是必要的,或可用性为什么是可取的?毕竟,不进行任何可用性工作,也可能发售一个可以工作的、没有错误的产品。但是,通过引入以用户为中心的设计理念可以使产品在很多方面得以很大改进。
减少用户拨打技术支持电话的次数是执行可用性测试的最佳理由。较差的可用性是用户拨打软件技术支持热线的主因,而每个软件公司主管以及信息服务经理都知道产品支持的成本是多么昂贵。此外,用户不得不寻求技术支持增加了用户对产品的潜在不满情绪。如果用户发现贵公司的产品使用起来十分容易,那么他们就不必频繁地打电话寻求技术支持了。
对于内部使用的软件,之所以将可用性作为开发过程中的一个重要部分,其原因还在于它减少了培训费用。对用户而言,可用性强的软件学习起来比可用性不受重视的产品学习起来要容易得多。用户能够更快地了解产品的各项功能,并能长久地掌握它,这直接减少了培训费用和时间。
可用性测试有助于促进用户对产品的接受程度。有很多因素决定了用户对产品的接受程度,这些因素包括可用性、实用性和受欢迎度。对于零售产品,用户的接受程度往往直接影响对产品的重复购买或对产品的忠诚度,这说明用户可能将产品推荐给其他人。对于内部应用程序,用户的接受程度决定用户是否愿意使用该软件执行任务,而这些软件就是针对这些任务设计的,这有助于提高生产效率。提高可用性是提高用户对产品的接受程度的一个因素。
可用性可将您的产品与您的竞争对手的产品区分开来。如果两个产品在实用性方面从本质上讲是一样的,那么人们很可能认为可用性更好的产品高出一筹。此外,由于 Microsoft® Windows® 的外观和感受以及随附的编程准则划定了基本用户界面的使用区域的标准,因此很多执行相似功能的程序其外观与操作在相当大的程度上是相似的。这些相似性表明,即使可用性上的细微差异也会对用户的喜好产生重大的影响。
最后请记住,每个产品最终都要进行可用性测试。用户每次使用您的产品时,都是在对它进行可用性测试,而他们对可用性优劣的意见将会影响他们是否继续使用该产品。将产品推向市场之前,对产品进行测试,可以有助于确保用户对产品的满意程度。
它的花费是多少?
软件设计人员和项目经理往往担心,如果采用以用户为中心的设计过程并执行适当的可用性测试,恐怕要占用大量的时间并花费大量的金钱。事实上,花费在关注用户方面的时间和金钱通常是相当少的,而且与不这样做而导致的花费相比,这点花费也是微不足道的。
例如,设想一下在开发周期的后期而不是在前期(产品仍处在开发阶段时)对设计进行修正您要花费多少时间和金钱吧!如果您一直等到 Beta 测试时期才使用户接触到产品以便进行可用性测试,就会发现自己不得不将花费了大量时间开发的程序的各部分分拆重做。而若等到产品真正发布时,如果要根据负面反馈进行修改或支持较差的设计,因为产品支持的庞大开销或用户对产品的接受程度较差等原因,很可能要支付高昂的费用。
合理的可用性研究通常只需要两周或更短的时间,并可以显著减少开发周期后期进行修改所需的时间和金钱。进行测试所需的花费将根据您的产品的性质以及所测试的界面部分的不同而有所不同。
可以认为可用性测试与代码测试是类似的。成功的项目经理在计划开发项目时总是会考虑到代码测试。他们并不认为代码测试是项目时间表或预算外的额外部分,而是将代码测试作为开发过程的一部分而计入成本。因为若不进行代码测试,那么花费反而会高得多。对于可用性测试,情况也是如此。
怎样获得可用性?
在理解可用性的重要性基础上,软件设计人员有时试图“获得”一些可用性,就好象可用性是一种成分,他们可以简单地把它添加到产品中,这样产品就更可用了。然而,可用性应当是设计过程本身的一部分,不是您可以在设计过程的随便某一地方添加的“东西”。可用性专家提到“用户关注的”与“以用户为中心的设计”的原因是:可用性取决于将用户的需要一直作为设计过程的中心。以用户为中心的设计根据需要的不同,包含的内容不单单是在界面中按照一组规则,对按钮和菜单布置进行管理。可用性测试是对设计工作进行检查的良机,而不是在产品中“添加”可用性的一种方法。
Gould、Boies 和 Lewis (1991) 为以用户为中心的设计定义了 4 个重要的原则:
及早以用户为中心:设计人员应当在设计过程的早期就致力于了解用户的需要。
综合设计:设计的所有方面应当齐头并进的发展,而不是顺次发展。使产品的内部设计与用户界面的需要始终保持一致。
及早并持续性地进行测试:当前对软件测试的唯一可行的方法是根据经验总结出的方法,即若实际用户认为设计是可行的,它就是可行的。通过在开发的全过程引入可用性测试,可以使用户有机会在产品推出之前就设计提供反馈意见。
反复式设计:大问题往往会掩盖小问题的存在。设计人员和开发人员应当在整个测试过程中反复对设计进行修改。
为什么应当将用户融入进来?