计算机科学中最古老的笑话之一是这样的:

问: 换一个灯泡需要多少程序员?
答: 没有一个这是一个硬件问题!

当问有多少可用性专家需要换一个灯泡,答案很可能是四:两个进行野外研究和任务分析来确定人们是否真的需要光,一个观察的用户实际上螺丝灯泡,和一个控制摄像机拍摄的事件。当然,在对这些问题实施假定的解决方案之前,应该研究用户的需求。即便如此,人们认为任何涉及可用性的人都会因为预算超支而失败,这使得许多软件项目无法达到用户应得的可用性水平。

1.恐吓障碍

众所周知,人们很少使用推荐的可用性工程方法[Nielsen 1993;怀特塞德等人,1988]在现实生活中的软件开发项目。这甚至包括一些基本的可用性工程技术,如早期关注用户、经验测量和迭代设计,而这些很少被公司使用。Gould和Lewis[1985]发现,当被问及在为终端用户开发和评估一个新的计算机系统时应该做什么时,只有16%的开发人员提到了这三个原则。26%的开发者对这些极其基本的原则只字未提。最近的一项研究发现,只有21%的丹麦软件开发人员知道大声思考的方法,只有6%的人实际使用它[Milsted et al. 1989]。更高级的可用性方法根本没有使用。

可用性工程没有在实践中使用的一个重要原因是使用技术的成本。或者更确切地说,原因是使用这些技术的感知成本,因为本章将展示许多可用性技术可以非常便宜地使用。应该不足为奇,然而,从业者认为可用性方法是昂贵的考虑,例如,一篇论文在广泛阅读,非常受人尊敬的杂志通讯ACM的估计,“成本需要增加人为因素元素的发展软件”是128330美元[Mantei Teorey 1988]。这个数字是大多数小公司可用性总预算的几倍,一位界面传播者实际上发现有必要警告这样的小公司不要相信ccm的估计[Tognazzini 1990]。否则,项目经理很容易放弃任何可用性工程的尝试,因为他们相信项目的预算无法承担成本。表1显示了根据下面讨论的折扣可用性工程方法调整可用性预算的结果。表1中的数字适用于中等规模的软件项目(大约32,000行代码)。对于小型项目,甚至可以使用更便宜的方法,而真正的大型项目可能会考虑为可用性和成熟的传统方法增加额外的资金,尽管即使是大型项目也可以从使用折扣可用性工程中获得相当大的收益。

表1
在中等规模的软件项目中,通过使用折扣可用性工程方法而不是有时推荐的更彻底的可用性方法来节省成本。
最初的可用性成本估算[Mantei和Teorey 1988] 128330美元
剧本发展为纸模型,而不是在录像带上 - 2160美元
使用免费超文本包完成原型制作 - 16,000美元
所有的用户测试都是3个主题而不是5个 - 11520美元
自言自语的研究分析,通过记笔记,而不是通过偷拍 - 5520美元
特殊视频实验室不需要 - 17600美元
只有2个焦点小组,而不是3个 - $2,000
只有一个焦点小组而不是3个接受分析 - $ 4,000个
问卷仅在反馈阶段使用,不在原型测试之后使用 - 7200美元
引入可用性专家进行启发式评估 + $3,000
“折扣可用性工程”项目的成本 65330美元

英国的研究[Bellotti 1988]指出,许多开发人员不使用可用性工程,因为人机交互(HCI)方法被认为太耗时、太昂贵,而且技术往往过于复杂,令人生畏。“折扣可用性工程”方法旨在解决这两个问题。贝洛蒂给出的进一步原因是,人们有时认为没有必要进行人机交互,而且缺乏对适当技术的认识。另外两个问题必须通过教育来解决[Perlman 1988, 1990;Nielsen and Molich 1989]和宣传[Nielsen 1990a],但即使是为了这个目的,更简单的可用性方法也应该有所帮助。此外,时间本身也在增加对人机交互的需求,因为软件市场似乎正在从早些年的“功能之战”中转移(Telles 1990)。现在,大多数软件产品的功能比用户需要或了解的要多,Telles[1990]指出,在行业媒体上,“界面已经成为软件获得好评的一个重要因素”。

作为“恐吓复杂性”的一个例子,考虑卡沃斯基等人的论文〔1989〕,用模糊逻辑扩展GOMS模型〔卡等〕1983。请注意,我并不是在抱怨这样做是糟糕的研究。相反,我发现开发方法来扩展GOMS之类的模型以更好地处理不确定性和用户错误等现实环境非常令人兴奋。不幸的是,当对人机交互领域没有深入了解的软件人员阅读论文时,模糊逻辑GOMS和类似的工作很容易导致恐吓。这些读者很可能相信,这些方法代表了进行可用性工程的“方法”,即使可用性专家知道,这项研究代表了扩展该领域的探索性探索,并且只应该作为(比如)项目中使用的第五种左右的方法。有许多更简单的方法应该首先使用[Nielsen 1992a,1993]。

我当然也会对恐吓行为感到内疚。例如,我最近与Marco Bergman一起完成了一个关于迭代设计的研究项目,我们总共雇佣了99名受试者去测试不同版本的用户界面,总成本估计为62,786美元。如果人们认为迭代设计和用户测试是昂贵且过于复杂的过程,那么他们阅读这方面的报告和类似研究的论文时,可能会有借口。事实上,当然,使用更少的对象和更便宜的方法是可能的,我们小心地在我们的论文中明确地说明了这一点。一个基本的问题是,除了少数例外,发布的可用性工作描述通常描述的情况是,在获得发布质量的结果上花费了相当多的额外努力,尽管大多数开发需求可以用更简单的方式来满足。

例如,考虑统计显著性问题。最近,我有一个会议来讨论可用性工程与计算机科学的世界最著名的实验室之一,当讨论所需的各种测试,他立即指需要测试结果有统计学意义值得收集。当然,对于很多研究来说,你需要有高度的信心,你声称的发现不是偶然的。然而,对于可用接口的开发,通常可以通过不那么严格的测试来满足。

统计显著性基本上是指一个人没有做出错误结论的概率(例如,声称某个结果在p<0.05水平上具有显著性表明该结果有5%的概率是错误的)。考虑在两个可选接口设计之间选择的问题[兰道1988 ]。如果没有可用的信息,您也可以通过投掷硬币进行选择,您将有50%的概率选择最佳界面。如果进行了少量的用户测试,您可能会发现界面a在20%的显著性水平上优于界面B。尽管20%被认为“不重要”,但您的测试实际上提高了您从50/50到4/1选择最佳接口的机会,这意味着您在选择时不考虑数据是愚蠢的。此外,尽管仍有20%的概率表明接口a不比接口B好,但它不太可能比接口B差得多。这20%中的大多数都说明了两个接口相等或B略好于a的情况,这意味着选择接口a几乎永远不会是一个真正糟糕的决定。换句话说,即使是不具有统计意义的测试也值得做,因为它们将大大提高决策的质量。

打折扣的可用性工程方法

可用性专家通常会建议使用最好的方法。事实上,这正是他们在大多数大学所接受的训练。不幸的是,似乎“le miux est l'ennemi du bien”(最好的是好的敌人)(伏尔泰1764年),坚持只使用最好的方法可能导致根本没有方法使用。因此,我将专注于实现一些可用性工程工作的“好”,即使实现这个结果所需的方法肯定不是“最好”的方法,也不会给出完美的结果。

这将是容易让读者见地放下与显示将在某些情况下错过重要的可用性方面的各种知名反例在这里提出的方法。其中的一些反例是毫无疑问的真实,我不同意,更好的结果可以通过应用更加谨慎的方法来实现。但要记住,这样更加谨慎的方法也更加昂贵 - 往往在金钱方面,始终在需要专业知识方面(导致威胁因素如上所述)。因此,简单的方法经得起在实际设计的情况下实际使用一个更好的机会,因此他们应该被看作是服务于用户社区的一种方式。

“折扣可用性工程”[Nielsen 1989b, 1990a, 1993]方法是基于以下三种技术的使用:

  • 情节
  • 简化思考大声笑
  • 启发式评估

此外,应该遵循早期关注用户的基本原则。它可以通过多种方式实现,包括简单地访问客户位置。

2.1的场景

场景是一种特殊的原型,如图1所示。原型背后的整个想法是通过消除整个系统的某些部分来降低实现的复杂性。水平原型降低了功能水平,形成了用户界面表层,而垂直原型减少了功能的数量,并实现了所选功能的全部功能(即,我们得到了系统的一部分来玩)。

图1
a的概念场景相较于垂直和水平作为原型的方式,使快速成型简单。
场景是在水平和垂直上都受到限制的原型

方案通过减少功能级别和功能数量来将原型设计到极端。通过减少界面的部分被认为是最低限度,设计和实现的场景可以非常便宜,但只要测试用户遵循先前计划的路径,就可以模拟用户界面。

由于场景很小,我们可以经常更改它,如果我们使用廉价的、小型的有声思考研究,我们也可以测试每个版本。因此,场景是从用户那里快速、频繁地获得反馈的一种方式。

场景可以实现为纸上原型[Nielsen 1990b]或在简单的原型环境中[Nielsen 1989a],这可能比更高级的编程环境更容易学习[Nielsen et al. 1991]。与需要使用先进软件工具的更复杂的原型相比,这是额外的节省。

2.2大声思考

传统上,有声思维研究是由心理学家或用户界面专家作为实验人员进行的,他们会对受试者进行录像,并进行详细的协议分析。对于普通的开发人员来说,这种方法看起来确实有些吓人。然而,不需要复杂的实验室就可以运行用户测试,只需引入一些真实的用户,给他们一些典型的测试任务,并要求他们在执行任务时大声思考就可以了。那些使用过“大声思考”方法的开发人员对此很满意[Jørgensen 1989, Monk et al. 1993],而我的研究[Nielsen 1992b]表明,计算机科学家确实能够应用“大声思考”方法,通过最少的训练就能有效地评估用户界面。而且,即使是在方法上相当原始的实验,也会成功地发现许多可用性问题。

我一直认为,根据几个案例研究,从最初的几个测试用户那里学到的东西最多。在之前的文章中,我通常建议每个测试使用3到5个测试用户,这是一种简化用户测试的方法,同时可以获得与使用大量主题的更复杂的测试几乎相同的好处。最近,Tom Landauer和我开发了一个可用性问题数量的数学模型[Nielsen and Landauer 1993],当输入来自不同类型用户测试的典型预算数字时,我们得到了如图2所示的曲线,用于描述中型开发项目的用户测试收益和测试成本之间的比率。从曲线上可以看出,无论使用多少受试者,用户测试的收益都远远大于成本。当使用3到5个受试者时,收益成本比达到最大,这证实了我之前的经验。

图2
使用Nielsen和Landauer[1993]所描述的模型和平均参数,改变测试用户数量的“典型”项目的成本效益权衡曲线。这条曲线显示了收益与成本的比率,即收益大于成本的多少倍。例如,效益成本比为50可能对应的成本为1万美元,效益为50万美元。
成本效益曲线

除了减少受试者的数量外,简化和传统有声思维的另一个主要区别是,数据分析可以根据实验者的笔记而不是录像带进行。录制、观看和分析录像带的成本很高,而且需要花费大量时间,最好花在运行更多主题和测试重新设计的用户界面的更多迭代上。只有在需要绝对确定性的情况下(如研究),才应进行录像。在折扣可用性工程中,我们并不追求完美,我们只想找出大部分可用性问题,一项对11名软件工程师的调查[Perlman 1988]发现,他们对原型的简单测试的评价几乎是视频协议的两倍。

2.3启发式评估

当前的用户界面标准和可用性指南集合通常有一千条规则需要遵循,因此被开发人员视为令人生畏的。对于折扣方法,我主张将复杂性降低两个数量级,而不是依赖于一组小的启发式方法,如10个基本可用性原则(列在另一页上)。

这些原则可以在一次讲座中介绍,并且可以用来解释用户界面设计中观察到的大部分问题。不幸的是,它确实需要一些经验来充分地应用这些原则[Nielsen 1992c],因此可能需要花一些钱让外部可用性顾问来帮助进行启发式评估。另一方面,即使是非专家也可以通过启发式评估发现许多可用性问题,剩下的许多问题将通过简化的有声思维测试揭示出来。也可以建议让几个不同的人执行启发式评估不同的人发现了不同的可用性问题[Nielsen和Molich 1990]。这是另一个原因,即使折扣可用性工程师也可以考虑将部分预算留给外部可用性顾问。

3验证折扣可用性工程

在一个案例中,我使用折扣可用性工程方法重新设计了一组帐户报表[Nielsen 1989b]。在我满意之前,我测试了8个不同的版本(原始设计加上7个重新设计)。即便如此,整个项目只需要大约90个小时,包括设计12种不同陈述的7个版本(然而,并非所有形式都在每次迭代中更改),并在简化的思维大声实验中测试它们。大多数版本的测试只有一个用户。为了验证设计的有效性,采用传统的统计测量方法进行了进一步的实验。需要强调的是,这种验证是一种研究活动,而不是折扣可用性工程方法本身的一部分:可用性工程的工作随着改进的报表的开发而结束,但为了检查使用的可用性工程方法,决定对其中一个新设计与原设计进行可用性测量。

3.1实验一:采用可用性测量的双盲测试

验证是使用双盲试验完成的:38个实验者,每个实验者在科学间设计中持续四个受试者(总共152个受试者)。实验者和主题都不知道这是原始账户对陈述,这是新的。表3中报告的结果显示了关于新陈述的测量值的明确且高度统计学显着改进,了解陈述中信息的信息的可理解性,按照有关内容的四个问题的平均正确答案的平均答案的平均数量衡量。陈述。该值确实是在迭代设计期间被监视为目标的可用性参数。在最终测试中还测量了在迭代设计过程中未被视为目标(使用效率和主观满意度)的其他可用性参数,并且该发表的两个版本实际上是相同的分数。

表3
实验1的结果:采用双盲测试(N=152)比较银行对账单的原始版本和修订版本。测量的值是:有多少受试者可以正确回答四个问题每个人关于声明的内容(这四个问题和合并后的平均),科目审查所需的平均时间的陈述和回答问题,和受试者的平均主观评级(规模:1[不好]5[好])。
最右边的一列表明,根据aT-测试。
原始设计 修改后的设计 差异显著性
“存款规模” 79% 95% P< . 01
“委员会” 34% 53% P< . 05
“利率” 20% 58% P< . 01
“信用额度” 93% 99% P< . 05
平均正确 56% 76% P< . 01
任务时间(秒) 315. 303. n、 美国(P= 58)
主观满意度[1-5分] 2.8 3.0 n、 美国(P= .14点)

这项研究支持使用折扣可用性工程技术,并表明它们确实可以在可用性方面引起可测量的改进。然而,这些结果也表明,在设置可用性工程工作的目标时应该谨慎。当可用性工程师的注意力集中在官方目标上时,那些没有为改进设定目标的可用性参数可能会被抛在后面。在这项研究中,没有观察到测量的可用性参数实际退化的负面影响,但人们不能总是指望如此幸运。

3.2实验2:没有可用性专业知识的人的建议

向两组评估者展示了两种版本的财务报表(没有被告知哪一种是修订版本),并询问他们会建议管理人员使用哪一种。所有的评估者都是计算机科学专业的学生,他们报名参加了用户界面设计课程,但还没有在这门课上学到任何东西。这意味着他们不知道可用性启发式否则他们可能会用它来评估两个版本。

A组由来自谁曾与帐户对帐单的每个版本上运行两个短实验实验1(以上报道)实验者,而在B组的评估不得不做出两个版本的自己的个人评价的基础上,他们的建议.结果列在表4中,并显示在建议一个显著差异:A组评估者优选的修订版4比1,而在B组评估人员分裂同样在两个版本之间。这后一结果是可能的事实,即两个版本几乎同样主观满足根据表3中报告的测量结果的反映。

表4
实验二的结果:要求两组评估者推荐两种版本的会计报表。在A组中,每个人首先与4个受试者进行实证测试,而B组的评估者除了自己的主观评价之外没有任何推荐依据。
两组之间的差异在统计上是不同的P<.05级。
A组 B组
N=38 N = 21
建议原创 16% 48%
建议修改后 68% 48%
不推荐 16% 5%

如果我们接受表3中的统计测量结果,将修订版本定义为“最好的”,我们看到A组在提出正确建议方面明显优于B组。这是尽管每个个人的组实验结果的知识只有两个主题为每个设计(总体统计数据后才计算建议了,所以每一个评估者只知道四个科目由个人的结果)。

因此,我们可以得出结论,即使运行一个小的,便宜的实证研究可以帮助非人为因素的人显著在他们的用户界面评价。如果再算上谁没有做出推荐为具有50/50的机会挑选合适接口的评估,该实验表明,运行只有两个科目在一个小的测试每个版本改进了概率,建议从最好的两个版本50%至76%。

4成本效益启发式评估分析:一个案例研究

启发式评估的成本效益分析包括两个主要元件:第一估计成本花费执行评估,以及第二推定增加可用性(少的重新设计的开发成本)方面的益处的时间方面。由于这些估计涉及一定的不确定性,他们将使用数字舍被转换成美元金额。任何给定的公司当然会略有不同的转换系数,根据其确切的财务状况。

以下案例研究涉及一个供内部电话公司使用的系统的原型用户界面,本章称之为集成系统。集成系统相当复杂,了解其细节需要对电话公司的概念、程序和数据库有广泛的了解。由于不需要详细解释来理解研究中普遍适用的经验教训,因此这里仅概述整合系统。

简单地说,集成系统提供了一个图形用户界面,以统一的方式访问运行在不同远程计算机上的几个系统的信息,尽管后端系统之间存在差异。集成系统可用于解决某些问题,当数据不一致需要技术人员的人工干预,因为计算机系统无法确定哪些信息是正确的。解决这些问题的传统方法包括让技术人员通过许多传统的字母数字终端会话访问多个数据库来比较信息。数据库驻留在不同的计算机上,具有不同的数据格式和用户界面设计,因此这种传统方法有些笨拙,需要技术人员学习大量不一致的用户界面。

执行此任务需要大量高度特定于领域的知识,这些知识涉及电话系统的构造方式和不同数据库的结构。技术人员需要知道在哪里查找哪些数据以及不同类型的数据是如何关联的。此外,对于没有详细领域知识的人来说,单个数据项本身是非常模糊的。

通过11名评估人员对该界面进行启发式评估(详细描述见[Nielsen 1994b]),发现了44个可用性问题。这些问题中有40个被称为“核心”可用性问题,并且在界面中经过深入评估的部分被发现,而剩下的4个问题是在界面中我们没有计划作为启发式评估的一部分进行研究的部分被发现的。

4.1时间支出

通常在可用性工程中,成本估算是最容易正确的。表5按人-小时计算了启发式评估项目的总时间。没有试图区分不同类别的专业工作人员。实际上,表5中列出的所有工时都是由可用性专家花费的。唯一的例外是,开发专家花了一小部分时间为评估准备原型,并参加汇报会议。

表5
估计本文中描述的启发式评估研究所花费的总工时数。“原型准备时间”的估算不包括初始任务分析、用户界面设计或原型实施所需的时间,因为这些活动已经独立于启发式评估进行。
评估使用启发式评估的合适方法,4人@ 2小时 8
让外部评估专家了解领域和场景 8
寻找和安排评估者,1.8小时+ 0.2小时每个评估者 4
准备简报 3.
为评估人员准备场景 2
简报,1位系统专家,1位评估专家,11位评估人员@ 1.5小时 19.5
为评估准备原型(软件及其硬件平台) 5
实际评估,1小时11名评估员 11
观察评估会议,2名观察员@11小时 22
汇报,3名评估员,3名开发人员,1名评估专家,时间为1小时 7
基于评估会话的笔记写作可用性问题列表 2
编写问题描述用于严重程度评估问卷 6
严重等级,每0.5小时11名评估人员 5.5
分析严重性等级 2
全部的 105

注意,为准备场景所指定的时间只涵盖了以评估人员在评估期间可用的形式编写场景的工作。首先需要相当多的额外工作来指定场景,但是这种工作是在评估之前执行的一般任务分析和设计活动的一部分。基于场景的设计是一种众所周知的用户界面设计方法[Carroll and Rosson 1990, Clarke 1991],因此人们通常能够利用在可用性生命周期的前几个阶段开发的交互场景。即便如此,我们可能很幸运,为目前系统开发的情景可以用如此少量的额外努力用于评估。

评价被录像,大约八个小时都花在一般性的任务,比如录像,学习操作特定的视频设备可用性实验室用于评估会议,建立和关闭视频设备在每两天的研究,复卷磁带等。这段录像并不是启发式评估的一部分,也不是为了达到可用性问题列表的目的而对录像进行审查。观察员的说明足以达到这一目的。录像带是在某种程度上用于本研究的分析研究额外花了八个小时回顾一些评估会议的细节,但是因为这没有实际应用的一部分,使用启发式评估方法,录像带上的时间没有被包含在表5。

由表5可知,评估花费的总人-小时数可由公式确定

方程1:
时间() = 47.8 + 5.2

在哪里是评估员的数量。该公式不适用于大值,因为用于房间安排和严重性等级分析的一些工作部分取决于评估人员的数量,并且会随着时间的推移而变化年代。

(等式1)的成本估计可能大于未来启发式评估所需的必需品。通过将两个观察者的团队减少到单个观察者,可以实现固定和可变成本的主要减少。该观察者应该是熟悉该申请的人,以便观察者可以在评估期间从评估者回答问题。此外,即使观察者应该具有一定程度的可用性知识,以便理解评估人员所做的评论,观察者不需要成为专门从事可用性的高技能专家。启发式评估和传统用户测试之间的一个主要区别是启发式评估会话的观察者主要是不必解释用户动作,因为评估人员假设明确地识别可用性问题的任务。相比之下,传统用户测试中的实验者需要更高级别的可用性专业知识,以便将主题的行为和困难转化为与界面相关的可用性问题。

这一改变将导致下列经过修订的公式

方程2:
时间() = 37.3 + 4.2

将(式1)或(式2)中的时间估算转化为金钱估算,只需将小时数乘以专业人员每小时的负载成本估算即可。请注意,专业人员的工资和福利成本是不够的,因为额外的成本是用于测试的计算机设备和实验室空间。为了使用整数,专业人员每小时估计的负载成本为100美元,换算成实际花费的105小时启发式评估的总成本为10,500美元。

4.2效益评估

获得启发式评估好处的精确度量的唯一方法是完全实现两个版本的用户界面;一个没有任何变化,另一个有评估结果所暗示的变化。然后,这两个版本应该被大量的真实用户使用,在足够长的时间内执行真实任务,从而在两种情况下都达到专家性能的稳定水平[Gray et al. 1992]。这个过程将为学习时间和专家表现的差异提供精确的测量。不幸的是,被评估的接口版本仅以原型形式存在,无法进行任何实际工作,在大量可用性问题被记录下来的情况下,期望投入大量开发资源将原型转化为具有相同用户界面的最终产品是不现实的。

或者,可以为用户工作日中涉及的不同步骤建立详细的经济工作研究模型,以评估每个子任务的频率和持续时间。然后,可以进一步使用用户交互时间的正式模型来估计使用一组备选用户界面执行每个步骤的持续时间e设计[Gray等人,1992]。这种方法将提供相当详细的估计,但由于模型中的操作持续时间未知,因此不一定准确。执行该方法也非常耗时。

因此,有必要依赖于对收益的估计,而不是硬测量数据。为了获得此类估计,要求11名评估人员通过修复启发式评估确定的所有44个可用性问题来估计可用性的改进。可用性改进是根据两个可用性参数进行估计的:

  • 减少学习时间:用户学习使用系统所需的时间会减少多少?作为可用性参数的学习时间代表了每个新用户学习系统的一次性生产时间损失,因此任何节省只能实现一次。
  • 加速在专家的表现:一旦用户已经达到了专家表现稳定状态,能快多少会使用系统时,所有的固定在使用系统时,所有的问题仍然比可用性问题,他们能够履行自己的工作?专家认为性能的可用性参数表示使用了改进的界面的持续优势,所以任何积蓄将整个系统的使用寿命来实现。

其他令人感兴趣的可用性参数包括用户错误的频率和用户的主观满意度,但这些参数没有被估计。由于我们发现的一些可用性问题与容易出错的环境有关,用户错误的数量可能会下降。

11名评估者中有10人提供了学习时间估计,所有11人都提供了专家加速估计。图3显示了这些估计的分布直方图。Nielsen和Phillips[1993]发现,可用性专家对用户性能变化的估计是高度可变的,如图所示,但至少三个独立估计的平均值与受控实验测量的值相当接近。

图3
直方图显示了在解决启发式评估中发现的所有可用性问题的界面中,评估者估计的学习时间节省(上)和专家性能加速(下)的分布情况。一个评估者没有提供学习时间估计。
估计学习时间和专家性能改进的直方图

鉴于效益估计纯粹基于专家的主观判断而非经验证据,在将评价人员的估计转化为预计的资金节省时,似乎应谨慎保守。当考虑所有评估者时,学习时间减少的平均值为0.8天,专家加速的平均值为18%,当排除可能过于乐观的2天和40%时,平均值分别为0.5天和16%。为了保守起见,我们将选择0.5天作为我们的学习时间减少估计,10%作为我们的专家加速估计。

10%的专家加速显然只适用于花在使用界面上的时间。对用户的研究表明,他们会花大约1/3的时间做其他任务,1/3的时间在不操作用户界面的情况下执行任务,1/3的时间在实际操作界面。因此,10%的专家加速相当于总工作时间的3.3%。

在以下假设下,可以将这些估计转化为总节省:我们假设将有2000人使用该系统。考虑到目前大约有3000人从事这项工作,这一数字有些保守。让2000人每个人在学习使用系统时节省0.5天,相当于一次性节省了1000个用户天。此外,在达到专家性能后,如果2,000个用户的工作速度提高3.3%,则系统在使用期间每年可节省67个用户年。同样,为了保守起见,我们只考虑第一年的节省,即使我们在这里谈论的计算机系统的规模通常是使用一年以上。67个用户年大约相当于13000个用户日。因此,第一年节省的用户天总数约为14,000天。

为了从金钱的角度来衡量节省的总成本,我们假设一个用户日的成本是100美元,为了保守起见,我们假设只有一半的可用性问题可以得到解决,因此只有一半的潜在节省实际上实现了。此外,我们需要考虑到这样一个事实,即在用户时间上的节省直到系统被引入时才实现,因此其净现值小于其绝对值。同样,为了使用整数,我们将节省的学习时间的价值折算20%,而第一年专家加速的价值折算30%。学习时间可以以较小的百分比折扣,因为这种节省是在系统引入后的第一天实现的。使用这些保守的假设,我们发现一年可以节省54万美元。

当然,储蓄并不意识到只要希望一半的可用性问题是固定的,所以我们必须减少储蓄估计和估计成本的额外的软件工程工作需要重新设计现有的接口而不是实现接口原型。假设这个额外工作所需的软件工程时间是400小时,并且再次假设专业人员的负载成本是每小时100美元,我们发现节省的估计需要减少40000美元。这笔费用是在此时此地发生的,因此不能贴现。因此,我们对改进用户界面的净现值的最后估计为50万美元。

仍然是保守的,我们没有考虑到不必在系统发布后修改它所节省的软件工程成本的价值。假设原始用户界面充分实施和释放,这是很有可能的第二版本中,用户需要实质性的变革,众所周知,软件工程更改发布系统是昂贵得多比更改在软件生命周期的一个原型阶段。

改进接口的50万美元收益应该与启发式评估项目的成本(估计为10500美元)进行比较。因此,我们看到收益/成本比是48。这个数字涉及到重大的不确定性,但它足够大,我们可以毫不犹豫地得出结论,启发式评估得到了回报。

作为对成本效益分析的最后评论,我们应该注意到“效益”并不会转化为实际的现金流。相反地,如果原型界面在没有进一步修改的情况下被执行并发布,那么用户将不得不花费额外的时间。找到恰当地表示软件开发资金节省的方法是一个有趣且重要的管理问题。

4.3用户测试的成本效益分析

在启发式评估练习之后,在同一个界面上执行额外的用户测试,运行四个测试用户。主要原因使用很多启发式评估者比测试用户,用户的特定应用程序是高度专业化的技术人员是很难进入实验室,而这是相当容易获得大量的可用性专家参与启发式评估过程。通过用户测试发现了四个新的可用性问题,同时也确认了通过启发式评估已经发现的17个问题。

我们可以讨论在用户测试中没有观察到的23个核心问题是否实际上是“问题”,因为它们不会被看到打扰到真正的用户。正如其他地方所争论的[Nielsen 1992b],这些问题确实是非常真实的,但是它们的影响可能持续时间太短,在标准用户测试中无法观察到。除非对大量用户的数据进行统计分析,否则无法观察到减慢用户速度0.1秒左右的问题,但它们可能是非常真实且代价高昂的问题。另外,有些问题可能发生得太不频繁,在这里测试的用户数量很少的情况下无法观察到。

用户测试活动的主要成本是让两名专业人员每人花费7个小时来运行测试,并对测试用户进行简报和汇报。定义测试任务的传统耗时活动不需要时间,因为使用了与之前可用性工作开发的相同的场景。此外,花了半小时寻找和安排用户进行测试,花了两个小时实现一个小的培训界面,用户可以在该界面上学习使用鼠标和标准的图形交互技术,如下拉窗口。这些活动总共需要专业工作人员16.5人小时,费用为$1 650。

此外,如果将旅行时间计算在内,这4名用户和他们的经理基本上花了一整天的时间进行测试。再次假设一个用户日的成本是100美元,进一步假设一个管理人员日的成本是200美元,那么用户参与的总成本是600美元。加上专业人员和用户的成本,用户测试的总成本估计为2,250美元。

花在用户测试上的2250美元可能会花在额外的启发式评估上。根据公式1,这个和对应于使用4.3个额外的评估器。Nielsen和Landauer[1993]指出,可用性问题的发现是通过评估者可以用预测公式建模

方程3:
问题发现() = n (1- (1-L

对于本研究中的核心可用性问题,该方程中参数的最佳拟合值为N=40和L= 0.26。增加启发式评估器的数量,从11至15.3因此,可以预期会导致约1.1附加的可用性问题的发现。这一估计表明,现有的额外资源的确似乎已经在运行的用户测试更好的度过,发现四个方面的问题,不是有可能进一步扩大启发式评估。

我们没有系统的方法来评估通过用户测试发现的另外四个问题的好处。然而,得出粗略估计的一个简单方法是假设四个新问题的平均严重性与启发式评估已经发现的17个问题的平均严重性相同。作为启发式评估研究的一部分,在等级表上测量严重性,每个可用性问题的严重性得分从零到四,得分越高表示问题越严重。最初44个可用性问题的严重性总分为98.41,在用户测试和启发式评估中看到的17个问题的严重性总分为41.56。因此,与原始问题相比,我们可以估计额外四个问题的相对严重性为4/17 xá41.56/98.41=0.099。

了解用户测试发现的额外问题将为改进界面增加9.9%的潜力。此外,我们可以假设可以修复的新问题的比例、修复它们的影响以及修复它们的成本都与启发式评估发现的问题的估计相同。在这些假设下,发现额外4个可用性问题的价值是50万美元x 0.099 = 49500美元。

使用这些估计,启发式评估之后添加用户测试的收益/成本比率是22。当然,如果我们认为用户测试能够找到在用户测试期间观察到的问题,但已经通过启发式评估发现了问题,那么用户测试的好处就会更大。但是,我们应该注意到,如果没有执行启发式评估并确认了使用场景的价值,那么计划用户测试的成本会更高。此外,如果没有预先的启发式评估,也不能保证所有观察到的问题都能被发现。现在,我们知道要寻找什么,但如果用户测试是我们对这个界面的第一个可用性评估活动,我们可能不会注意到这么多问题。

如果考虑到17个问题的严重程度高于平均水平,将所有17个重复问题以及4个新问题计入用户测试,则用户测试的收益将估值为260500美元。当然,只有在事先没有进行启发式评估的情况下,这一数量才会从用户测试中受益。因此,对用户测试的假设分析收取一些实际用于准备启发式评估的成本似乎是合理的。具体而言,参考表5,我们将增加评估使用该方法的适当方式、让外部评估专家了解领域和场景、准备场景和准备软件的成本,以及编写问题描述所花费的一半时间(因为发现的问题约为一半)。这些活动总计为24小时,或2400美元的额外成本,用于运行用户测试的总估计成本,而无需事先进行启发式评估4650美元。这意味着效益/成本比为56。

为了提供一个公平的比较,应该指出的是,收益/成本率只有四个评估进行启发式评估的将是53这个数字是自多个先前unfound可用性问题比收益/成本比例较大的全面评估由第一评估被识别比由最后,如图(EQ 3)。此外,启发式评估提供了可以被用来在进一步发展过程中的可用性问题定影优先严重性估计,并且该数据的可用性如通过递送测量的可用性可能增加了该方法的实际值。如果花在述职和严重性评级的时间是从花在启发式评估的时间中扣除,效益/成本比满十个评估成为59和四个评价者的比例变为71。

因此,在这些估计的不确定性范围内,用户测试和启发式评估似乎具有可比的成本效益比,并且每种方法中的某些操作可能具有附加价值。

组织中可用性工程的发展

在可用性方面,“任何数据都是数据”和“有总比没有好”是打折扣的可用性工程的两个基本口号。因此,我经常提倡一种可用性方法,即从一开始就注重使用最小的可用性方法。即便如此,仍有许多项目将受益于使用比最小折扣可用性方法更多的方法。我在这一章的标题中使用了术语“guerrilla HCI”,因为我相信简化的可用性方法可以帮助公司逐步建立对系统可用性方法的依赖,从最基本的开始逐步发展到更精细的生命周期方法。

基于多年来的多年来的多个公司和项目的基于,我已经到达了在软件开发中使用能力工程的使用增加了一系列步骤。

  1. 可用性无关紧要。主要的重点是从熨斗上榨取每一点表现。这就是导致世界著名错误消息“嘟嘟”的态度
  2. 可用性很重要,但好的接口肯定可以由常规的开发人员设计作为他们总体系统设计的一部分。丹麦国王腓特烈六世(King Frederik VI)在1835年2月26日发表的著名声明就体现了这种态度:“只有我们知道什么才是国家和人民真正的福利。”在这个阶段,没有尝试在用户测试或获取具有可用性专业知识的人员。
  3. 渴望拥有的接口由魔杖祝福可用性工程师。开发人员意识到他们可能不了解可用性的所有知识,所以他们请了可用性专家来检查他们的设计并对其进行评论。可用性专家的参与往往太晚,无法在项目中发挥更大的作用,而且可用性专家经常不得不在没有接触到真实用户的好处的情况下提供界面方面的建议。
  4. GUI恐慌罢工,导致突然想要了解用户界面问题。目前,许多公司正处于这个阶段,他们正在从基于字符的用户界面转向图形用户界面,并意识到需要从一开始就引入可用性专家来为图形用户界面提供建议。一些可用性专家对这种态度表示不满,认为为任务提供一个合适的界面比盲目使用图形界面更重要。即便如此,对于可用性专家来说,GUI恐慌是一个机会,可以在界面设计的早期阶段就参与进来,而不是传统的在最后一刻才完成的、无法改变的设计。(更新添加到1999:这些天,这个阶段的特征通常是网恐慌罢工.这是同样的现象,应该以同样的方式对待。)
  5. 折扣可用性工程偶尔使用。通常,某些项目使用一些折扣可用性方法(如用户测试或启发式评估),尽管这些方法通常在开发生命周期中使用太晚了,以做出最大的好处。使用可用性方法的项目通常不同于其他人在早期项目中经历了可用性方法的利益的管理人员。因此,可用性充当一种病毒,随着更多人体验其益处,逐步感染更多的项目。
  6. 折扣可用性工程系统地使用。在某些时候,大多数项目都涉及到一些简单的可用性方法,有些项目甚至在系统开发的早期阶段就使用了可用性方法。在这个阶段,场景和廉价的原型技术似乎是游击队人机交互非常有效的武器。
  7. 可用性小组和/或可用性实验室成立。许多公司在体验了折扣可用性工程的好处后,决定扩展到高级可用性方法。目前,建筑可用性实验室[Nielsen 1994a]非常受欢迎,成立专门的可用性专家小组也是如此。
  8. 可用性渗透生命周期。最后一个阶段很少达到,因为即使是拥有可用性小组和可用性实验室的公司,通常也没有足够的可用性资源来在开发生命周期的所有阶段采用人们希望的所有方法。然而,有些项目(通常很重要)的可用性计划被定义为其早期项目规划的一部分,并且在整个开发生命周期中使用可用性方法。

这个模型与Ehrlich和Rohn[1994]提出的一系列组织接受阶段非常相似,但它是独立开发的。表中第1-2阶段对应Ehrlich和Rohn的怀疑阶段,第3-4阶段对应好奇阶段,第5-6阶段对应接受阶段,第7-8阶段对应伙伴关系阶段。

许多可用性工程的老师描述了这种近乎宗教的效果,这似乎是学生第一次尝试运行用户测试,亲眼看到了正常人使用所谓“简单”软件可能遇到的困难。不幸的是,组织更难转换,因此它们大多必须通过使用游击队方法(如折扣可用性工程)从内部征服,这逐渐向越来越多的人表明可用性方法有效并改进产品。假设一个开发组织可以在一次彻底的变革中从上述模型中的第1或第2阶段转移到第7或第8阶段,这是过于乐观的。事实上,几乎所有可用性方法的使用成本都非常低,相比于它们以更好、更易于使用的产品的形式提供的好处,但我们通常必须从尽可能低的成本方法开始逐步克服这些障碍。

致谢

作者要感谢Raldolph Bias, Tom Landauer和Janice Rohn对手稿早期版本的有益评论。

工具书类

  • Apple Computer(1987)。人类界面指南:Apple桌面界面。Addison Wesley,读书,MA。
  • 苹果电脑(1992年)。麦金塔人机界面指南。艾迪生·韦斯利,雷丁,马萨诸塞州。
  • 贝洛蒂,V.(1988)。目前的设计实践对HCI技术的使用的影响。在琼斯,D.M和Wrrer-R(EDS),人和计算机IV,剑桥大学出版社,剑桥,英国,13-34。
  • Boehm,B. W.(1981)。软件工程经济学。Prentice-Hall,Englewood Cliffs,NJ。
  • 卡德,S. K.,莫兰,T. P.和纽威尔,A.(1983)。《人机交互心理学》,Lawrence Erlbaum Associates,希尔斯代尔,新泽西州
  • 卡罗尔,J. M.,罗松,M. B.(1990)。人机交互场景作为一种设计表现形式。计算机科学与技术,vol . 23, no . 1, no . 1, no . 1
  • 克拉克,L.(1991)。通过用户界面设计人员的使用情景。尿布,D.,和哈蒙德,N.(编),人与计算机的VI,剑桥大学出版社,剑桥,英国103-115。
  • 李志强,李志强(1994)。可用性工程的成本论证:供应商的观点。在Bias, r.g.,和Mayhew, D.J.(编),成本合理性可用性。学术出版社,波士顿,马萨诸塞州
  • 古尔德,J. D.和刘易斯,C. H.(1985)。可用性设计:关键原则和设计师的想法。通信的ACM 28, 3(3月),300-311。
  • 灰色,W. D.,John,B. E.和Atwood,M. E.(1992)。项目宽限性的比例,或者概述了GOMS的验证。Proc。ACM Chi'92(1992年5月3日至7日蒙特雷,1992年5月3日),307-312。
  • Jørgensen A.H.(1989)。在系统开发中使用有声思维方法。在Salvendy, G.和Smith, M.J.(编),设计和使用人机界面和基于知识的系统。科学出版社,阿姆斯特丹743-750。
  • Karwowski, W., Kosiba, E., Benabdallah, S., and Salvendy, G.(1989)。人机交互中的模糊数据和通信:是好是坏。在Salvendy, G.和Smith, M.J.(编),设计和使用人机界面和基于知识的系统。爱思唯尔科学出版社,阿姆斯特丹,402-409。
  • 兰道尔,T.K.(1988)。人机交互的研究方法。Helander,M.(编辑),《人机交互手册》。北荷兰,阿姆斯特丹,荷兰。543-568.
  • Mantei,M.M.和Teorey,T.J.(1988),《将人为因素纳入软件生命周期的成本/效益分析》,ACM通信31,4(4月),428-439。
  • 米斯特,U.,瓦尼尔德,A.和Jørgensen, A.(1989)。Hvordan sikres kvaliteten af brugergr¾nsefladen i systemudviklingen(“在系统开发中保证用户界面的质量”,丹麦语),Proceedings NordDATA'89 Joint Scandinavian Computer Conference (Copenhagen, Denmark, 19-22 June), 479-484。
  • Molich, R.,和Nielsen, J.(1990)。改进人机对话,ACM通信33,3(3月),338-348。
  • Monk, A., Wright, P., Haber, J., and Davenport, L.(1993)。改进人机界面:实用技术。Prentice Hall International, Hemel Hempstead,英国
  • Nielsen,J.(1989a)。使用面向对象的超文本编程系统对用户界面进行原型设计,Proc.NordDATA'89斯堪的纳维亚计算机联合会议(丹麦哥本哈根,6月19-22日),485-490。
  • j·尼尔森(1989 b)。打折扣的可用性工程。在Salvendy, G.和Smith, M.J.(编),设计和使用人机界面和基于知识的系统,Elsevier科学出版社,阿姆斯特丹。394-401。
  • 尼尔森,J.(1990年a)。“折扣”可用性工程的巨大回报,IEEE软件7,3(5月),107-108。
  • j·尼尔森(1990 b)。纸面与计算机实现作为启发式评估的模拟场景,Proc. INTERACT'90 3rd IFIP Conf. Human-Computer Interaction (Cambridge, uk, 27-31 August), 315-320。
  • j·尼尔森(1992)。可用性工程生命周期。IEEE计算机学报25,3(3),12-22。
  • j·尼尔森(1992 b)。评估计算机科学家使用的大声思考技术。哈特森,H. R.和Hix, D.(编),《人机交互进展》第3卷,Ablex,诺伍德,新泽西州。75 - 88。
  • j·尼尔森(1992 c)。通过启发式评估发现可用性问题。美国ACM CHI 92(蒙特雷,CA, 3-7 5月),373-380。
  • Nielsen,J.(1993)。可用性工程. 学术出版社,马萨诸塞州波士顿。
  • Nielsen,J.(1994a)。可用性实验室.行为与信息技术13,1。
  • Nielsen,J.(1994b)。启发式评估。在Nielsen,J.和Mack,R.L.(编辑部)中,可用性检查方法.John Wiley & Sons,纽约,纽约
  • Nielsen,J.和Landauer,T.K.(1993),《发现可用性问题的数学模型》,程序ACM INTERCHI'93 Conf.(荷兰阿姆斯特丹,4月24-29日),206-213。
  • Nielsen,J.和Levy,J.(1994)。测量可用性-偏好与性能。ACM的通信37,4(四月),66-75。
  • Nielsen,J.和Molich,R.(1989)。基于可用性工程的用户界面设计教学,ACM SIGCHI Bulletin 21,1(7月),45-48
  • Nielsen,J.和Molich,R.(1990年)。用户界面的启发式评估,Proc。ACM CHI'90(华盛顿州西雅图,4月1日至5日),249-256。
  • 尼尔森,J.和菲利普斯,V. L.(1993)。评估两个界面的相对可用性:比较启发式、形式化和经验方法。美国ACM国际会议93会议(阿姆斯特丹,荷兰,4月24-29日),214-221。
  • Nielsen, J., Frehr, I.和Nymand, H.(1991)。HyperCard作为一个面向对象编程系统的易学性,行为与信息技术10,2(3 - 4月),111-120。
  • 珀尔曼g(1988)。教授软件工程师如何开发用户界面,中国计算机学会第32届年会,391-394。
  • Perlman,G.(1990)。教学用户界面开发,IEEE软件7,6(11月),85-86。
  • 告诉,m(1990)。更新旧的接口,Proc. ACM CHI'90(西雅图,WA, 1-5四月),243-247。
  • 托夫特鲁普和尼尔森,J.(1991)。评估用户界面标准的可用性,Proc. ACM CHI'91(新奥尔良,洛杉矶,4月28日- 5月2日),335-341。
  • Tognazini,B.(1990)。廉价的用户测试,Apple Direct 2,6(3月),21-27。在TOG on接口, Addison-Wesley, Reading, MA, 1992。
  • 伏尔泰(1764)。Dictionnaire Philosophique。
  • 怀特塞德,J.,贝内特,J.和霍尔茨布拉特(1988)。可用性工程:我们的经验和发展。在Helander, M.(编辑),人机交互手册,北荷兰,阿姆斯特丹791-817。