时间: 2021-07-30 09:30:35 人气: 12 评论: 0
你不需要一个完整的产品来验证用户反馈的价值。如果你等着在产品面世后才开始测试，那么为时已晚。
在用户体验和产品开发领域，调研和规划决对产品来说，起了决定的作用。
忽视它们，将让你以及你的团队蒙受巨大的损失，这包括高用户流失、客户服务需求（和成本）增加、开发成本和时间增加，总而言之——完全浪费资源。
可是，当最后期限临近以及预算过低的时候，我们能做什么呢？
你可以使用 Guerrilla 可用性测试，这是一种精益敏捷且节省成本的测试方法。
我们将用简单的 7 个步骤向你介绍如何构建 Guerrilla 可用性测试，并获得高效的回报。
不过，首先让我们回答 Guerrilla 可用性测试相关的三个最常见的问题：
Guerrilla 可用性测试的主要目的是快速发现问题和快速解决问题。
Guerrilla 可用性测试容易做，你不必担心下面这些事：
适合 Guerrilla 可用性测试的人才是我们所需要的。
这使得 Guerrilla 可用性测试非常精简和敏捷。你只需要几个小时便可发现问题。
并且测试过程非常的简短，大约 15 分钟左右：
因为在测试过程中你**收集定性数据，你只需要 3-5 个人便可发现关于产品的最大可用性问题。
发现问题后就立即解决，解决的问题将在下一轮测试中得到验证。
对于认可可用性测试价值的相关利益方而言，Guerrilla 研究是完美的启动方式。
我们容易接受用几个小时并且几乎无需花销的 Guerrilla 可用性测试，而不是需要数月规划和执行才能完成的测试。特别是当我们知道团队所有的时间不多，以及预算不足的时候。
有发现总比没有发现好。即便是你的研究快速简单，也是非常值得的，也比没有好。
与传统的可用性测试相比，无需招募 Guerrilla 可用性测试的志愿者，因为他们就在你身边。
一种较容易的方式是，把你的亲朋好友当作志愿者——他们无法逃脱，毕竟你知道他们住在哪。
值得注意的是，你的亲朋好友非常了解你和你的产品，很难从他们那得到真实的“产品初体验”；况且，你老妈和姨妈由于特别在乎你的感受而表现的过于友好…
因此，比较好的方式是采用对你和你产品不了解的人作为志愿者。这些人通常在咖啡厅或者商场。
专业提醒：如果你的原型和网站需要在线才能使用，确定选一个有稳定 Wi-Fi 的地方。哦，别忘了电也要充足，你也不想在测试的时候没电了吧。
我们为我们的业务做了数百次的可用性测试，并且还没有遇到过一次一无所获的时候。
这就是你要尽早并且经常测试的原因，毕竟解决问题的成本变得越来越高，你的产品也**越来越好。
牢记：你不需要一个完整的产品来验证用户反馈的价值。如果你等着在产品面世后才开始测试，那么为时已晚。
第一步：设计任务列表
第二步：定任务优先级
第三步：将任务设置在场景中
第四步：开始测试
第五步：发现问题
第六步：解决问题
第七步：再次测试、验证，形成常态
（文章介绍步骤于图**内容略有不同）
首先，要写下人们在你产品上完成的所有任务的清单。
如果人们在你的产品中买东西，在任务清单中就应该有一个要求测试者购买产品的任务；如果你想人们创建账户，也应该有一个这样的任务；等等。
例如，Facebook 的任务可能是：
你自己试着写写看，思考所有人们在你的产品中做的重要的事，并写下一个简短的任务清单。不过，不要在细节上浪费太多时间，仅仅是把人物写下来。剩下的，我们**在下一步中具体介绍。
当你有一个任务列表之后，是时候通过给 1-3 的分值来给所有的任务项拍优先级了，这些分值表示的是任务被使用的频率。
例如：
根据上面的打分，刚才我们列出的 Facebook 的打分是这样的：
不要过多的关注这个排行，通过这个排行找到用户最常用的任务就可以了。
为什么？
因为你一次不能把所有的测试项都做了（不在 Guerrilla 可用性测试中全部做完）。如果你把第一次测试的关注点放在发现并且解决最重要的部分，你**得到最高的投入产出比。
那么，我们就得到了 3 个最重要的测试项：
重申一次，Guerrilla 可用性测试是关于快速获得结果并立即采取行动的测试方法。
仅选 3 个最重要的测试项并开始执行。剩下的，稍后测试。
现在，将测试项放到用户能够阅读、理解、遵循的场景中。
专业提醒：只要你的场景合适，你的测试才能起作用。好的场景能够帮助你测试，那就和目标受众参与测试一样。
这里有几个设计场景的规则：
让我们用 3 个任务项试一下：
（1）滚动时间线
我们不能仅告诉用户在没有任何动机或目标的情况下“滚动时间线”。我们可以向人们提供一个理由去做，而不是描述要做什么。
不好：滚动页面查看新帖子。
这只**让你的用户像机器人一样执行任务。没有任何动机，他们只**翻阅页面，你不**了解到任何关于如何提高可用性的东西。
一般：看看这个页面，找出它的全部内容。
这至少是开放的，可以让人们更自然地浏览页面。只要告诉他们看看这个页面，他们很有可能**滚动浏览这些帖子来了解它的全部内容。
好的：想象一下，这是你今天第一次查看 Facebook。现在试着去找到今天发布的第一篇文章。
最后，这是有效的，因为它为用户提供了一个真正的目标。与其仅仅告诉他们该做什么（不好的）或希望他们**这么做（一般），你可以给他们一些特定的事情来做，这**自然而然地激励他们使用你的产品（好的）。
（2）更新状态
对于下一个任务，您需要激励人们输入实际数据（而不是滚动浏览）。让我们看看不同的方式：
不好：写内容并发布。
这给如何使用该网站提供了太多线索。人们只需查找“状态更新”，也可以选择“发布到个人页面”的按钮。再有，这种情况并没有提供任何动机或原因，为什么你想要更新状态。
一般：通过更新让你的朋友知道你在做什么。
这解释了为什么要更新状态。但它还不好。而且“更新你的状态”这个事实仍然存在，这使得它再次成为一个简单的寻找文字的游戏。
好的：找到一种方法让你的朋友知道你在做什么，并告诉他们你正在测试一个产品。
这非常有效，因为它避免提供关于如何使用的任何线索。再有，它为用户提供了一个特定的目标（找到一种让朋友知道的方法），甚至为他们提供了可以使用的信息。
这有助于减少在测试期间考虑应填写什么类型的数据而导致的心理努力。
（3）上传照**
这一个有点棘手，因为我们一定要避免“上传”和“照**”字样（因为它们在产品界面上），但我们又不得不告诉测试者上传照**……
不好：找到上传照**的方法。
这太明显，我什么都不想说……
一般：找到一种与朋友分享照**的方式。
这个其实很不错。虽然动机部分仍然让人摸不着头脑，但与朋友分享图**的想法是一种很好的方式，上传图**的行为定义对大多数人都是有意义的。
好的：昨晚你参加了一个派对，拍了一些滑稽的照**，现在你正在寻找一种方式分享，并且让你的朋友也能看到它们。
这提供了所有必要的上下文，来了解用户尝试实现的情况和目标。
注意每个细节是如何有意义的，并有助于整体理解。就像如果这些图**很滑稽，这**导致一些用户特别注意隐私设置（在与朋友聚**的前提下，“滑稽”一词相关的上下文内容，并不一定是大多数人希望公开的东西）。
好！刚刚我们只是将最重要的任务项转化为场景，现在是时候将它们组合起来：
好了，这很简单吧。现在你只需要开始测试。但首先阅读并学习如何去做第五步。
正如开头提到的，Guerrilla 可用性测试的秘诀在于接近人，并要求他们测试你的网站、应用或原型。
无需关心测试者，也不需要担心如何记录**话，因此不需要特别记录或其他任何东西，便可开始开始测试。
只要走到某人面前，问是否可以耽误他几分钟的时间。为了获得更好的效果，甚至可以提供一点小礼物感谢他们的参与，如免费咖啡或松饼。
一旦你足够亲切地接近他们，你也**找到其他人，并在每次测试时，都**变得越来越好。
（1）如何找到人参加
当你面对测试者的时候，你要怎么说话：
“嗨！我们正在做一个网站（应用、原型，或是其他），并且想看看它是否符合预期。请问能占用您几分钟时间，和我们一起看看这个网站么？
你愿意帮我们完成这些测试么？在你回答之前，你绝对不**做错什么的。另外，你可以免费享用咖啡、松饼，谢谢！“
（2）说明测试
由于大多数人不知道可用性测试是什么，所以在给出这个场景之前，通常要做一些解释：
“你必须知道的第一件事是：我们正在测试网站，而不是你。 所以你不必担心犯任何错误。我们希望看到你指出我们的错误。
当使用该网站时，我们希望你大胆地思考。只要说出你在看什么，它如何影响你，在每次互动之后你期望发生什么，你想要完成什么，等等。
请不要在意我们的感受。我们希望改进网站，并且需要听取你的真诚的反馈。“
这是有趣的一部分。只要给他们你的场景，退后并观察他们如何使用你的网站、应用或原型。并且记得闭嘴。
（3）记得保持沉默
在这种情况下一样，你不想给出任何有关网站使用方式的线索。
你不想引导你的用户。你想看看他们是如何找出自己的东西；或者他们怎么找不到，这可以帮助你了解更多！
避免引导用户的最好方法是：在测试过程中保持沉默。
在现实生活中，当他们使用你的产品时，你不**坐在他们身边。你当然希望测试**尽可能真实。
你的参与者当然**有问题，而且当你坐在他们旁边时，自然**指引他们走向你。
每当他们问你什么时，为了避免任何不好的感觉，只要这样告诉他们就可以了：
“这是个好问题。我现在还不想回答你，因为我们感兴趣的是当没有人坐在他们身边时，你如何使用这个网站。不过，我**在测试后给你答复。现在你有这个问题了，如果我不在这里，并且你正在使用这个网站的话，你**怎么做？“
你**找到自己的方式，来处理测试过程中出现的问题和其他情况。
唯一应该谈的是提醒用户大胆地思考。他们经常保持沉默，特别是在试图找出某些事情时，那就是当你必须给他们一点点推动时。
请记住，目标是让你的用户推动大部分的对话。理想情况下是 100% 的时间都是。
（4）讨论问题
一旦测试者完成了这个场景并且完成了所有的任务，是时候定位测试过程中出现的问题，并且可能的话，你自己也要提出一些后续问题。
如果碰巧遇到目标受众参与测试，你可能还想将其转换为客户访谈，并询问他们是否真的**使用产品。
但由于这不是可用性测试的一部分，我们继续下一步。
尽量避免在测试过程中发现问题。
恩，那就对了。因为如果你坐在测试者的旁边，并且你一直在写东西，你绝对搞砸了这次体验。
人们**感到压力，想知道你在写什么，或好或坏，或者他们做错了什么…
测试期间，你应该只需关注观察用户并试图理解他们的行为、他们的语言以及隐藏在这些背后的细微差别。
是的，用户在大胆地思考，但是人们很难将他们的潜意识思想转化为意识以及他们想要表达的意思。
这就是为什么你要不断问自己：“他们表达的想法背后还有其他意思吗？”
你的头脑必须被设定为观察（而不是记录），并且你**看到你能够记住所有重要的事。即便你忘了一些东西，你还**做其他测试（就如你在后面的步骤中看到的），如果这是一个真正的问题，它**再次出现。
那么，如何发现问题呢？
方法1：列出前 3 个可用性测试问题
发现问题最明显的方法是简单列出测试中确定的前 3 个可用性问题：
没必要记下来你发现的所有事情。Guerrilla 可用性测试是关于发现和解决主要问题的测试，而不是了解困扰用户的每一个细节的测试。
方法2：发现任务完成
记录发现的更复杂的方式是了解每个参与者的任务完成情况。
如果你需要提供给客户和其他利益相关者一些信息，这一点特别有用。
你可以使用以下方式：
结果可能是这样的：
我们在 Simplease 的项目中使用过这个表格。
正如本文开头提到的那样，解决问题可能很贵。特别是如果问题影响正在运行的应用和网站的时候。
这就是为什么在编写代码之前尽早通过设计原型并进行测试，尽可能解决主要问题的方法是十分明智的。
但是如果已经过了这个原型设计阶段，并且通过 Guerrilla 测试发现了问题，公司**花费数百个开发时间和数千美元才能解决问题么？（囧！感觉这个在国内，那都不是事啊～）
（1）优先解决最大的问题
如果你的工作是吃掉一只青蛙，那你最好早上就做它。如果你的工作是吃掉两吃青蛙，那你最好先吃掉那只大的。—— 马克·吐温
细心的读者**注意到一种模式。首先，我们只测试最重要的任务。然后我们只写下最重要的问题。现在我们先解决最大的问题。我们很快就做到了。
（2）快速解决问题
在解决问题时，尽量做到最少。—— 斯蒂夫·克鲁格
不断地问自己，你做出什么最小、最简单的变化，可能**让用户避免遇到问题。
对于直播网站尤其如此，但许多人反对这一想法。
在《妙手回春：网站可用性测试及优化指南》一书中，史蒂夫·克鲁格指出，你不必为问题寻找永久的解决方案。只需找到一个容易实现的快速解决方法，就可能解决问题，并进行更多的测试以确定这个方法是否已经可行。
（3）微调整，不要推倒重来
在完成了一些可用性测试并开始考虑如何解决问题之后，总是很容易做远**实际的调整。
迟早，你**发现就想要重新设计郑哥网站了。
这种推倒重来的偏见有很多原因，很容易理解为什么很多人喜欢重新开始，而不是仅仅实施一个快速解决方案。
我们自己有罪，但希望这份清单（依然来自斯蒂夫·克鲁格）能够帮助我们记住为什么调整比重新设计更好：
如果你仍然不相信快速解决以及它比推倒重来更好，那么继续进行 Guerrilla 可用性测试的下一步（也是最后一步）——再次测试并形成常态。
之后所有事情都**有意义…
（4）再次测试并形成常态
如果持续进行，可用性测试效果最佳。
不必花费过多的时间和金钱来进行复杂的可用性研究，以便推倒重来，你可以实施快速解决问题。
诀窍是继续测试以确保解决方案能够正常工作。
（5）测试频率
关于在可用性测试中需要多少用户，有一些有趣的讨论。
一个流行的经验方法是：与 5 个用户一起测试，以发现任何应用程序中最严重的问题。但一如既往，这取决于…
如果一个用户在 30 秒后遇到了了一个重要的可用性错误，其他四个测试就不需要了。
最后，这不是高深的事。有时候这很明显。即使只针对一个用户进行测试。
唯一重要的是定期重新测试（如果可能的话，每周一次）。
通过这种方式，可以查看调整是否真正解决了问题，并且确保发现可能由更改导致的任何新问题。
（6）让测试成为工作流程的一环
Guerrilla 测试往往比传统的可用性测试好几倍原因是，你可以负担得起定期做这件事；当然，我不仅仅在谈论金钱。
Guerrilla 队可用性测试既快速又简单、价格便宜，它的效果非凡，没有理由不这样做。
Guerrilla 可用性测试有很多种形式。在你使用的时候制定你自己的方法：边做边学。
原文作者：Markus Pirker
原文地址：https://userbrain.net/blog/7-step-guide-guerrilla-usability-testing-diy-usability-testing-method
郑几块，人人都是产品经理专栏作家，前新浪微博产品经理。
本文系作者@郑几块 独家翻译授权，未经本站许可，不得转载
题图来自 Pixabay，基于 CC0 协议
