移动可用性测试(四):远程测试
移动可用性测试(四):远程测试-移动阅读二维码

4

实际工作中,虽然远程测试用得更少,但它确实能解决一些现场测试无法解决的问题。比如在当地无法找到目标用户时,远程测试相对出差是更为廉价可行的做法。或者当需要大量的样本时(现场测试因为时间空间的限制,只能做小样本测试),无主持的远程测试可以完成大样本的测试。此外远程测试相比现场测试,情境还原度更高,更能还原用户真实场景。

1 远程测试的类型和选择

通常来说,远程可用性测试按是否有主持人分为两种类型。一种是有主持的远程测试(Moderated Remote Testing),研究人员需要和被试者通过远程设备连接起来,使得不在同一地点的两方能同时处于同一个“真实”的空间中,研究人员可以通过远程观察设备完整地观察到用户的操作行为,同时能在测试过程中与被试者进行实时的在线交流。另一种是无主持的远程测试(Unmoderated Remote Testing),被试者根据研究人员的要求,按照自己的时间计划完成测试,并对自己的操作全程进行记录。测试过程中,研究人员并不进行干预与互动,所有的分析工作都在测试完成之后进行。

移动可用性测试(四):远程测试

两种类型的远程测试各有千秋,研究人员需要根据项目具体情况进行谨慎地选择。可以从以下几个方面考虑。

  • 项目时间安排和样本量要求

有主持的远程测试,由于需要主持人的参与,一定程度上限制了同时进行测试的数量,测试阶段需要花费的时间较长。而无主持的远程测试能够同时进行多个测试,能在有限的时间内用较低的花费收集大量的数据。所以当需要大样本量的时候,应该采用无主持远程测试。但因测试过程中完全不参与,后期数据分析工作量较大,需要花费较长时间。

  • 任务设置要求

对于有主持的远程测试而言,所有的交流都是实时的。在测试过程中研究的人员有不清楚的地方,可以向被试者进一步的追问,了解被试者行为背后的原因,所以这类测试对那些任务更为复杂的测试更有效。而在无主持的远程测试中,被试者全程独立完成测试,这就要求测试的任务描述需要清楚直接,有明确的结束状态。被试者独立完成任务时,注意力的集中程度有限,通常无法保证长时间高质量地完成任务,有专家建议无主持的远程测试应控制在15-30分钟左右,包含3-5个任务为宜。

  • 被测对象的稳定性要求

无主持的远程测试没有研究人员的干预,被试者过程中过程中遇到任何问题都没办法得到及时的解决。因此,这要求被测的原型或产品的稳定性非常高。一旦产品出现问题,很可能被试者就无法把测试进行下去。并且原型或产品需要对被测者的操作行为作出反应,让被试者明确判断出自己是否完成了任务,是否可以进入下一个阶段。

2 远程移动可用性测试的难点和弊端

做移动可用性测试时,远程方式虽然可以覆盖更多样本类型和样本量,还原用户情境。但也存在存在以下难点和弊端。

  • 互动减少,信息不足

远程测试由于研究人员和被试者在不同的空间,两者无法直接互动。有主持的远程测试中,研究人员无法直接观察到被试者的身体语言和场外信息,提高了沟通成本。无主持的远程测试中,被试者的行为完全是独立的,研究人员基于测试后分析,对于行为背后的原因难以获得。

  • 测试环境不可控

远程测试过程中,我们无法控制被试者的测试环境,被试者很可能被电话、突然的到访者等打扰。这既是远程测试的优势,可以还原被试者的现实情境,但也是劣势,被试者很可能就此中断任务甚至放弃任务。

  • 被试者网络环境影响(有主持)

远程测试需要通过屏幕的共享以及图像的录制来进行数据的收集,虽然现在的网络越来越发达,但是难免受用户当地网络环境的影响。

  • 任务理解偏差(无主持)

无主持的远程测试中,被试者对任务理解有偏差,可能就会导致大量数据失效。建议任务设置明确,同时标明研究人员联系方式,以便能够被联系到。

  • 被试者态度难以甄别(无主持)

无主持的远程测试中,更大的风险在于一些无效数据。如用户敷衍完成任务,我们很难甄别。因此,在招募用户时,需要确定对方是否配合、对产品感兴趣。计划测试时就需要考虑如何定义数据的有效性,以及如何对数据进行有效筛选。

  • 测试工具限制

远程可用性测试,对测试工具的要求更高,工具限制会成为很重要的限制因素,下面工具部分会详细展开。

3 远程移动测试的原型制作和发布

项目早期移动测试原型制作,依然可以采用第一篇介绍的工具Prott。原型制作的部分需要强调的是,因为远程测试更不可控,所以对原型的保真度要求更高,特别是对功能及跳转的完整性上。

原型制作完成之后,远程发布给用户也非常简单,不需要用户安装任何App。用户研究员在Prott项目界面点击分享按钮,在弹出界面中选择Send email。用户收到邮件之后,在浏览器中打开链接,按照提示把快捷方式添加到首页,之后就可以类似原生App的方式进行测试了。

移动可用性测试(四):远程测试

对于项目后期的测试来说,一般做法是内嵌SDK到代码到程序中,所以不存在制作原型的问题。

4 移动远程测试(有主持人)的平台选择

做现场测试的时候,我们面临的平台选择是,iOS还是Android。最终会依据“产品用户平台分布”,“测试工具限制”来决定平台选择。然而在远程测试中,因为工具限制太大,所以我们必须优先考虑工具的限制,然后再考虑用户分布情况。比如iOS平台在远程测试中,将面临以下问题:

  • iOS的远程测试,基于QuickTime的解决方案,用户必须使用OSX操作系统
  • iOS的远程测试,无法看到和记录用户手势

在iOS的远程测试中,我们需要先让用户将手机屏幕投影到PC/Mac上,再通过远程屏幕共享软件,将屏幕同步到观察人员面前。而Mac在桌面操作系统的占比太低,使得我们很难募集到足够的Mac用户参与远程测试。PC平台的镜像App延迟都比较严重。另外苹果的安全限制使得手势无法被观察和记录,也让观察效率大大降低。

这些限制使得iOS的远程测试困难重重,所以我们建议iOS平台产品尽量做现场测试。Android平台产品或者全平台覆盖产品的有主持人的远程测试,可以通过下面的工具来实现。

5 移动远程测试(有主持人)的可用性测试工具

有主持的远程移动可用性测试中,研究人员需要利用工具解决两个主要问题:

  • 实时看到用户的手机界面(包括手势)
  • 与用户实时交流

实时看到用户的手机界面,可以利用上篇中提到的工具AirDroid/Mobizen,通过Wifi同步用户的屏幕和手势。以AirDroid举例,在开始测试前,需要让用户预装AirDroid,登录指定账号,并打开系统设置里的“显示屏幕触摸”。

远程与用户实时交流,国外一般会推荐网络会议工具,但是这些工具都太复杂了,需要很高的教育用户成本和预装成本。推荐使用QQ的免费视频功能就好。最后用本地的录屏软件做记录QQ视频和AirDroid的窗口就可以了。下图是我们的测试结果,左侧是AirDroid屏幕镜像窗口,可以看到用户手势,右侧是QQ视频窗口。

移动可用性测试(四):远程测试

虽然AirDroid/Mobizen已经是比较好的基于无线网络的解决方案,但无线网络环境太复杂,实际测试中,AirDroid/Mobizen依然会出现卡顿的情况。所以另一种解决方案是,让用户通过Mobizen先把手机屏幕同步到用户PC上,再通过QQ屏幕分享给用户研究人员。

6 移动远程测试(无主持人)的工具比较

无主持的远程移动可用性测试,主要用于收集用户在移动设备上的定量行为数据,以及定性的操作视频。因为是被试者远程自主进行,也没有研究人员进行指引,所以相应的测试指引和数据收集都需要依靠工具。这就需要专门的移动测试应用具备以下几个主要功能:

  • 可以预设测试任务指引
  • 可以记录用户操作数据(任务时间、用户手势等)
  • 可以录制用户操作视频
  • 提供测试后问卷以获取用户的主观反馈和信息
  • 分析记录数据(如通过事件追踪视频相应位置等)

目前已知的可用于移动远程测试的工具,并没有完美地兼具以上功能。我们对下表的工具做了简单的对比测试(Reflector,GoToMeeting,Magitest,UXrecorder,UserZoom,Userlytics,Appsee),发现大部分工具都有这样或那样明显的局限性,无法运用于实际测试中,现状令人十分沮丧。最后选择Appsee作为重点体验对象,下面详细分析。

移动可用性测试(四):远程测试

7 Appsee体验

Appsee提供了数据分析功能和用户操作录屏。数据分析功能帮助设计师了解宏观层面的整体使用情况;用户的操作录屏数据,有利于在微观层面,对用户使用问题作进一步定性分析。为了能更深入的了解这个工具,我们在Lightalk app里部署了Appsee,以下是我们在真实使用环境下收集到的数据。

Appsee保存了用户操作录屏的数据,以非常友好的方式将数据展示出来。右侧的时间线清晰的标识出用户的点击及手势操作,你能快速定位到某个你感兴趣的视频片段上。下图展示了其中一个用户在注册Lightalk时设置头像的操作过程,我们在其中发现了有趣的细节,用户首选通过“自拍”的方式来设置头像,然后又取消了此操作。由此我们推断出“自拍”功能的设计没能满足该用户的预期,可能是因为缺乏好看的滤镜效果。通过分析视频,我们能在细节上揣摩每个用户的操作行为,更好的了解他们的预期和心理。 Appsee还对用户进行了分类,分为新用户(First Sessions)、回归用户(Returning Users)、忠诚用户(Royal users)、流失用户(Quick Abandons)、短期停留(Short Sessions)、长期停留(Long Sessions)。

移动可用性测试(四):远程测试

Appsee分析了App的常用页面,统计了每个页面的平均停留时间及交互的情况。你能看到用户在这些页面里执行的主要操作及频率对比,还给出每个页面的上下级页面。如下图所示,我们能看到在Lightalk的通话tab上,80%的用户会选择最近联系人发起通话,20%的用户通过搜索找到目标对象。

移动可用性测试(四):远程测试

基于预先设定的页面跳转路径,Appsee能追踪用户在执行这些路径时的具体情况。你能观察到有多少比例的用户顺利完成了整个流程,有多少比例的用户在哪个页面流失。

移动可用性测试(四):远程测试

为了获取App的使用数据,开发人员需要在App里嵌入Appsee的SDK,花费几小时完成部署工作。iOS、 Android两个平台需要分开部署。Appsee的收费方式是基于App的,针对不用用户规模的App,Appsee定价也会有差异。具体的费用需要与他们的团队通过邮件或Skype沟通。

Appsee也有它的不足。它生成的数据无法保存或导出,只能通过它自己的网站查看,不适用于保密项目。它目前只支持App,不支持Web的可用性测试。Appsee的收费方式有一定的局限性,对于新孵化的项目,要专门为它购买整套服务显然不现实,成本太高。个人认为Appsee更适用于已积累了一定用户量的应用,例如QQ、微信这种。

总体来说,Appsee是笔者认为目前做得最完善的移动可用性测试工具。它能保存用户操作录屏,真实地还原了用户的使用场景。提供的页面分析视图、路径分析视图,非常实用,帮助设计师迅速了解到App关键界面的使用情况。

8 总结

从流程方法上来说,移动可用性测试继承了传统可用性测试的主要框架,但是在具体问题上又有不同。借用张小龙的话来说,“手机是肢体的延伸,和人是一体的,而PC是外物,即外部环境。”虽然手机看上去只是屏幕变小了,但实际上意味着手机对用户来说更私密,会在移动中使用手机,会通过传感器和手机交互,设备和平台充满多样性…

本文选择了几个点来阐述移动可用性测试的不同,包括移动平台选择,移动情境,用户设备还是测试设备等。这里应该有更多可以深入思考和挖掘的差异点,希望不只是我们的产品设计思路,我们的用户研究思路也需要跟上移动的脚步。

从移动原型和测试工具上来说,移动可用性测试面临的原型工具转换,观察困难,记录困难,这些问题会更突出一些。然而问题也是机遇,比如通过我们对工具的测试研究,发现通过前置摄像头拍摄用户表情的可行性,使得在不借助外部摄像头的情况下,手机可以完整记录用户所有信息。移动原型工具大爆发,也使得我们有更多选择,更方便的途径来制作和生成移动原型。

然而工具使用的限制依然很多。在现场测试的部分,我们给出了4种情况下,对应的最佳选择;远程测试部分,通过对大量工具的测试比较,我们认为还没有针对所有场景的解,甚至某些场景下,目前所有的工具都还不够理想。但工具也在持续发展,希望后续有更好的工具可以和大家进一步分享。

写这篇文章的初衷,是因为大家都在做移动可用性测试,但国内很少看到全面整体的介绍文章,大量资料都是零散的,缺乏最佳实践。研究过程比较繁琐,需要阅读大量的资料,梳理总结,并对测试工具做逐一测试,归纳出我们认为最行之有效的做法。希望通过我们的工作,给用研和产品设计同学们一个全面的移动可用性测试的参考资料。

希望对大家有帮助,欢迎讨论,并感谢阅读。

附:
移动可用性测试 (一):概述
移动可用性测试 (二): 问题讨论
移动可用性测试(三):现场测试

来自:腾讯ISUX
作者:死猫

本文链接:http://www.mobileui.cn/mobile-usability-test-4.html
本文标签: , , , ,