如何衡量获取硬数据的可用性?

时间:2009-03-06 14:35:19

标签: usability

有一些关于可用性的帖子,但没有一篇对我有用。

我需要对应用程序的某些部分的可用性进行定量测量。 我需要用硬数字来估计它以便能够将其与未来版本进行比较(例如用于报告目的)。最简单的方法是计算点击次数和击键次数,但这看起来太简单了(例如填写文本字段的成本是输入所有字母的简单总和? - 我想这更复杂)。 我需要一些数学模型,所以我可以估算数字。

有人对此有所了解吗?

P.S。我不需要有关设计用户界面的资源的链接。我已经有了它们。我需要的是一种用于测量硬编号中现有应用程序界面可用性的数学装置。

提前致谢。

6 个答案:

答案 0 :(得分:2)

http://www.techsmith.com/morae.asp

这是微软在花费数百万美元使用功能区工具栏重新设计Office 2007时所使用的部分内容。

以下是Office 2007的分析方法: http://cs.winona.edu/CSConference/2007proceedings/caty.pdf

请务必查看PDF末尾的参考资料,那里有很多好东西。看看微软如何处理Office 2007(不管你对它的看法如何),他们在这些东西上花了很多钱。

答案 1 :(得分:1)

您接触的主要想法是有效性和效率(在某些情况下,有效性)。要记住的基本要点概述为on this webpage

您真正想要做的是测量可用性的“检查”方法。这些设置通常成本较高(无论是在时间还是财务方面),但如果做得恰当,可以产生显着的效果。这些方法包括启发式评估,简单地比较系统界面和系统界面的使用,以及您的可用性启发式(但是,从您上面所说的,这可能不是您所追求的)

然而,更适合您的使用方法是“测试”方法,您可以观察用户在您的系统上执行任务。这部分与有效性和效率有关,但可以包括各种事物,例如“大声思考”概念(在某些情况下,这取决于所测试的软件,它非常有效)。

Jakob Nielsen有一个decent (short) article on his website。有another one,但它更多地与如何进行测试才能具有代表性,而不是如何进行测试本身。

答案 2 :(得分:0)

考虑测量执行关键任务的时间(使用新用户和有经验的用户)以及执行这些任务的数据输入错误数。

答案 3 :(得分:0)

首先,您要定义目标:例如,增加可以完成某组任务的用户百分比,并减少他们所需的时间。

然后,获得两个摄像头,一些用户(5-10)给他们一个完成的任务列表,并要求他们大声思考。一半的用户应使用“旧”系统,其余用户应使用新系统。

查看录像带,衡量录取时间,衡量成功率,无休止地讨论解释。

或者,您可以开发一个用于桶测试的系统 - 它以相同的方式工作,但它使得找到新的东西变得更加困难。另一方面,它便宜得多,所以你可以做更多的迭代。当然,这仅限于您可以公开测试的网站。

这显然意味着你试图获得两种设计之间的比较数据。我想不出一种将可用性表达为价值的方式。

答案 4 :(得分:0)

您可能希望查看GOMS model(目标,运算符,方法和选择规则)。在我看来,这是一个非常难以使用的研究工具,但它确实提供了一个“数学”基础来衡量严格控制环境中的性能。它最适合“专家”用户使用。对于新英格兰电话运营商来说,这是非常有趣的case study of Project Ernestine

答案 5 :(得分:0)

定量测量可用性是一个非常困难的问题。我把它作为我博士工作的一部分来解决。简短的回答是,你可以衡量它;不,你不能在真空中使用结果。您必须了解为什么需要更长或更短的时间;简单地比较数字比无用更糟糕,因为它具有误导性。

为了比较备用接口,它可以正常工作。在纵向研究中,用户将他们过去的第1版专业知识带入他们对第2版的使用,它不会有用。您还需要考虑学习界面的时间,包括在用户离开界面时重新理解界面的时间。最后,如果任务具有可变难度(这是现实世界中的常见情况)那么除非你有办法解决这个难题,否则你的数字将遍布地图。

GOMS(如上所述)是在设计阶段使用的一种很好的方法,可以直观地了解界面A在执行特定任务时是否优于B.但是,它仅解决专家用户的无差错性能,并且仅测量低级别任务执行时间。如果用户找到了一种更有效的方式来完成他们没有想到的工作,那么你就不会对GOMS进行估算,并且必须起草一份。

您可以查看一些具体措施:

  • 如果您想知道需要很长时间的事情,那么测量标准任务的时钟时间就会很好。然而,实验室测试通常涉及测试对象比日常工作更加努力和集中,因此将实验室的结果与真实用户进行比较会产生误导。
  • 错误率:用户犯错误或回溯的频率。特别是如果你发现一遍又一遍地发生同样的错误。
  • 解决方法的外观;如果您的用户正在处理某项功能,或者采取您认为愚蠢的一系列步骤,则可能表明您的界面没有提供工具来确定如何解决他们的问题。
  • 不要低估只是询问用户他们认为事情的进展情况。主观可用性很挑剔但可以揭示。