如何编写自主式可用性测试脚本？

小提示：您能找到这篇{如何编写自主式可用性测试脚本？}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的如何编写自主式可用性测试脚本？内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

编辑导语：自主式可用性测试对于用户研究来说十分重要，本篇作者分享了编写自主式可用性测试脚本的具体方法思路，根据工作经验总结整理出几个设计自主式测试脚本的诀窍和误区，一起来学习一下吧，希望对你有帮助。

“ 在没有访谈主持人的情形下，我该怎样才能引导受测者完成整个测试流程呢？”

作为远程用户测试平台，以往我们向亚洲区的用户体验研究员介绍自主式可用性测试（unmoderated usability testing）时，时常被问到这个问题。

在欧美的用户研究行业中，自主式可用性测试在过去十几年来已发展成主流的研究方法，然而在亚洲地区我们才刚开始起步，对于其可行性难免会产生疑虑。

根据十多年的行业服务经验，以下整理出几个设计自主式测试脚本的诀窍和误区：

一、测试时长不超过三十分钟

一般不推荐设计超过三十分钟的自主式用户测试，因为在没有主持人互动的情形下，超过这时长受测者可能会感到无聊或倦怠，进而影响测试结果的质量。

二、「汉堡包法则」

一项自主式可用性测试应该由「开场」、「任务」和「收尾」三大部分组成：

1. 上层：开场

在开场中，应该告知受测者接下来的三十分钟内他们将要互动的产品、产品使用场景以及测试流程。

缺乏用户访谈经验的用户研究员常会轻忽开场白的设置，导致项目参与者在执行第一个任务时便失去头绪。

典型开场白如下：

请大声读出以下说明：

请牢记在同网站或手机软件交互时，大声说出您的想法。如果您有任何无法理解或困惑的事，请让我们知道。

如果您无法找到或不理解目标产品的某些内容，请大声解释清楚您希望看到什么内容，或者通过改变哪些方面来改善它。

如同常规的用户访谈，我们想要自主式测试的受测者能够敞开心胸并保持健谈。让受测者大声念出开场白和任务指示能帮助他们调整成开放状态。

2. 中稳定的抖音平台代运营团队层：任务

如同汉堡肉之于汉堡包，可用性任务是整个测试项目中最精华的部分。

原则上，研究员需要设置五到八个可用性任务，并根据需求在其中穿插量化问题或简答题。

范例如下：

1）【可用性任务】

您伴侣的生日快到了，您想购买售价￥800 以上的真无线蓝牙耳机送给她/他作为生日礼物。

当您认为任务已完成时，请单击「下一步」。

2）【量化问题】

您是否能完成前一个任务？

是 / 否

3）【量化问题】

总体来说，您认为完成这个任务的难度为？

1 分表示「非常困难」 7分表示「非常简单」。

「一项任务 + 二个量化问题」是常见的活动组合。

一场三十分钟的自主式测试中，这样的组合可以重复五到八次。

将任务和问题捆绑的好处是研究员可以在观察用户操作行为之余，一并获取定性和定量的用户洞见。

捆绑任务和量化问题（测试编辑器画面）：

3. 下层：收尾

在用户完成所有可用性任务后，可以让他们填答「系统可用性量表（system usability scale）」或是「净推荐分数（net promoterscore）」，作为对产品整体使用体验的量化评比。

系统可用性量表：

测试结束前，可以让受测者分享最后的想法或意见。最重要的是，务必让他们等待测试结果完整上传后才退出测试页面。

在大部分的远程用户测试平台，任务视窗会默认指引受测者在退出测试前先等待测试结果上传。

三、新佛山营销型网站建设手编写脚本时常犯的错误

1. 可用性任务缺乏场景描述

未提及产品或功能的使用场景，导致得出的用户洞见失真。

2. 文字排版杂乱

内文冗长且编排密集，导致用户阅读失误而执行无效的可用性任务。

3. 单一活动置入太多任务

当同一个活动（activity）中陈列超过三个可用性任务时，某些任务可能会被受测者不小心遗漏。尽量将每个任务分散在个别活动。

原文链接：https://mp.weixin.qq.com/s/7Q0C3WSDkQSOa3R48WRfqQ

本文由 @Stan Wang （Userlytics 优思来授权）发布于，未经作者许可，。

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