【UXRen译#42】怎样利用行业会议之便进行用户测试

组织一次用户测试并不容易。敏捷开发要求持续不断地迭代，这使得我们很难有充分的时间进行设计，更不要说定期获取真实用户的反馈。

对我们很多人来说，进行正式的用户测试是个不小的挑战。这是由很多因素导致的：你没有足够的准备时间；找不到足够的参与者或者找到的参与者不符合条件；你很难从老板那儿得到资金的支持等等。

尽管如此，用户测试依然是改良设计的最佳选择。

如果只是基于日常数据或者自己的经验，你很难提出好的方案来解决用户遇到的问题。所以，用户测试至关重要，但问题是如何设计测试模型以及如何进行测试？

 

什么是用户测试？

要界定这个概念，让我们先看看用户测试“是什么”、“不是什么”

用户测试是….

• 正式的
  你的目标是从多名参与者处得到关于某个设计的定性反馈。保证每个用户的操作流程相似或一致，尽可能减少干扰变量的加入。这样，你就能弄清楚用户的共性问题。
• 可观测的
  用户并不能确切的说出自己的需要是什么。所以问他们“想要什么”并不是个明智的选择。相反，你最好做一个安静的观察者，给他们一个可操作的设计原型、从旁观察他们在真实任务中的操作反应。
• 基于实验的
  任何用户研究项目的核心都是基于一组（3-5个）研究假设进行的。而研究的目的通常都是证实或者证伪这些假设。以便在下一版本的迭代中，进行相应改进。

用户测试并不是….

• 即时判断
  收到一个用户的反馈后，不要急于做出任何判断。保持开放、客观的态度接受信息，直到从多个用户口中得到类似共同的信息时再做出判断。如果一次调研中有5-6个用户给予相同的缺陷反馈，这时才改进产品设计。
• 刨根问题
  访谈对于了解用户的角色、经验等背景资料，非常有帮助。但请保持访谈的简明扼要。通常，访谈更关注用户所说的话，而不是非要刨根问底，反复推敲他们实际的行为。
• 量化的
  因为样本量小，仅仅基于数据本身，你无法给出一个强有力的统计推论。如果你看重量化数据，那么请进行问卷调查、远程测试、或者是自主性的可用性测试。

 

什么是用户测试？

用户测试本身是研究项目：将面对的产品问题/需求转化为研究假设，制定相应研究计划，通过测试5-6名用户来检验这些假设。一旦完成以上步骤，你就需要对研究结果进行总结，以决定下一步该采取的措施。如果结论有指导意义，你可以据此改进产品设计。反之，你可能需要进一步的研究。

通常情况下，你无法在第一版时取得最佳答案。你需要对产品进行用户测试、迭代、并重复以上步骤。

好的用户测试应该有明确、可测量的产出。

如果你有明确的研究预期，那么你将更容易作出研究设计。这通常是以验证研究假设的形式来完成：对你认为可能正确的内容进行可操作的验证。好的假设有：

• 用户能够在五分钟之内完成：添加物品到购物车并结账的操作
• 用户会通过点击帮助、错误提醒等了解问题的具体原因或商品的详细信息
• 用户不会因为产品缺乏仪表盘举步不前

好的用户测试是易于实施的

如果你只是流程设计者，而不是测试的具体实施者，这一点就更为重要了。因为，如果实施者缺乏用户测试经验，那么你还需要提供一个易懂的测试脚本，写清楚测试的流程、阐明测试目的。

好的用户测试是注重细节和便于互动的

如果你想测量用户对屏幕上动效的反应，你可能需要一个经编程得到的测试原型。如果你想决定版本最终是否该删除某一特定页面，一套PSD模型（图片文件格式的模型）就可以了。不用说，这其中有很大的活动空间。成功的用户研究是严谨的，要得到有效的结果也是需要付出代价。如果你偷工减料，你能轻易预测到最终的结果，而且势必需要额外再进行一次研究来验证研究结论。

 

自我评估

前面我们了解了什么是用户测试，现在你需要问自己以下一些问题：

• 由你来实施用户测试吗？
• 用户测试是你工作内容的一部分？
• 你愿意做更多的用户测试吗？
• 是什么阻止你去做更多？

我经常问自己这些问题。令人惊讶的是，鲜有人能够持续进行用户测试（包括我自己），但每个人都希望能做更多的用户测试。这既是一个问题也是改进的机会。

 

快速迭代中的用户测试

敏捷开发的口号就是：“失败要趁早”。越早失败，你就能越早找到正确的产品方向。这相当于一系列的迭代过程。敏捷的团队通常要在两周内，发布一个可测试的版本。

这很牛吧~但带来的问题是：这使得团队很少有时间对产品设计进行测试和总结，或为下一次迭代做即时的设计。(对于用户测试来说，)招募用户通常就需要一周，更不用说实施测试的时间了。

但这是站不住脚的。在新一轮迭代开始前，你最多只有几天时间为下一版本提供指导建议。我们应该怎么解决这个问题呢？

让我们假设一下：

• 产品设计的过程，从开始到最终，需要进行五次迭代
• 每次用户测试需要5名参与者，那么共需要25名参与者
• 同时进行着四个设计，则那么共需要100名参与者

解决问题的方法是：在软件完成之前验证产品的多个版本。并且，不是每版设计都需要用标准的原型来验证。有时候可点击的PDF就够了。现在，我们已经对问题进行了转化：设计迭代的次数和参与测试的用户数是不变的，但你可以在开发之前进行用户测试。你需要做的就是尽快找到大量的参与者。

 

在行业会议中进行用户测试

除非你足够幸运，设计的产品有数百万的用户，否则用户招募始终是个难题。因为我的产品是专为系统管理员设计的软件，为期数天的IT大会是获得用户定性反馈的最好场所。

基本的步骤是：

1. 选择一个适合做测试的行业会议。
2. 写好调研设计
3. 布置好展位
4. 及时的分析测试结果
5. 基于测试结果进行设计迭代
6. 重复上述步骤

显然，你需要帮手，所以招募一些志愿者吧。另外，别期待着一次就能成功。给自己一些犯错的机会，并从中学习吧。

 

行业会议是短时间同时进行多个用户测试最好的选择

产品迭代的次数取决于你在测试中的收获。如果你时间充足且收获良多，那么请多进行几次测试。如果受到测试工具的限制，那你可能需要缓一缓，先和开发团队一起做一个经编程的模型吧。

额外提示：如果你会软件开发，自己能够完成产品原型。还是让开发人员与你一起工作吧，集思广益会更好。

声明：我已经两次在行业会议上做过用户测试了，仍然存在一些瑕疵（尽管我们已经在正确的方向上取得了长足的进步）。这可能需要再多些尝试，才能驾轻就熟。

 

第一次尝试：2012年的Puppet大会

Puppet实验室举行的一年一度的Puppet大会，是IT技术人员的专业会议。2012年，在旧金山使命湾会展中心举行，有750名相关专业人士参加。

团队的两名工作人员设计了五个研究方案，并在会展中心人流大的走廊里设置了三个用户测试点。每个用户测试点都有一台笔记本电脑、一堆测试脚本和NDAs（测试系统）, 由一名志愿者来执行测试。在这次会议中，我们一共有16名志愿者，测试了50名用户。

这次测试经历很有意义，但我们并没有从中得出太多有价值的结论。我们一直关注于数据的收集。直到会议结束后的几周里，我们才分析了这些数据，这意味着为时已晚。此外，我们这次用户测试并不是产品发展规划中的一环，因此这个研究及时性不强。

第二次尝试：2013年的Puppet大会

2013年，我们再次进行了用户测试。这一年的会议在旧金山的费尔蒙特酒店举行，并有1200名专业人员参与了大会。

这次，团队的5名工作人员设计了6个研究方案，并在人流量大的走道旁的室内空间里设置了3个用户测试点。我们还增加了专门的翻译小组，并用三环活页夹保持测试脚本整齐有序。测试有16名志愿者，而参加测试的用户数量约是上年人数的2倍，95人。

这一年的用户测试比上一年的更成功。我们在用户测试后当即进行了分析，所以比上一年更快得到有价值的数据。

但我们并没有将这次研究的结果运用到下一版本的迭代中。直到数月之后，我们才这样做，方向正确，但由于落实的太慢而算不上敏捷。

 

我们从中获得/学到了什么？

在2012年的测试中，我们犯了很多错，也获得很多宝贵的经验。这使得我们在2013年改进了研究设计和测试过程，从而在测试的质量和数量上都更上一层楼。所以，别害怕失败。失败的用户测试起码能帮助你在下次提高。

这里是我的一些观察和体验：

会议有助于减轻用户招募的压力

用户招募非常耗时。在Puppet大会期间，我们的研究团队为了招募用户而设置了全天候的用户测试点。参会人员准备好演讲，也愿意参与你的测试。你需要做的就是一直在测试点等待

在常规的用户招募中，我们给用户池中的50-100人发送招募邮件。大多数人都不会回复，而回复邮件的人中，只有少部分符合测试条件的用户。不仅筛选出有效的用户需要花些时间，而且有时候用户数量不够，我们还必须继续“广撒网”，这就需要花更多的时间。

行业会议能让你的用户测试更有效率

在这两年的行业会议上，比起测试结果，我们对测试本身更感兴趣。2013年，我们对95名用户进行了用户测试，这远远超过了我们的研究需要。

如果你决定要进行自主、可量化的可用性测试，你甚至可以对更多的用户进行测试。2014年，我们的研究团队对超过200名的用户进行了一对一的可用性测试

环境嘈杂，但测试过程应当有序

2012年，我们将测试操作区分为4个流程：问候、招募、测试和感谢

1. 问候
   每个走到测试点的与会者，我们都会有一个负责问候的志愿者上前打招呼，并介绍我们的测试。
2. 招募
   接着，我们会问他，是否愿意尝试作为我们的一名调研对象，在需要进行用户测试的时候联系到他。获得同意后，我们会记录他的资料。
3. 测试
   如果我们当即能进行测试，我们会问询用户是否你愿意花15-20分钟参加一次用户测试。如果得到肯定答复，负责接待的志愿者会把用户介绍给测试点里的测试人员。
4. 表示感谢
   在测试结束后，我们会真诚的感谢每一名参与用户，并赠送一件限量版的T恤和一本大会的纪念册作为答谢礼。

这一测试流程通常能运行顺畅，但仍存在两个明显的漏洞：首先，我们没有良好的用户筛选程序，所以我们没法保证测试参与者都是符合测试标准的用户；第二，我们并没有完善的计划，以便迅速获得测试结果并运动到设计中。

2013年，我们对此进行了相应的改进，增加了2个步骤：问候、招募、筛选、测试、感谢和分析

1. 筛选
   测试开始之前，测试人员会问每个参与者6个问题。如果回答是肯定的，我们知道这个用户是符合测试条件的。
2. 分析
   在用户测试结束后，主持人需要填一份简表。表格按照不同研究假设区分不同维度而设计。每个用户的测试被填写在一个空格里，旁边注明了研究的假设。主持人填写相应记录，并标记假设的有效性结果。

 

行业会议测试使得竞争对手能够窥探你，所以你要防范

我们用NDAs来应对。意向不到的效果是，这使得测试更独具意义，所以大家都希望参加。

2013年，我们用DocuSign（在互联网上审核认证用户的数字签名，从而帮用户实现文件的自动化管理的产品），将测试形式从纸质换成了电子表格。从便捷度来看，这是一个很大的进步。我们不用在会议结束后拿着一大摞测试结果的纸质记录那么麻烦；另一方面，省去了繁杂的签字工作流程。人们只需要确认自己姓氏三次，然后在NDA上进行点击和选择即可。

 

行业会议中进行用户测试是理解用户的绝佳途径

终极角度看，用户测试关注的是人，而非测试本身。在会议上，我们的志愿者都不是用户体验部门的员工：开发、产品、市场和销售人员。这是个让这些员工了解真实环境中用户的问题和感受的绝佳机会。

这也是双向的。人们喜欢谈论他们的工作、痛点，以及你的产品或服务在缓解痛点方面做得不够的地方。当然，这些零星的数据对设计的作用并不是非常大，但它能帮你有效的建立真实情境中的用户心智模型。

 

行业会议+用户测试的组合很靠谱

正如我所提到的，我们的志愿者是公司里其他部门的员工。在此之前，大部分志愿都从没有参与过用户测试。对这些人来说，用户测试着实需要伤些脑筋。

2013年，我们进行了一系列内部培训以使得这些志愿者能对更加快速地上手进行测试。

在第一次培训会议中，我们将所有志愿者集中在一个房间中，介绍和讨论了如何组织高水平标准的测试程序。然后，我们将志愿者分为2-3人一组，交替扮演主持人和参与者，真实模拟测试环境。测试组织者也参与其中，以发现需要改进或澄清的地方。

如果发现有志愿者仍担心没有掌握用户测试的方法，我们会单独的约见他。在某些情况下，我们会说服或鼓励他们，使之相信自己能够推动并指导用户测试。或者在某些情况下，我们使之担当要求较低的角色（通常是接待/问候人员）。

 

会议也会是数据收集的黑洞

第一年， 1台测试用的笔记本电脑（共3台）“神秘”地丢失了用户数据；第二年，2台笔记本电脑被盗，这使得我们丢失了这些电脑里的所有数据。

2013年，云存储为用户分析提供了新的希望。因为我们测试人员都按照测试过程进行了严格的记录，并将之同步到云端，所以我们能够保存数据，即使我们丢失了用户录音的文件也能进行用户分析。

 

流程为王，但有序的组织也很重要

记录电子化是非常有用的。如果你需要使用纸张，不要使用牛皮纸袋，使用三环活页夹更利于你的资料收集。

电子记录时，请将所有会议测试相关的文档和数据放到同一个文件夹中。可以使用DropBox或者Box这样的工具来同步各个设备保存的数据。保存到本地也是很重要的一步，以免网络崩溃时无数据可用。

 

在回顾中学习和提高

会议结束后，与用户测试的核心成员一起开个总结会。在最初的5-10分钟，每个人在便签上写下自己认为需要停滞、保持和想尝试的事情。之后，将所有的人的便签贴在黑板上，便签被分为三组（需保持、停止、可尝试）

一旦每个人都提出自己的想法后，选出一名志愿者来将所有人的便签按照不同主题分组，如沟通、过程、人。理想情况下，这些便签能被归为3-5组。然后一组组地，依次找出每一组可行的改善方法，最后将每个行动项指定给团队里的相应成员负责。

 

应该把行业会议加入你的工具箱吗？

没有一个用户测试工具或者技术是万能的，基于会议的用户测试也不例外。在做了几次行业会议的用户测试后，我们可以总结出其优缺点。

优点

• 不愁参与者
  一般一个小型会议会有百名的与会者，中型会议有千人，大型会议常有数万人。根据你的测试目的，按需取材。
• 招募便捷
  建立一个测试点，用户就会来。将测试的笔记本电脑放到房间中，并在屏幕上清晰地展示测试流程将会非常有帮助。
• 便于快速迭代
  你能轻而易举的在1-2个小时内完成5-6名用户的测试。如果你有多个测试点，这个速度将会更快

缺点

• 测试环境嘈杂
  知道那些拥有单向玻璃，环境安静的可用性测试房间吗？这在会场里是无法找到这些的。
• 需要出差
  除非你足够幸运，所在的城市正好开了一个相关的行业会议，不然进行这样的用户测试你很可能需要去外地出差。这个花销可不小。
• 难以规划
  还记得之前提到是产品路线图吗？如果设计阶段无法赶上会议时间测试（时间不凑钱），就需要你另寻方法来满足研究需要。

一般来说，这个方法在你对产品的发展规划具有计划性时，是可行的。如果你知道开发产品的计划，你就能好好规划设计时间，来匹配一个或多个会议测试。

另一方面，如果你需要即刻进行灵活的用户测试，这个方法就行不通。这种情况下，我建议你在公司内部建立专门的用户测试室，测试室中放置所有你需要的实验设备。

 

一些小贴士

如果你读到这里，并认为基于会议的用户测试对你来说非常可行，那非常好！这些小贴士将有助于用户测试的成功。

• 提前5个月选择一个合适的行业会议
  此时，你并不用详细制定所有的测试计划，但有一个目标日期和地点，有助于开始思考这个测试。
• 选择一个大家对你都不熟悉的大会
  我们曾经在一个自己举办的会议上进行过用户测试，每个参加会议的人都知道我们公司。这种自我选择的偏见使得我们无法获得潜在市场里的交叉样本。
• 不要在人流量最大的走廊设置测试点
  能见度最高是个诱人的因素，但要想清楚是否能负担起嘈杂的代价。2013年，我们测试的房间与人流量最大的走廊有半墙之隔。这样，我们的测试点很容易被参加者发现，同时又避免了过于嘈杂。 
• 不要独自设计每一个研究
  第一年，我自己设计了4-5个用户测试方案。结果，执行者都反应很难明白测试用意，最终也没得到有意义的数据。写出一个既能验证研究假设，又便于操作的用户测试方案，是非常耗时的。
• 不要安排参与者等待
  当你的测试点挤满了人时，请不要试图让人们排队等待。请以已登记的用户记录表为准，驱散多余的人，即时测试点在某些时候会空荡荡的。
• 会议前，在每台机器上测试，以防万一。墨菲定律，你懂的，不需要我反复提醒了吧？
• 向前看，只管去测试
  比体验一次失败的用户测试更差劲的就是，什么也没做。如果你失败了，起码下次你知道怎么做的更好。如果你什么也没有做，你也将一无所获。

 

译者：吴姝欣；审校：李福东；发布日期：November 5th, 2014

原文作者：Daniel Sauble

原文链接：http://www.smashingmagazine.com/2014/11/05/how-to-run-user-tests-at-a-conference/

顶部图片来源：http://media.mediatemple.netdna-cdn.com

版权所有：UXRen翻译组 （转载请注明出处！）