编辑导读：可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。本文作者从远程可用性测试的概念出发，结合案例分享了创建一个有效的远程可用性测试的具体流程和相关技巧，供大家一起参考和学习。

现在大部分用研的小伙伴，每一次做可用性测试都需要邀请参与者在现场完成任务，观察并注意他们的行为，然后总结得出结论。没有远程进行可用性测试，因为在底层认知内是必须在同一个房间做任何类型的用户体验研究才能获得数据。

现在国外和国内大厂的远程可用性测试就是很普遍化了。那么我们该怎么找到适合现状的远程可用性测试呢。

一、什么是远程可用性测试？

远程可用性测试是指参与者和研究人员在不同地点进行的测试。随着技术创新的推进，远程测试在实践中有所增加，在线工具也为远程测试提供了便利。会话通常通过可用性测试平台进行（不打广告，自行百度），它记录完成测试的人员，收集数据，并生成报告。

远程可用性测试的好处：

1. 可以更好地找到参与者，因为他们可以不用坐着公交来到公司进行参与，参与者可以在任何他们想要的时间以及他们想要的地方进行测试。
2. 有足够的定量数据支撑
3. 创建测试和获得结果之间的时间要短得多，可以非常快速地获得数据驱动。
4. 开销-为公司节约成本。不需要包路费或者足够的送礼品。远程发个红包，也能表达感谢之情。

远程可用性测试的缺点：

1. 总体测试环境和过程的控制较少。例如，如果任务不清楚，就不能在那里更详细地解释它，并将其引导正确的方向。
2. 解决方案：为了最小化这些风险，在测试开始时介绍性的讲述缘由，以便参与者知道将要发生什么，也请告知参与者测试的目标，并确保他们掌握了所有必要的信息来理解所参与的内容。
3. 远程测试进行试验需要确保编写任务的方式非常清晰。
4. 远程可用性测试并不比面对面的测试工作量少。它通常需要更多的计划和更多的交流。因此，要做好相应的计划，确保你要使用的工具和设备工作正常。
5. 需要给某些可用性测试平台付费

彩蛋：共享屏幕的进行操作，然后你录屏。嘿嘿，曾经我就是这么做的。后来我们公司，受不了大型的视频文件了，决定自己开发一个系统。

二、进行远程可用性测试的最佳时间是什么时候?

是在设计过程中的任何时候。只要第一步任务的编写完成了，那么远程测试比现场测试进行起来更快更容易，因为可以无限的复用。

对于，某些公司缺少启动资金，又想做的专业，那你就需要试试我的建议了。可以确保您的迭代始终得到数据的支持。或者不甘于在做画图仔的小伙伴，可以试着推动一下。

1. 你只需要做到编写任务，确保任务流程非常清晰后。
2. 召集你的调研对象
3. 发送链接（怎么让用户点击产生时间不用我说了吧）
4. 完成录屏
5. 分析记录的数据
6. 以及谢场

三、创建一个有效的远程可用性测试的5个技巧

要真正看到远程可用性测试的好处，您必须以一种能够获得可操作结果的方式来设置您的测试。远程测试并不意味着更少的准备或计划。相反，它要求以最好的方式设置测试，以获得有效的结果，从而帮助您学习并根据收集到的数据采取行动。

1. 选择正确的测试类型

远程可用性测试有两种类型:中度测试和非中度测试。

除了主持人和用户不在一个房间之外，主持测试的工作原理与传统的现场可用性测试基本相同。主持人需要用到腾讯会议这样的软件去观察视频通话中的用户。

这样做的好处是：仍然可以向用户询问尽可能多的后续问题，此外，用户也不需要长途跋涉到公司参与。（像我们公司做B端产品的，运营分布上海、重庆、合肥。你说香不香。）

缺点是：它仍然需要参与者在一定程度上的投入——他们必须在特定的时间使用特定的设置来完成测试，而额外的交流使得整个测试过程更加耗时。所以就看你在开局时能不能编写好剧本了。

要点：

对于更传统的可用性测试过程，可以使用温和的远程测试；对于资金不足的、想专业性的、定量的、节省时间的方法，可以采纳远程可用性测试。

2. 缩小你的范围

测试的范围可以决定它成功的机会，也可以决定它失败的机会。很显然，我们大家都需要在某个时候对产品的每一处的功能都要进行测试。但是对于远程测试，最好采用测试特定的流程，而不是把所有东西都放在一个大型测试中。

这有几个原因：

首先，把你的测试集中在几个假设上，不管怎样都会使你的结果更加清晰。一次测试的设计越多，测试的时间就越长，结果也就越模糊。耐心嘛，总归是有限的。

我们应该给参与者更少的选择，这样可以精确地确定设计决策并更严格地测试它们。

第二，测试越短，用户越有可能完成它。还是那句话，注意力也是有限的。

因为我们无法在现场指导他们的方向（远程沟通的弊端）。如果他们不能坚持到最后，你将会得到扭曲的结果。

我的建议：是将任务分成七到八个小任务的远程可用性测试。

• 好的方面是：可以更频繁地运行小型测试。
• 弊端就是：你需要做的复杂一点了。

中度测试：可能稍微复杂一点，因为你可以就参与者发现的问题进行完整的对话，并对他们是如何陷入困境的来做笔记。由于这些测试需要更多的时间来安排，你可能需要更深入地挖掘以最大限度地利用每一个测试。（在远程可用性测试方面，我不大推荐这么做。）

要点：

为了获得更清晰的数据模式、也为了确保人们完成。远程测试不应该超过七到八个子任务。非中度远程测试可能没有那么集中，但同样的原则也适用。

3. 尽快开始寻找参与者

为什么说到尽快呢？因为最根本的就是防止自己出错！及时止损！

请记住，远程可用性测试的主要好处之一是能够使用大样本进行测试。所以你能找到的用户越多越好。（建议：寻找具有特定背景或职位的用户）因为远程测试是属于定量的。（现场可用性测试的话会更加偏向于定性）别再搞混了，在搞混直接打死！

如何找：

1. C端，很常见的就是从运营手里找用户，或者从反馈问题的页面找到联系人。C端找人太简单了。我就很喜欢去反馈。
2. B端，这个就要分业务场景了，是包装后准备售卖还是以代运营的方式。自己公司就好说，代运营得从业务部门沟通开始安排时间。
3. 搭建访谈记录池

要点：

准备充分！及时止损！寻找特定背景/职位用户！

4. 创建任务

当您为远程可用性测试创建任务时，清晰是非常重要的。写得好的和结构化的可用性任务会给你带来更准确的结果。

要点：

• 确保目标的一致性：你想到的产品使用目标和用户在使用你的产品时所想到的目标是一样的。
• 提供产品背景：提前告诉参与者这个测试——它是针对什么项目的，你想要的数据类型以及设计，而不是他们自己。这会帮助他们理解你要求他们做的事情。
• 从简单的开始：通过简单的开始任务给人们一个机会来适应测试过程和产品。
• 使用简洁的语言：避免使用内部术语或技术术语，因为它们可能会使人困惑。找个文化水平好一点的大师，让他们教教你。哈哈哈，我经常被吐槽。
• 专注于一件事：想让用户在完成一件事之前一定要专注现在的事情。这将防止他们不知所措，并帮助您精确定位数据中的设计缺陷。
• 遵循流程：请按照产品中的常见、常规的操作流程去进行测试，这样测试数据就更加真实。
• 不要透露答案：给人们情景，而不是方向。

“你找到这个列表，点击这个编辑，然后填写数据，最后点击完成”兄弟们千万不要这么做啊！！！这个过程太精确了——可用性测试的目标是看看人们是否可以在不提醒的情况下完成你的产品的实际任务。

要点：

如何编写和组织任务将在很大程度上决定远程可用性测试的成功与否。根据用户的目标使用简单的语言，避免让任务太复杂或太明显。

5. 问一些有效的问题来获得更丰富的见解

提问是在远程可用性测试中获得更多反馈的一种方式。

在每项任务结束后跟踪参与者，了解他们对具体设计元素的看法，或在测试结束时提出一般性问题，以获得定性反馈。因为你需要为远程测试提前写好问题，所以它们需要是完美的。这里有一些建议:

把开放式的问题留到最后，询问某人的整体经历可以让你得到详细、定性的回答。

下面是一些我会经常问到的可用性测试问题的例子:

1. 你完成这项任务后的感觉如何?
2. 你觉得这个设计总体上怎么样?
3. 您如何看待信息和特征的布局?

最后在拼死压榨一下，填写一下系统可用性度量表(SUS)的问题。这是一个经过测试的可用性调查，经常被用来衡量产品的可用性。SUS甚至会在最后给你的产品一个可用性评分。

计算评分如下：计算SUS得分的第一步是确定每道题的转化分值，范围在0-4。对于正面题（奇数题），转化分值是量表原始分减去1（X-1），对于反面题（偶数题），转化分值是5减去原始分（5-X）。所有题项的转化分值相加后乘以2.5得到SUS量表的总分。所以SUS分值范围在0-100，以2.5分为增量。

你也可以问一些人口统计问题来根据年龄、职业、教育等对用户进行细分。这对于发现不同人群的可用性趋势很有用。隐私就别问了啊。

要点：

措辞精准、请反复核对。

四、结合Think aloud

完成可用性测试（这一点是根据一位不知名的网友提供的。虽然他单词拼错了，哈哈哈可我还是依然给他置顶了评论)。

Think aloud释义：

Think aloud 是可用性测试中常用的一种方法，它是由IBM公司Clayton Lewis 在1982年在 《以任务为中心的界面设计》书中被阐述，同时引进到了可用性领域，1993年由前苹果研究院VP的Jakob Neilson在可用性工程这本书中再次推出。

使用 Think aloud方法，需要提供给被测用户待测的产品或界面原型，要求被测用户根据指定任务操作产品或界面，与此同时，即时地说出使用产品界面时的想法、感受和意见。

Think aloud适合在产品设计的任何阶段使用，并且适用于各种形式的产品原型，对于用户路径，界面信息构架，误操评估等有快速有效的校验作用。

我在以往做可用性测试的时候，往往会忽视了参与者的即时感受。除非他自言自语，我找不到这个功能在哪了，那会儿我才反应到他为什么出现认知错误了。现在经过他的留言，我才反思到是我过度的专注于实操和他的表情了。希望小伙伴们要注意哦~

作者：交互思维铺子；公众号：交互思维铺子

本文由 @交互思维铺子 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。