作者：(美)Steve Krug
出版社：人民邮电出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
妙手回春：网站可用性测试及优化指南（修订版）试读：
中文版推荐序
众所周知，想要获得数字营销的巨大成功，除了要获取高质量的流量以外，还有一件很重要的事情，那就是建设可用性极强和用户体验极佳的网站。网站如果存在问题，即使流量再高，也不能达成目标，最终转化时也会黯然失色，因此我们需要打造卓越的网站。个人认为，优秀的网站是要针对不同的访客、流量、功能进行优化的，而不是一成不变的。针对网站优化的难题，大师Steve Krug给我们提供了业界领先的网站可用性测试与优化理念，让我们拥有了完整的方法论，来支撑网站长期和持续的优化，找到网站的最优化结果，而不是让网站优化失去活力，感觉没什么事情可做，落入窘境。
很多数字营销人员可能会问：“可用性测试太晦涩了，在实际工作中是否真的能够产生实质的作用?”其实，测试在互联网行业是一个非常成熟的专业领域，是软件、信息系统、网站中不可遗漏的一个重要环节。有了测试，我们的网站才能更好地迎合访客的需求，提升用户体验，提升转化率，让企业从容打赢数字营销之战。这本书特别适合非技术人士使用，包括营销总监、网站策划人员、产品经理和数据分析师等，强烈推荐！胡力Netconcepts高级数据咨询顾问《流量的秘密（第3版）》译者深圳网站分析博主
献辞
献给姨妈Isabel，她每天都为我祈祷。
献给我的兄弟Phil，他是法律服务公司的一名优秀的律师。
献给所有将一生都奉献于社会的人。开场白管我叫以实玛利吧
本书的由来，免责声明，以及一些边边角角
我酷爱最后期限，酷爱它飞过时发出的嗖嗖声。——道格拉斯·亚当斯，《银河系漫游指南》的作者，以不按时交稿著称。
9年前，就在完成《Don't Make Me Think》之后我就想写这本书了。
在写那本书的过程中，我无意中认识到了以下三点。
可用性测试是改善网站（以及用户将与之交互的任何产品）的最佳方式之一。
既然有很多公司和组织付不起专门请人进行定期测试的费用，那么每个人都应该学习自己进行可用性测试。
我可以编写一本很不错的书来阐述如何进行可用性测试。
不过，还有一个小问题：
我讨厌写作。
实际上，比我想象的还要讨厌，可能最准确的措词是对写作感到极度痛苦（agonizing）。
不是“买白色iPhone还是黑色iPhone”那样的痛苦，而是拨火棍插到眼睛里那样的极度痛苦。我始终认为写作是我所知的最艰巨工作，实在无法理解有人竟然在没有被枪指着头（这指的是最后期限即将到来）的情况下写作。
事实证明我没有立刻着手编写这本书可能是件好事，因为《Don't Make Me Think》带来的美好副作用之一是，让我有机会开展讲座，这比写作和咨询更符合我的性格。
在最初的五年期间，我的讲座由讲解和演示组成。我通过对与会者的网站进行简单的专家审阅来阐述对可用性问题的看法。我想向他们介绍如何自己进行测试，但无法在一天的讲座中加入这些内容。
经过深入思考以后，我终于在三年前找到了如何在一天的讲座中教人自己进行测试（包括动手实践）的办法。我改变了讲座方式，将一整天时间都用于介绍本书的主题：自己进行可用性测试。
经过几年实践以后，我对人们需要知道什么有了更深入的认识。要真正学会如何做某件事，就试试教别人怎么做吧，诚哉斯言！看到很多人学习如何自己做测试后，我也更加相信它的价值了。
最后，就在去年，我终于下决心签下了编写本书的合同（同时也戴上了最后期限的紧箍咒）。毕竟能够花钱参加一整天讲座的人有限，而阅读本书是不错的替代方案。
还需要另一本有关可用性测试的图书吗？
我没有发明任何东西。可用性测试历史悠久，很多人至少在20年前就开始倡导简化的可用性测试（discount usability testing）了，其中最有影响力的是Jokob Nielsen。
市面上已经有很多优秀的图书详细地阐述了如何进行可用性测试。在您有机会开始测试后，我强烈建议您至少阅读这些图书之一。
但本书和它们稍有不同，这主要体现在以下两个重要方面：
本书不全面介绍可用性测试 ：本书假设可用性不是您的谋生手段，甚至不包含在您的职位描述中，因此您不需要太深入了解它，也没有很多时间去学习它。与《Don't Make Me Think》一样，我尽可能确保本书足够简短，可以在乘飞机长途旅行中阅读完毕。
本书并不是要让您成为可用性测试专业人员或可用性测试专家，而只想让您做些测试。有些读者可能确实对可用性测试感兴趣，因此想进行全面学习，而第15章正是为这样的读者准备的。然而，就算只阅读这本书，也可以从测试中获得很多好处。
本书不仅仅介绍如何找出可用性问题 ：和其他有关测试的图书不同的是，本书还介绍了如何找出并修复可用性问题。第10~13章阐述了如何确定要修复的问题以及最佳的修复方式。在其他图书中，对这个主题介绍不多，而它确实很重要。
说我不负责任好了
有些专业测试人员认为，让业余人士自己进行测试是不负责任的。这些人很聪明，而我也很重视他们的看法。下面是他们的两个主要理由：
业余人员不称职，因此他们（1）将导致测试的产品更糟而不是更好 ；（2）让人们以为可用性测试没有价值。
业余人员做得不错，这将抢走专业人员的饭碗。
因此，在消除这些担心之前，有必要先声明一下。
如果雇得起可用性专业人员为您测试，这样做好了。
这没有问题：优秀的可用性专业人员比您更能胜任测试工作。除了在设计和主持测试方面拥有丰富的经验外，专业人员还在以前多次遇到过一些相同的可用性问题，对如何修复它们有更深入的认识。
其次，让局外人从不同的角度审视您的产品总会有所帮助。以一次测试的价格，您通常还可以免费获得专家评估，因为专业人员必须通过使用来确定如何测试产品。
更客观：作为局外人，专业人员更适合指出一些令人不高兴但很重要的真相，例如您开发的产品不管用或没有人需要。
但问题是，大多数网站雇不起专业人员——至少雇不起专业人员进行多轮测试。即使雇得起，也没有足够的专业人员可以雇。
更重要的是，我并不认为业余人员不称职，就我个人而言还没有见到过这样的情况。多年来，我一直在征集可用性测试导致产品更糟糕的例证，却没有得到任何回应。
这种情况并非不会发生，但极其少见。在大多数情况下，我怀疑这是有人出于个人目的假借公正的可用性测试之名操纵测试过程的结果。
另外，我对业余人员会抢走专业人员饭碗的说法也持怀疑态度。首先，这种工作并不是专业人员应该做的。
在2001年的UPA会上，Jakob Nielsen在他关于可用性未来的发言中完美地阐述了这一点。他指出每个人都应该进行简单的用户测试（对设计进行调试），而专业人员应该致力于对技能和经验要求更高的工作，如定量测试、比较测试和对新技术的测试。他指出，资深的专业人员应该致力于真正尖端的工作，如国际化测试和新方法开发（例如，深入思考以及与同道交流）。
根据我的经验，接触过测试的人几乎最终都会对它的价值深信不疑。因此我的观点是，如果有更多的人自己进行测试（以及更多人观看测试过程），专业人员将有更多的工作机会，而不是更少。
就我个人而言，如果要在可用性方面花钱，我将请专业人员做专家评估，然后自己进行测试；或者请一位愿意教我自己进行测试的专业人员进行第一轮测试。
本书不介绍的内容
本书不包含如下内容。
各种测试方法。可用性测试类型众多——定性、定量、总结性、形成性、正式、非正式、大样本、小样本、比较测试和基准测试等，它们的用途各不相同。
下一章的开头将讨论一些测试类型，但需要知道的是，本书只介绍一种测试，那就是简单、非正式、小样本的DIY可用性测试——有时称为简化的可用性测试。
对核反应堆仪表板、控制交通管制系统以及错误使用可能导致人员伤亡的系统进行测试的方法。本书介绍的测试并不是要确保产品无懈可击，而只是让产品使用起来更容易。在生死攸关的情况下，您应该进行科学，全面而细致的，大样本，可重现的定量研究，它的结果通常具有统计意义。至少，我会这样做。
唯一而且正确的方法。大部分测试都有很多方法，如果可以选择，我通常会选择对大多数人来说最适合的方法或对初学者来说最简单的方法，但这并不意味着这是唯一可行的方法。
必不可少的配套网站
本书有一个配套网站（www.rocketsurgerymadeeasy.com），读者可以在这里下载一些文件，例如，测试演示视频以及书中所有的脚本、表格和材料。
任何人都可以下载这些文件，我希望自己进行测试的人越多越好。这些文件可能会在某些时候更新，但就我对自己的了解而言，这种可能性不大。
箴言？您确实想把它们叫作箴言吗？
本书中有一系列称为箴言的东西——实在找不到更好的词了。它们看起来就象下面这样，因此很容易找到。
宽松招募并采用相对评分法（grade on a curve）
这些箴言是什么呢？有点像他们说的关键成功要素。在教别人自己进行测试的过程中，我发现只要牢记几个关键点就能成功；但出于某些原因，人们好像很难完全记住。因此随着时间的推移，我将它们浓缩成了更好记的箴言。
即使将这本书上所有的内容都忘了，也别忘记这些箴言，它们是最重要的告诫。
一些鼓励的话
准确地说是四个字：您做得到。
多年来，我将“这并不难（it's not rocket surgery）”作为公司的座右铭，因为我深信大多数可用性测试工作从本质上说并不太难。我还没有遇到不能做可用性测试的人，而显然做一些测试比不做要好得多。
鉴于您正在阅读本书，您很可能是公司或部门的用户代言人：最有兴趣确保产品（网站或桌面应用程序等）对用户友好的人。
公司对您这种兴趣提供的支持可能不多，您甚至得不到任何支持。也可能您获得的是精神上的支持，而不是资源方面的支持。因此，您只能在业余时间从事这项工作。
但是请振作起来，不要气馁。可用性测试很容易，几乎任何人都能做到，您下周就可以开始；还有经常被人们遗忘的一点是，这很有趣。我认识一些已经从事可用性测试多年的人都仍然觉得它令人激动并对此乐此不疲。
那么尽早开始，让测试尽可能简单，好好玩吧！
FAQ
这本书是不是新瓶装旧酒呢？
谁让您进来的？《Don’tMakeMeThink》 的第9章
不是，绝对不是。我的前一本书介绍如何设计以提高可用性，而这本书介绍如何进行可用性测试。
从某种意义上说，本书是《Don't Make Me Think》中介绍如何进行可用性测试的第9章的扩充版。
令人欣慰的是，很多人都写信告诉我，他们已经开始根据该章的简短介绍进行测试了。而这本书，就是介绍如何进行测试的完整指南。
另外，《Don't Make Me Think》的所有标题都是红色的。
如果我并不打算做任何测试，是否还应该阅读本书呢？
是的。即使您确信您不会做任何测试，也建议您阅读本书，我想您将发现有关章节——尤其是有关如何修复问题的章节值得一读。
另外，强烈建议您即使不做完整的测试，也应该花半个小时对您开发的产品做简单的可用性测试。如果进行尝试，您将发现快速的非正式的可用性测试是一个不错的选择，随时可以供您使用。
您是不是过度简化了可用性测试？
是的，这正是关键所在。只要您动手去做，这种可用性测试就极具价值，很多人不做是因为他们认为这过于复杂，因此我尽一切努力使它尽可能简单。
这只适用于网站吗？
本书的重点是网站测试，这是因为当前大多数人都在进行网站开发，同时，这样做也旨在确保本书简短而简单。这些方法和原则也可以用于测试并改进人们使用的其他任何产品，其中显而易见的是We b应用程序和桌面软件，但也同样适用于手机、PowerPoint演示文稿、数码相机说明书以及您在医生办公室填写的表格。我想您可以将本书中的“网站”都替换为“产品”。
您怎么能在一本新书中包含“FAQ”呢？
这个问题问得很好。这些问题是我在讲座中经常遇到的，我想本书的读者也会存在这些疑问。找出问题第1章您看到周围有大象吗？
DIY可用性测试是什么，为何它很有效？为何很少人这样做？
您为什么拿着一只鸡在头上挥来挥去？
为了赶走大象。
这管用吗？
您看到周围有大象吗？——一个非常古老的笑话
介绍DIY可用性测试之前，先让我来说一下什么是可用性测试。
很简单！
观看其他人试着使用您正在（或已经）创建/设计/建造的产品，目的是（1）让它使用起来更容易；（2）证明它容易使用。
可用性测试的种类有很多，但它们有一个共同点，那就是都需要观察用户实际使用产品。
实际使用使得可用性测试与调查、访谈和焦点小组等方法截然不同。在调查、访谈和焦点小组中，您将询问用户对产品的看法或过去的使用体验。
为了将各种可用性测试进行分类，一种有用的方法是，看它是定性的还是定量的。
在定量测试中，您的目的是要证明某个结论，例如“最新的版本是不是比以前的版本好？”或者“我们的网站与竞争对手的网站使用起来一样容易吗？”；这是通过测量诸如成功率（多少人完成了您指派给他们的任务？）和完成任务花了多少时间等指标来实现的。
由于目标要进行证明，因此定量测试有点像科学试验：它们必须严密，否则结果将不可信。这意味着您必须制订测试方案，并严格按方案测试所有参与者。您必须仔细地收集数据。您必须有足够大的参与者样本，以确保结论具有统计意义。而这些参与者必须能够代表实际用户，这样才能将结果外推到更大的人群。所有这一切都意味着您必须对测试有深入的了解，并在测试中小心行事。
在定量测试中，为了避免测试结果受到影响，您通常要尽最大的努力减少与参与者的交互。在极端情况下，参与者独自坐在房间里，主持人通过对讲机发出指令，而观察者通过单向玻璃进行观察并记录数据。
那么，什么是DIY可用性测试呢？
现在您可能猜到了，我向您推荐的测试位于定性——定量谱系的另一端。
DIY可用性测试绝对是定性的，它不是要证明什么，而是要让您获得用来改善产品的观点。
因此，DIY测试不用那么正式，也不用那么科学。这意味着您可以测试更少的用户（只要能获得所需的观点就可以），甚至可以在测试中途改变规则。例如，如果第一位参与者不能完成某个特定任务而且其中的原因显而易见，您可以修改这个任务，甚至让其他参与者跳过这个任务。而在定量测试中不能这样做，因为这将导致结果无效。
基本上，只需要主持人和参与者坐在一起，将要执行的任务交给他，并让他在执行任务期间进行发声思维就可以了。
不需要收集数据，相反，开发小组成员、客户和其他利益相关方将在另一个房间通过屏幕共享软件观察测试过程。测试完毕后，观察者们将进行总结（debriefing），他们核对所做的记录，并确定要修复的问题以及如何修复它们。
仅此而已。
有趣的是，这确实管用
在做可用性测试讲座时，我总是首先进行一次现场演示——完全临场发挥。我做的唯一准备工作是，选择一位出席者的网站并使用它，找出访客在该网站可能想完成的一个任务。例如，如果是卫生保健网站，我可能选择一个有关预约挂号的任务。
接下来，我让一位志愿者充当测试参与者，并花15分钟进行简化的测试（真正的测试通常需要一小时，但也可能短到只有5分钟或长达一整天）。
结果几乎总是相同。
参与者度过了一段美好的时光，并且因为勇敢地充当志愿者而获得热烈的掌声。
网站“所有者”在整个15分钟内都忙于记录要修复的问题，并询问能否将录像播放给同事和老板看。
每个人最后都想 ：“这么简单？我也能做”。
测试结束后，我问，“这15分钟花得值吗”？所有人都点头表示同意。
现场演示是为了表明（1）这很容易；（2）总是管用。有些人认为我之所以能够让测试看起来很容易是因为我做过很多次，但等到讲座结束以后，尝试过测试的每个人都认为这没有什么神奇之处，它确实像看起来的那样简单。
必须承认，我在最初几次现场测试演示中有些担心。但到目前为止，我做了大约50次这样的测试，每次都管用，无论测试的是哪个网站，也不管参与者是谁。
事实上这确实管用。只要问一问做过可用性测试的人，他都会告诉您这几乎总是管用。只要让人们——任何人坐下来使用您正在开发的产品，他都不可避免地会遇到一些问题，而这些问题是大部分用户都会遇到的。
但它为何管用呢？
只需要做这么简单的工作（让人执行任务并观察）就总能发现严重的可用性问题，这看起来有些不可思议。但只要考虑一段时间（而我考虑了多年），就能明白其中的原因。
它之所以管用是因为每个网站都有问题。每个人都可以根据自己的经验了解到这一点。在使用网站的过程中，您经常会遇到可用性问题，而这些问题通常很严重，让您极度沮丧甚至无法完成原本要做的工作。
有些成熟的网站可能没有那么多严重的问题，尤其是经过多轮可用性测试以后，但不要自欺欺人：您的网站肯定存在可用性问题。我的网站也存在可用性问题，您可以想见这有多让人难为情。甚至Amazon网站也存在可用性问题，而我对该网站的评价很高。
它之所以有效是因为严重的问题通常容易发现。同样，想想您在其他人的网站中遇到的可用性问题吧。您是否经常这样想：他们怎么可能不知道这种问题呢？很多最严重的问题一眼就能发现，几乎所有人都会遇到。
但是对于我们自己的网站，我们却总是认为这样的问题难以发现。
对您来说，您自己网站的可用性问题可能不明显，因为您知道该网站的工作方式——至少是您认为的工作方式；而用户并不知道，这就是区别所在。
当然，也有一些严重的可用性问题隐藏得更深，这种问题不会有那么多的访客遇到。但是除非有大量资源用于可用性测试（例如，这是您的全职工作），否则强烈建议您重点排除那些显而易见的问题，而大多数网站连这一点都没有做到。
最后：
它之所以管用是因为观看用户使用产品能让您成为更优秀的设计师。虽然大多数网站开发人员都知道诸如“以用户为中心的设计”和“用户体验”等术语，但设计师、开发人员、客户、经理和支票签字者——所有参与设计过程的人都很少花时间观看用户如何使用网站。因此，最终用户变成了抽象的概念，而设计是根据我们自己的想象完成的。
通过观看测试过程可以让您更深入地了解用户如何使用产品以及如何为使用而设计产品。它赋予您设计的智慧，就像旅行可以开阔视野一样。
为什么很少有人进行测试
既然它这么容易而且这么有价值，为什么可用性测试没有成为每个We b项目的标准组成部分呢？即使在当前，进行可用性测试的公司也很少，即使做，他们也通常只做一次，那就是在项目即将完成的时候。
在我看来，这在很大程度上是因为大多数人都没有任何可用性测试方面的直接经验，他们还没有认识到测试的价值所在。但是即使他们有这样的经验，也还是有很多似是而非的理由不这么做。
例如，没有时间。测试看起来需要做大量的工作，而大部分人手头的工作还来不及完成呢！大多数网站开发的日程安排都非常紧张，因此一种普遍的态度是“先发布，以后再调整”。
另外，人们普遍不愿意展示未完成的产品。既然我们都知道产品有问题，为什么还要向别人展示并让他们告诉我们已经知道的问题？这不是在浪费彼此的时间吗？谁喜欢向公众展示产品的缺陷呢？
这些说法好像都很有道理，但正如您将看到的，它们并不一定正确。
FAQ
您讨论的是小样本测试。通过网站分析从大量用户那里收集数据不是能获得更可靠的信息吗？
是的，网站分析让您能够非常精确地了解用户在您的网站中做了什么（72%的访客在5秒钟内离开了主页）。它的样本非常大（实际上是所有用户），数据是根据实际使用情况收集的，而分析工具让您能够提出任何统计性问题并立即得到答案。
但问题是，正如任何可用性专业人员都乐意向您指出的，虽然通过分析工具可以非常详细地了解用户在您的网站中都做了些什么，但它们并不能告诉您用户这样做的原因。例如，如果访客在某个特定网页上花费了大量时间，统计数据并不能告诉您这是因为他们发现这个网页的内容很有用并忙于阅读，还是因为这些内容不知所云，他们正忙着猜测呢。
而可用性测试非常适用于帮助您了解访客的所做所为背后的原因。
在需要找出并修复可用性问题时，可以使用精确的数据分析，它们将告诉您用户都做了些什么，但您无法知道用户是怎么想的。也可以和用户坐在一起一个小时，这能够让您倾听用户的想法并提出探究性的问题。如果必须在这两者之间做出选择，我每次都会选择后者。第2章现在我就要把我可爱的助手切成两半
DIY可用性测试是什么样的？一切不过如此/我的朋友？——Peggy Lee 演唱的歌曲Is that all there is中安慰绝望者的叠句。
在上一章，我描述了自己在讲座中做的测试演示，现在您将观看一个这样的演示视频。
从很大程度上说，它与您将对自己的网站（或应用程序什么的）所做的测试相同，主要区别在于，在实际测试中参与者将完成更多或耗时更长的任务，因此测试过程通常将持续一个小时。
请访问www.rocketsurgerymadeeasy.com并播放“Demo Test”文件。
1.如果您现在不能上网（例如，在不支持Wi-Fi接入的老式飞机上阅读本书），也不用担心，直接进入下一章即可。但务必一有机会就马上观看测试演示。
2.观看时别忘了演示结束后我将要求您列出三个可用性问题，这些问题是您在观看期间注意到并且最想修复的。
仅此而已吗？
是的，仅此而已。没什么神奇之处，也不需要特殊技能。有些参与者遇到的问题更多，让您迸发出更多的思想火花，而有些参与者遇到的问题更少，但通常您都将从每个参与者那里学到很多。
FAQ
如果不介意，请问您为什么用一整章介绍这么点内容呢？
因为观看测试演示很重要，我想确保您这么做了。第3章每个月一个上午，仅此而已
一个您可以采用的实用方案每周一罐，仅此而已。——Blue Diamond Growers 公司于1990 年左右使用的广告语，获得了巨大成功。
正如我在第1章所指出的，有很多不进行可用性测试的似是而非的原因，但大多数人不进行测试的主要原因是，他们以为这是一项庞大的工作——我将其称为庞然大物式（Big Honkin’）测试。
在讲座中，我制定了一个合理的方案，任何人——无论是大型组织还是个人作坊都能负担得起，它让您能够在项目进行期间对产品进行多次测试。
这个方案可行而且管用，它发现的问题足够多，但又不超出您的实际修复能力，并且让您能够首先修复最重要的问题。
我喜欢这样总结这个方案。
每个月一个上午，仅此而已。
基本上，这相当于每个月做一轮测试，每次测试三位用户。
在测试当天，您在上午进行三场测试，并在午饭期间进行总结。等午餐结束后，这个月的可用性测试工作就完成了，也知道了要在下一轮测试前修改哪些问题。
这里有两个重要的关键字。
一个上午 ：将测试限制为半天，这意味着只测试三位用户，从而可以简化招募工作，同时将有更多的人来观看测试。
每月一次。每月一次是不错的频率，这是大多数小组能够承受的测试频率，同时发现的问题足以让您在下一个月忙于修复。
如果您宣布了将在每个月的第三个星期四进行现场测试，就可以期望单位的人到时候到现场观看，而开发小组也将在那个时候准备好用于测试的产品。
通过将测试作为固定的例行活动，就不用再决定什么时候测试，而只需要在测试的当天对准备好的内容进行测试就可以了。如果必须考虑什么时候进行测试，结果就是不会经常测试。
比较DIY测试和庞然大物式测试“每个月一个上午”不仅仅指时间上的安排，它还意味着让测试尽可能简单，以便经常测试。
DIY测试并不像庞然大物式测试那样面面俱到，但它将以能够承受的代价提供我们所需要的结果。下面概述了这两种测试之间的差别，本书后续章节将详细介绍各个部分。
FAQ
真的每个月只需要一个上午吗？
不，不完全是这样。我说的是测试和总结只需要一个上午就能完成。对团队的大多数人来说，这是他们每个月需要花的时间。
但作为主持人，您需要为每轮测试做些准备工作：决定测试什么内容、选择任务、编写情景、招募参与者以及让所有利益相关人参加。
第一次测试时，至少需要两三天才能完成这些准备工作，但对于以后的测试，可以将时间大幅削减到两天甚至一天。
可以以更高的频率测试吗？
当然可以。每个月一个上午只是最低要求。不管您开发的是什么产品，多做一些测试都会有好处。
重点是至少每个月要进行一轮测试。只要您在某个月的第三个星期四中断测试，就又需要重新做出什么时候进行测试的决定，这意味着测试的频率将急剧下降。
我们采用的是敏捷开发方法，每个月只需要一个上午进行测试？太好了！
鉴于敏捷开发的周期很短，如果等一个月才测试，黄花菜都凉了！在这种情况下，可能是“每个开发周期一个上午，仅此而已”。
从很多方面说，DIY测试非常适合用于敏捷开发方法，这种方法的基本原理在于快速开发出产品的一部分并呈献给用户。唯一的问题是，在很多情况下这些“用户”是负责开发工作的小组成员（您需要改变这种状况）。
由于每个月需要多测试几次，您可能想让每轮测试更简单（例如，测试两位参与者，而不是三位），并偶尔采用远程测试（请参阅第14章），这样可以节省大量时间。但除此之外，测试过程几乎完全相同。
在敏捷开发环境中进行可用性测试面临的最大挑战是，您需要始终走在快速行进的程序员前面，他们没有时间建立原型（他们编写的都是可以工作的代码）。
这意味着您可能需要花些时间创建他们下一个周期开发工作的原型。因此，在每轮测试中，您可能需要测试开发小组在上一个周期所做的开发，还需要测试他们接下来的开发工作原型。
必须在上午测试吗？
并不是一定要在上午测试。例如，有些参与者可能在工作期间参与测试有困难，您可以选择在下午6~8点进行测试（提供晚餐以提高观察者的参与热情），并在第二天的早餐或午餐期间进行总结。
这里的要点是在半天内完成所有测试，以便能让尽可能多的人前来观看，并在每个人都还对细节记忆犹新的时候进行总结。
如果有人说每次只测试三位用户没有统计意义，什么也证明不了，我该如何回应呢？您该这样回应：
您说的太对了，测试这么少的参与者不可能得到有统计意义的结果。样本太小了，甚至都不用劳统计学的大驾。但这种测试并不是要证明什么，而是要找出并修复主要问题来改善产品质量。这种测试很管用，因为大多数需要修复的问题都显而易见，根本不需要证明。
这样说时请尽可能使用令人信服的语气，并报以友好的微笑。
这种测试的总费用是多少呢？
下面是DIY测试的年度支出（不包括您的时间成本）。
如果没有申请到预算，可以采用下面的简化版。第4章测试什么？何时测试？
为何最难的是尽早开始测试？下周吧，到时候我们将有一张在更大的餐巾纸上绘制得更好的草图。——每当我要求看餐巾纸上的设计草图时，客户都这样说。
如果要观看其他人如何使用您设计的产品，就必须有产品让他使用，这很容易理解。这意味着您必须决定每个月都测试些什么。
人们通常认为要开始测试，就必须有能够工作的东西——即使不是成品，也至少是可以工作的原型。
但是如果说可用性专业人员也有看法一致的地方，那就是应该尽早进行测试。错误的想法正确的想法
他们根据经验得知，在开发过程的早期就可能发现严重的可用性问题，哪怕这个时候可以展示的东西很少。
他们还知道，如果能尽早发现可用性问题，修复起来将容易得多，付出的代价也小得多，可以将问题消灭在萌芽状态。有时候一些严重问题由于发现得太迟而根本无法修复。一种最糟糕也是最常见的做法是，等到网站建成并要发布的时候才进行测试。
遗憾的是，专业人员也知道人们对尽早测试存在抵触情绪，下面是一些常见的理由。
我们做的工作还不够多：毕竟，如果产品还不能运行，用户怎么能使用它呢？事实上，越早向用户展示设计理念越好，最好有了第一个草图就向用户展示。
太粗糙了 ：设计师通常不愿意展示还没完成的作品，但是面对粗糙的作品时，用户可能更愿意大胆评论，因为他们知道设计肯定要修改。
为什么要浪费别人的时间让他们审阅自己都知道要修改的设计呢？在设计过程中，您心目中总是有比通过代码或稿纸呈现的设计更好的版本。是的，用户会遇到您早已心知肚明的问题，但是也可能会给您带来一些意想不到的惊喜。事实上，您很可能获得惊喜：因为您只见树木不见森林，或者存在一些因为没有像想象的那样了解用户而没有考虑到的问题。
在何时进行测试方面，我能提供的最佳建议是：
尽早测试，越早越好。
您的本能反应是等一等，这无疑是最糟糕的。
设计越糟糕，就越不愿意给别人展示，而越给别人展示，好处越多，这真是一个悖论。
在整个项目开发过程中，项目小组将生产各种设计产物：草图、线框图、网页设计、工作原型等。通过测试所有这些产品以及现有网站和其他人的网站，您将获益良多。
在本章接下来的篇幅中，我将为大家介绍可以进行测试的各种内容、怎样测试它们以及将从中获得什么。
测试现有的网站
如果您已经有一个网站并打算重新设计，显然应该首先对它进行测试。
怎样测试
按第5~9章详细介绍的过程进行。
将从中得到什么
您将了解到当前的很多错误做法，从而可以在重新设计时避免它们。您可能想更进一步，先修复您发现的一些最糟糕的问题。重新设计需要时间，为什么要让用户的痛苦等到重新设计完毕后才得以解脱呢？
您还将了解到一些以前不知道的用户访问行为。
测试其他人的网站
在设计自己的网站之前，通过测试其他人的网站可以获得很多经验教训。这可能是竞争对手的网站，也可能只是内容或目标用户与您即将组建的网站类似的网站，又或者某个提供了您打算实现的功能的网站。
其他人的网站是一种没有得到充分利用的资源。对于您想要解决的问题，肯定已经有人经过艰苦努力解决了，您可以充分利用他人留下的劳动成果。
大多数人并不重视这种机会，然而这样做可以避免您付出大量的劳动。例如，如果要搭建一个旅游网站，可以观看访客如何在其他旅游网站预订旅行服务，这将让您学到很多东西。
怎样测试
按第5~9章详细介绍的过程进行。
让参与者完成访客将在您的网站中完成的一些重要任务。您可能想让每位参与者在两三个竞争对手的网站中完成相同的任务。
但在总结会（这将在第10章介绍）期间，小组应该讨论哪些功能很好、哪些功能欠佳以及从中可学到哪些经验教训，而不是确定哪些问题最严重（因为您显然不会去修复它们）。
将从中得到什么
这里的目的是从他人那里学习经验教训：哪些做法可行、哪些做法不管用。
可以想见，测试他人的网站对市场营销人员和管理层很有吸引力：他们总是对竞争对手的做法充满好奇。这是一种吸引他们前来观看测试进而关注测试的高明手段。
测试他人的网站还是一种在没有任何压力的情况下进行测试的好方法，可以避免开发团队的抵触情绪，因为测试的不是他们开发的产品。
测试餐巾纸上的草图
在任何项目的早期规划阶段，都可能有一些草图或概念示意图，我通常称之为“餐巾纸上的草图”（这些草图可能确实是绘制在餐巾纸或餐具垫上的）。例如，对于网站，您可能有主页或产品网页的草图。
对餐巾纸上的草图进行测试总是值得的。
怎样测试
餐巾纸测试并不是完整的测试，他们类似于主页浏览，就像我在测试演示中所做的那样。每次测试都不超过五分钟。可以让朋友、邻居或您遇到的任何人来进行餐巾纸测试，也可在实际用户聚集的地方（如展览会或用户组会议）进行这种测试。具体步骤如下所示。
1.随便找一个人。
2.问他能够帮忙看看草图吗？
3.将餐巾纸草图递给他（这可能是整洁的示意图，也可能就是餐巾纸上的草图）。
4.让他们解释该草图以及该草图表示的是什么。
注意，您要询问的不是他们的看法（您喜欢该草图吗？）或反馈（您对这个草图怎么看？），而要让他们看草图并尝试确定它是什么。
5.仔细倾听。他们可能这样说 ：这看起来像是网站的主页，您想通过它销售____。这些是您要销售的产品。这里有“Store”的字样，我猜我可以在线订购产品，但不确定这个叫“Incentives”类别是什么意思。
如果愿意，您也可以提出一些探测性的问题，例如“您认为Incentives是什么意思呢”？
如果他们的描述符合您的预期，就可以用一块更大的餐巾纸继续绘画了。然而，通常草图中有些东西是他们无法理解的，或他们的解释与您的预期大相径庭，这让您能够在开发开始之前就发现一些重要的问题，并且可以立刻修复他们。
将从中得到什么
您可以了解到您的概念是否容易理解——也就是能让访客弄明白。他们将让您确信自己处在正确的轨道上，或他们将指出一些基本问题，让您能够尽早着手处理。
这里给您提供一个我自己的例子。长久（实际上是多年）以来，我都想将把这本书叫作Krug's Field Guide to Users，而整本书的设计将模仿观察研究野鸟的图书，包括开本、形状和外观。
我想这是一个不错的主意，事实上我认为这是一个惊人的主意。我太喜欢了，只要想一想，就能让我兴高采烈。为了激发灵感，我将封面的草图贴在了办公桌旁边的墙上。
接下来我做了件蠢事：根据自己的建议对此进行了测试，结果大家都口诛笔伐。
每个人都认为这就象一本有关观察研究野鸟的图书，他们都认为这是个“好”主意。
他们无不认为这是一本研究各种网站用户的图书。当我告诉他们该书介绍的是可用性测试时，他们都很惊讶。他们不是对我撰写有关测试的图书表示惊讶，只是封面误导了他们。
不识庐山真面目，只缘身在此山中。是我自己了解得太多了。
测试线框图
绘制草图后，网站设计的下一步是创建线框图。
线框图实际上是网页的示意图，它通常呈现了网页上的各种内容以及它们相对的突出程度，还有诸如菜单和搜索等导航工具。
怎样测试
您可以通过虚构任务测试线框图，这些任务通常都与导航相关：“您将怎么找到____？”、“您希望点击这个链接以后看到什么？”。
线框图测试不需要很长时间，因为用户使用它们可以做的事情不多，所以通常可以将这种测试与其他测试（如测试现有网站或他人的网站）一并进行。
将从中得到什么
这里主要测试的是分类和命名方案：访客能不能找到需要的东西？您使用的类别名称是不是合理？导航的工作原理是不是清晰？例如，您可能发现网站是根据组织结构图组织的，而访客并不以这样的方式思考。
测试网页设计
通常，网站由几个独特的网页（如主页）以及一系列重复但包含不同内容的模板（如栏目首页、文章网页和产品网页）组成。创建线框图后，接下来通常需要将这些不同类型的网页可视化（或者制作样稿）。线框图的重点是交互，而样稿（comp）的重点是视觉设计。
怎样测试
您从主页开始向参与者手工展示样稿，并让他们描述每个网页（详情请参阅第8章）。
将从中得到什么
这样做的目的是检查视觉设计是否带来了可用性问题。访客能明白每个网页的工作原理吗？
测试工作原型及其他
在接下来的项目日常安排中，您将对可以工作的网站部件进行测试，从原型到完成的栏目再到完成的网站。
怎样测试
按第5~9章详细介绍的过程进行。
将从中得到什么
改进网站所需要的所有观点。第5章宽松招募和相对评分法
让什么人参与测试以及如何找到他们只测试一名用户绝对比不测试强。——Krug可用性测试第一定律
现在，烦人（至少对我来说如此）的部分就要开场了：招募测试参与者。
Jakob Nielsen认为这项工作单调乏味，确实如此，它就是确定要招募什么人、找到他们、安排时间约见并让他们到场。
我从来就没喜欢过这项工作，可能因为它是测试过程中唯一与可用性关系不大的部分，也可能是因为我生性不适合这种工作（这要求您做事井井有条，而且对与陌生人交流乐此不疲）。也有一些人很擅长这么做，还有一些人乐在其中呢。
但无论喜欢与否，如果要观察参与者，就必须找到可供观察的人。与测试过程的其他部分一样，您希望它越简单越好。
该过程可以归纳成这么几个问题。
招募什么样的人参与测试？
需要多少？
如何找到他们？
如何补偿他们付出的时间？
招募什么样的人参与测试？
在确定招募什么样的人方面，几乎所有的人想法都差不多。
这看起来完全合理，毕竟：
这是显而易见的。对于那些不会使用您的网站的人，对于他们能否使用您并不关心，为什么还要他们参与测试呢？
在测试中，有代表性的用户更可能与实际使用网站的人遇到相同的问题。
非目标用户可能遇到实际用户不会遇到的问题（假阳性现象）。
目标用户具备其他人没有的专业领域知识。
但事实证明，选择能够代表目标用户的人进行测试并没有看起来那么重要，也没有那么简单。
就拿专业领域知识来说吧。
显然，在有些情况下，专业领域知识和经验很重要。例如，如果要测试的是用于订购专业起重机的表单，访客必须在其中填写诸如跨度、起重臂高度和起重量，则可能希望参与者对起重机有所了解。
但即使在专业领域知识很重要的情况下，这也可能很难说。
目标受众可能比您想象的更变化多端。例如，新手通常没有专业领域知识，但也需要使用您的网站。如果您在线销售汽车保险，可能想将重点放在有车且有一定车辆保险知识的人身上，但也希望首次购车的人能够使用您的网站。
被假定拥有专业领域知识的人不一定都具备您认为他们应该具备的知识。例如，几年前我对一款为房地产中介设计的产品进行了可用性评估，界面有一个专业术语非常显眼，但我不知道它的意思，因此我向设计师请教。设计师们说每个中介都知道这个术语，而且他们也经常用到。后来，我请一位向我卖过房子的中介做了一次快速的可用性测试，结果他一看到这个术语，就指着它问：“这是什么意思？”
很多最严重的可用性问题与专业领域知识毫无关系，而与导航、网页布局、视觉层次等相关——就是那种几乎任何人都会遇到的问题。
我并不是说您不应该招募更接近实际用户的参与者（在确实需要实际用户时，请务必招募这样的参与者）；而是说不要生搬硬套。对有些网站来说，找到实际用户没有任何问题；但对其他网站来说，这样做将耗费太多的时间，而且费用高昂，而这并不总是必要的。
是的，有些问题只有通过观看目标用户使用网站才能发现；但很多问题通过观看任何一个人使用网站都能发现。在可用性测试初期，网站可能存在大量严重问题，这些问题几乎任何人都会遇到，因此开头可以非常宽松地招募参与者。随着时间的推移，您可能想更多地依赖于实际用户，但即使在这个时候，我也会在每轮测试中招募一名“棒槌”。
我还发现，不属于目标用户的参与者有时也能够发现实际用户无法发现的问题，因为他们是从局外人的角度看待网站，这就是“皇帝的新装”效应。我宁愿要一个有一定常识、善于表达和交流的局外人，也不想要神情十分紧张、说话怪异的实际用户。
多年来，我就有一个有关招募的箴言。
宽松招募并采用相对评分法。
这意味着尽可能寻找能代表目标受众的用户，但也不要在一棵树上吊死。相反，应该允许测试参与者与实际用户之间存在一些区别。
当参与者遇到问题时，问问自己：目标用户是否也会遇到这种问题？还是由于参与者不熟悉术语或不具备专业知识导致的，而实际用户绝对不会遇到？
三位参与者足矣
在可用性社区，对于需要多少位测试参与者长期争论不休，就像一场几十年来一直没有扑灭的煤矿火灾。
几乎所有人都同意这一点，让越多的用户完成相同的任务，回报越少：因为测试的用户越多，发现的新问题越少。不过大部分的研究，以及争论，都集中在到底测试多少用户才会发现产品的大部分可用性问题，例如，“测试五名用户将发现85%的问题”。
但对DIY者来说，这种说法是错误的。您并不是要发现大部分问题，而只是想发现一些可以修复的问题。
经过多年的实践，我决定在每轮测试中招募三位用户。
前三位用户很可能会遇到您的测试任务里最重要的那些问题。
找到三位参与者需要的工作比找到更多参与者要少。
与最大限度地利用每一轮测试相比，多做几轮测试要重要得多。如果每轮只测试几名用户，那就更容易多做几轮测试。
测试三名用户使得测试和总结可以在同一天完成。
测试的用户较少时，更容易说服相关人员前来观察。
除回报不断降低外，对主持人和观察者而言还有一些其他的问题。从测试第四位用户开始，观察者通常会吃更多的点心、更多地查看语音邮件以及闲聊。
当一次测试的用户超过3位时，通常会得到更多没有时间处理的笔记，而其中很多问题都是无关痛痒的。这可能会掩盖更严重的问题——“只见树木，不见森林”效应。
测试大量用户可能发现过多的问题，而对这些问题进行鉴定和优先级排序本身就是一个问题，需要产生额外工作量。
摆脱困境的简单之道：花钱解决问题
可以将这项工作交给为焦点小组招募参与者的人员，具体招募过程完全相同。要找到这样的人员，只需在网上搜索关键字“焦点小组租赁”或“市场研究”。租赁焦点小组设施的人通常会帮您招募参与者——即使您不租用他们的场地，他们也可以推荐从事这项业务的人。
招募人员将与您一起确定要招募什么样的人，然后他们将找到候选者（通过他们的数据库或广告）、进行筛选、安排时间甚至发提醒邮件以确保他们到场。
这些服务的收费没有您想象的那么高，每位参与者的招募费用可能不超过100美元，如果需要的参与者不好找，收费可能高一些。
在测试过程中，招募是唯一一项我建议外包的工作。不过既然这是一本介绍DIY测试的图书，在这里我们假设您将亲自进行招募，那么接下来将介绍如何完成这项工作。
到哪里去寻找参与者？
首先需要做的是考虑到哪里去寻找您需要的参与者。这让我想起了Willie Sutton被问到为什么要抢劫银行时做出的回答（“因为钱在那里”）：到您要找的人经常聚集的地方去。
例如，如果要招募老年人参与测试，可考虑前往老年人活动中心和图书馆。如果要招募产品用户，可尝试用户组、SIG和展览会（您甚至可以在展览会进行现场测试）。
如果要招募使用您的网站的人，可以在主页添加一个招募链接，也可以在网页创建弹窗邀请。
如果什么人都可以，考虑一下朋友、家人和邻居。不要觉得您是在强人所难，因为大多数人都会喜欢这种经历。有人认真对待您的看法还为此付钱本身就是一件很有趣的事，而且参与者还可以学到一些以前不了解的网站或计算机方面的知识。
请公司的同事参与测试很有诱惑力，他们是现成的，更容易找到，而且他们可能愿意伸出援助之手。如果是一个很大的企业组织，甚至可以找到背景与实际用户相符的同事。
但他们很可能知道得太多了。对于参与目标产品开发、支持、销售、培训和文档编写的同事，显然不能请他们参与测试。但单位内部可能有对目标产品知之甚少的员工，例如，参与其他产品开发或其他部门的人、行政人员、前台接待、财务或人力资源部门的人员。
另一方面，如果测试的是公司内部网，则新员工是最佳人选。他们通常渴望给人以良好印象，可能拥有专业领域知识，而且他们就是目标受众。
有一类候选参与者，我几乎可以保证不可行，虽然他们看起来很合适，那就是市场营销部门提供的用户清单。这可能是市场营销部门的一番好意，但根据我的经验，结果通常不会太好：要么管理层不想让客户过早了解产品，要么涉及隐私问题等。我只知道我从来没见过这类参与者可行的情形。
如果确实很难找到特定类型的用户，可以考虑进行远程测试（这将在第14章介绍），这样招募将容易得多，因为这一下子将潜在的参与者从“住在附近的人”扩大到任何有宽带Internet连接的人。
发出邀请
决定到哪里去招募后，便需要发出招募参与者的通知。例如：
我们将在6月25日（星期四）对网站进行可用性测试，现招募几名参与者。测试将在我们的办公室进行，持续时间大约一小时。特招募有在线支付账单经验者。
如果您有意且当日有空，请给Larry Smith发邮件，邮件地址为lsmith@companyname.com。请在邮件中提供您的姓名、电话号码以及合适的联系时间。
不要提供您的电话号码，否则您的电话会被打爆。和听几十个语音电话相比，浏览几十封电子邮件的效率要高得多，何况您要招募的人不会没有邮箱。
在什么地方发出邀请呢？您认为有人看到的任何地方。
张贴到布告栏和论坛。
发布到留言板。
通过您的工作或个人关系发邮件，并请他们将邮件转发给他们认为对此感兴趣的任何人。
在主页中放置一个招募链接或创建弹窗邀请。
试读结束[说明：试读内容隐藏了图片]