[译]低保真的可用性测试

标签: | 发表时间:2014-01-25 20:53 | 作者:happydeer
出处:http://blog.csdn.net/happydeer

牛人,给你来个突击测验: 你怎么知道你的应用程序能够正常工作?当然,也许你的程序通过了编译。也许它通过了所有的单元测试。也许它还成功通过了QA的严酷考验。也许它被成功部署到了一个正式的服务器,或者被打包成了一个安装程序。也许连Beta测试人员都签字认可了。

然而,所有这些都不能说明你的程序能够正常工作。

用户真的能理解你的应用程序吗?他们能够使用你的程序去完成他们的工作吗?这才是“能工作的应用程序”的定义。我在第一段罗列的所有东西都算不上什么。实际上, 如果你不找来真正的用户做可用性测试(Usability Testing)的话,你是无法知道你的程序能否正常工作的!

你会定期给你的应用程序做可用性测试吗?


你应该去做!这就是我的观点。Steve Krug有本书叫《Don’t Make Me Think》,其中有个中心思想就是:可用性测试对于任何软件项目来说都是必需的。Krug有个简单易行的方法来做可用性测试,他称之为“跳楼大减价”的可用性测试。

译者注:《Don’t Make Me Think》的中文译本是《点石成金:访客至上的网页设计秘笈》,由机械工业出版社于2006年出版。

可用性测试已经存在很长一段时间了。它的基本理念很简单:如果你想知道你的软件、网站或VCR的遥控器是否容易使用,那么在一些人尝试使用它的时候观察他们,记下他们在哪里碰到了问题,然后修正这些问题,之后再度测试。

不过,在最开始的时候,可用性测试的花费非常昂贵。你需要建立一个可用性实验室,它带有一间位于单向玻璃后面的观察室;至少要有两部摄像机,分别录制用户的反应和他们正在使用的东西。此外,你还得招募大量的测试用户,以得到具有统计意义的结果。这是科学研究。每次测试需要花费2~5万美元。因此这种活动不会经常发生。

但是在1989年,Jakob Nielsen写了一篇题为“Usability Engineering at a Discount”(打折的可用性工程)的论文。他指出,可用性测试不是非得那样做不可。你可以不需要可用性实验室,而且就算测试用户减少很多,也能得到同样的结果。这个想法是一个巨大的进步!惟一的问题是,10年以后的人们仍然觉得可用性测试不便宜,聘请一个人主持一次测试仍然得花上 5000〜15000美元。结果呢?虽说可用性测试比以前发生得多了,但还是不够频繁。

在这一章里,我要介绍的方法将会更加激进,这就是我们所说的“跳楼大减价”可用性测试。我将教你在你没有时间且预算不足的情况下,如何自己进行测试。当然,如果你有能力去请专家进行测试的话,那就去请吧。但如果这样破费会减少你的测试次数,那你还是别请了。

Krug指出,除非你对可用性测试有抵触情绪,否则它不难!即使只请一个人来做可用性测试,你多多少少总能得到一些有用的结果,比如下面的情况:

可用性测试总是会有效果的,哪怕对不合适的用户做一次最糟糕的测试,也会让你看到网站的一些需要改进的地方。我喜欢在每次研习班上做一次现场用户测试;通过这种方式,人们会认识到测试其实很容易做,而且经常能产生许多有价值的看法。我会在班上找一位志愿者,请他在某个其他同学的网站上执行一项任务。这样的测试不会超过10分钟,但被测试网站的主人通常会迅速记上好几页的笔记。他们还会询问是否可以对测试过程录像,以便他们带回去给开发团队看。(曾经有人告诉我,他的团队看过录像后对网站进行了一项改进,后来他们算了一下,这项改进帮他们节省了10万美元!)

如果你想看到更多的证据,来证明不需要很多用户也能进行有效的可用性测试,那就来看看Jakob Neilsen提供的这张图吧:


显而易见,完全不做可用性测试是一场灾难。但还有一点不是那么显而易见的是,只有少许几个人进行的可用性测试也能相当有效。而且,如果你遵循Krug给出的指导原则,你的低保真(Low-Fi)可用性测试会进行得更加顺利:

  • 我该在什么时候测试?理想情况下,一个月一次。在整个开发过程中,你应该持续不断地做小型的可用性测试。这些测试应该很简单,持续时间较短,以便于你随时都可以开展,而不用提前花时间去做计划。
  • 我需要找多少用户?3个,或者顶多4个。
  • 要找什么样的用户?随机抓一些人。只要会用电脑就行。一个不为人知的秘密是,可用性测试找谁测其实无关紧要。尽管找到具有代表性的用户会更好,但早点测、经常测要重要得多。别不好意思,不要放过你的朋友和邻居。
  • 测试要持续多长时间?每个用户花45分钟到1个小时。尽量保持简单。让测试的范围小一点。不管怎么说,哪怕做最简单的可用性测试,它还是会占用额外的时间。但从长远来说,它还是为你节省时间的。可用性测试的结果可以让你幸免于无休止的争论,或者避免在项目的收尾阶段大量返工。
  • 在哪里测试?任何办公室或者会议室。你所需要的只是一个房间、一张桌子、一台电脑和两把椅子,并且不受别人的干扰。
  • 测试人员应该具备什么特质?任何有点耐心的人都可以。这个人要有耐心,还要冷静、感性并且善于倾听。只要稍微训练一下,大部分人都能胜任做一个测试人员。
  • 我需要什么设备?你只需要一个屏幕录制软件(比如Camtasia)。如果想要录制的效果更好一点,你可以用一个便携式摄像机把人和屏幕都录下来。
  • 我要为测试做什么准备?想好你想要展示的东西。草拟一些步骤和说明,以引导参与者如何开始测试。
  • 测试需要花多少钱?如果不算主持人的时间,给每个用户50~100美元津贴。
  • 我们应该怎样解读测试的结果?在当天的午饭时间,向开发团队和任何感兴趣的干系人汇报。可用性测试最大的好处之一,就是测试结果在所有人面前都是一目了然的。任何严重的问题都难以被遗漏!

如果你还没买《Don’t Make Me Think》这本书,那你就太落伍了!赶紧去买吧!在等待送货期间,我强烈建议你下载该书的第9章先看看(下载地址为 http://sensible.com/Downloads/DMMTchapter09_for_personal_use_only.pdf)。我前面只是初略地介绍了一下,如果你想知道更多的细节,还是去看书吧。

可用性测试没必要做得很复杂。如果你真的想知道你正在做的东西是否对路,邀请一些人来使用它吧,并且你待在旁边仔细观察。没别的,也就是从会计部把Joe抓过来,从市场部把Sue抓过来;只要不是直接参与这个项目的,附近的人随便抓,然后请他们使用你做的东西。不要告诉他们做什么。给他们指定一个任务,然后提醒他们,在他们动手做的同时把心里的想法都说出来。而你只需要静静地坐在后面,仔细观察。根据我个人的经验,我可以告诉你,结果往往是令人惊讶的。

可用性测试的好处是毋庸置疑的。你尽管去做吧,这样才能真正体会到那些好处!

作者:happydeer 发表于2014-1-25 12:53:38 原文链接
阅读:161 评论:0 查看评论

相关 [低保 可用性 测试] 推荐:

[译]低保真的可用性测试

- - 呦呦鹿鸣
牛人,给你来个突击测验: 你怎么知道你的应用程序能够正常工作. 也许它还成功通过了QA的严酷考验. 也许它被成功部署到了一个正式的服务器,或者被打包成了一个安装程序. 也许连Beta测试人员都签字认可了. 然而,所有这些都不能说明你的程序能够正常工作. 用户真的能理解你的应用程序吗. 他们能够使用你的程序去完成他们的工作吗.

简单快速的可用性测试

- 画笔(PG) - 网易用户体验设计中心
可用性测试是改善产品的最佳方式之一,这一点,在内部已经是不争的共识. 只是由于用研人手总是不足,所以为了能让各个部门的同事能更快速地展开一些研究和测试的工作,我们陆续整理了一些简单的文档和教程,并计划通过集中的培训来普及一些用户体验的方法. 因此,要特别强调的是,本文所介绍的测试方法是简单,非正式的,小样本的,以发现严重问题为目的的.

可用性测试的权衡之道

- - 博客 - 伯乐在线
对于可用性测试,业内人士存在一些普遍认可的原则. 它们神圣地如同自然科学里的理论,似乎我们只能对其言听计从、俯首称臣才能践行出“好的可用性测试”. 其实,即便是科学,它的一个特征也是“可证伪性”——理论的正确性总是存在前提条件的. 可用性测试中的原则同样如此,需要根据目的、资源、环境的不同,灵活把握、权衡取舍,而非一味恪守某一个或某几个原则,也许这才是可用性从业人员经验重要性的体现.

可用性测试中的任务设计方法

- 嘉慧 - 网易用户体验设计中心博客
可用性是用来衡量产品质量的重要指标,从用户角度来判断产品的有效性、学习性、记忆性、使用效率、容错程度和令人满意的程度. 可用性测试是在迭代设计中不断获得用户反馈,根据用户反馈不断优化产品设计的一种方法. 其目的是是建立评价标准,尽可能多的发现可用性问题,并指导产品界面的设计和改进,尽可能地提高产品的可用性质量.

可用性测试的权衡之道(二)

- 翔 - 所有文章 - UCD大社区
继续讨论可用性测试中各种原则的灵活运用和注意事项. 五.发现问题:真的 VS 假的. 判断发现问题的真假,初看上去似乎不是个困难. 多数或全部参与者都遇到的问题毫无疑问是明显的可用性问题. 或许有人会建议,根据参与者中发现该问题的人数比例来判断:比例高是真问题,比例低是假问题. 前半句话可以接受,后半句话则有待商榷.

移动应用可用性测试的实践经验总结

- - 互联网的一些事-关注互联网产品管理,交流产品设计、用户体验心得
  如果你不大熟悉移动应用的可用性测试,没关系,这事儿没你想象的那么困难;不过移动应用与传统网站产品在可用性测试方面确实有一些关键的区别需要我们注意.   过去的几年当中,我(英文原文作者)为不少移动产品做过测试,从戒烟应用到移动版的车辆保险网站,其中既包括在实验室使用复杂设备进行的测试,也包括在各种实境化的条件下进行的非正式测试.

产品经理干货:可用性测试的那些事

- - 人人都是产品经理
可用性测试是指通过对典型用户实施测试来对产品或服务做出评价. 在一次典型的测试中,用户要完成一系列典型任务. 与此同时,观察者会在一旁观察、倾听、做笔记. 可用性测试的目的就是为了发现可用性问题,收集定性和定量的数据,并评估用户对产品的满意度. 可用性测试有助于设计和研发团队在产品成型之前发现问题.

50个小时的可用性测试带给我的启示

- - 博客园_新闻
上海这地方要积雪不是很容易,印象里只有 2008 年初的那次;更多时候即使漫天飞扬着雪花,最终还是好像下了场雨一样的到处是水. 所以每到冬天的这种时日,就会想到小时候在北方的样子. 高三那年入冬之后,喜欢在每个周六的晚上花一个小时左右的时间在外面骑车或是溜达,而且每逢这种时候只听枪花的 Use Your Illustion 1,最后在听到 Dead Horse 或是 Coma 的时候回到家;若是遇到雪天,则必定是 Metallica 的黑专辑.

可用性测试好助手——Morae软件的应用

- - Taobao UED Team
    在用户研究部门的日常项目中,可用性测试是常用的研究方法之一.     通过可用性测试,研究员可以梳理出产品存在的一些问题,有助于需求方对产品进行相应的改进. 而需求方则可以直接体会到用户的困境,从而找出解决方案. 因此,可用性测试不论对研究员发现问题还是需求方改进产品都是非常有价值的. 但是在测试过程中,一些“其他”因素却可能让我们的测试效果打了折扣.