用户研究甚是有趣,上次专门研究可用性测试是半年之前了。本文将结合自己近期实际工作中的经验,谈谈移动可用性测试,以下为本文涉及到的范围:

A. 什么是可用性测试?

B. 为什么要做可用性测试?(可用性测试意义、目的是什么?)

C. 既然是移动可用测试,这与传统PC端相比有哪些不同?

D. 可用性测试分为几类?应该在项目什么时间节点做?多少人来做?需要做多久?

E. 完整的可用性测试需要经过哪些流程?

F. 简易可用性测试应该怎么做?

G. 需要做哪些前期准备?

H. 现场实际可用性测试具体该怎么做?如何开场白?测试过程中该如何引导?测试者遇到了问题,该怎么引导?

I. 怎么处理测试的结果?

J. 写在最后


A.什么是可用性测试?

要知道什么是可用性测试,先得搞清楚什么是可用性。

A.1 什么是可用性?

可用性是指在特定环境下,产品为特定用户用于特定目的时所具有的有效性、效率和主观满意度。 Nielson认为可用性有5个指标,分别是易学性、易记性、容错性、交互效率和主观满意度。 可用性直接关系着产品是否能够满足用户的功能性需要。如果人们无法使用或者不愿意使用某个功能,那么功能的存在也就没有什么意义了。

A.2 什么是可用性测试?

可用性测试是在产品或者产品设计早期,通过观察或者访谈,发现产品或者原型存在可用性问题,为设计改进提供依据。 可用性测试不是用来评估产品整体的用户体验,主要是发现潜在的误解或功能在使用时存在的错误。

B.为什么要做可用性测试?什么时候做?

B.1 为什么要做可用性测试?意义是什么?

为了要解决这样一个问题:更客观发现产品在早期设计是否存在可用性的问题。在产品开发过程或者完成时发现更多可用性方面的问题,为迭代提供依据。

B.2 什么时候做?

理论上应该在产品整个周期都做,但是不同时期意义不同。

设计早期

当前方案是否有些问题?如果有好几套设计方案,哪种将会最有效? 形成性:多在开发前期。更专注更快速发现和解决问题,及时修复。在设计早期阶段,如果问题发现的越早,就越容易解决,很多软件的问题并不是程序实现的问题,而是设计问题,可用性测试可以将这些问题早早扼杀。早期测试的目的能让你大概了解用户是否理解你的设计,以及哪些用户不能理解。

产品开发过程或完成时(贯穿在除了早期的其他时期)

更了解自己的产品,以及普通用户眼中的产品。发现自己产品的问题,安排几乎解决。 总结性:开发完成后,产品迭代过程中。发现产品现存的可用性问题,通过多个指标评估产品整体体验。

C. 移动端可用性测试与传统PC端相比有哪些不同?

PC,大部分时间都是在相对稳定的环境,比如家里或者办公室或咖啡厅等环境下。移动应用,使用时可用性的感知,跟移动情境有很多关系。

移动情境:使用移动应用和产品时环境和状态。例如导致用户分心的内容、多任务并行的场景、操作时的手势、低电量情况 和 网络连接环境等 都是典型问题。这些构成了移动情境的复杂性。

Harrison et al.建立的移动可用性测试模型PACMAD时,将情境因素引起的认知负担纳入了其中。有三类:

  1. 环境情境 用户所处的环境、文化规范、所正在进行的活动
  2. 任务情境 用户的使用目标、注意力、多任务状态
  3. 设备情境 移动设备本身、网络连接情况、运营商

需要评估移动情境对于本次移动可用性测试的重要性,再来决定移动情境在本次可用性测试中的优先级

  • 根据产品使用环境评估移动情境重要性,比如触宝电话的免费电话更加可能是在室内,但是Uber很可能就是室外。
  • 根据可用性测试目的,考虑移动情境。若是在产品设计初期,仅仅只是低保真原型,对于产品团队更多需要考虑的应该是产品整体层面,比如导航的合理性、页面逻辑关系等,这时候移动情境重要性相对它而言较低。但若是已经在产品后期迭代,则需要考虑更多的细节,所以移动情境就会显得很重要。

D.可用性测试分为几类?多少人来做?需要做多久?测试频率如何?

D.1 分为几类?

有好几种分类方法,分别从不同角度进行分类:

  • 简易(游击式)测试 VS 完整测试

  • 实验室环境测试 VS 真实环境测试

  • 现场测试 VS 远程测试

  • 有主持的测试 VS 无主持测试

D.2 多少人来做?

这其实包括了两个问题,分别是:团队内部需要多少人手来做? 需要多少个tester?

团队内部需要多少人手来做?

如果是在原型早期做,则只用设计人员参与就行。如果只是纸质原型测试,则需要一位设计人员(设计者)作为“电脑”来模拟应用的交互,另一位协作者引导用户、观察、并做一些记录。

如果是产品后期开发迭代阶段,理论上除了设计人员,还需要项目组内其他人员参加,比如开发和测试。实际测试过程中,至少有两位人员,一个负责引导,另一个负责观察和记录。其他人员可以在不干扰tester测试的情况下,在远处观看或者观看实时录像。让开发测试人员尤其是开发人员,参与到可用性的测试过程中,便于他们发现产品存在的问题,在可用性测试结束之后,更加认同可用性测试的结果,从而避免设计团队与开发团队撕逼,更有利于后续执行产品改进。然而在现实工作中,由于开发人员对于可用性测试重视程度未必那么高,所以不一定会分出人手参加可用性测试,所以如果不能involve更多的人进来,尽量需要一个在团队内部很有影响力的开发进来,这样也能保证作用。但是在一些小的开发团队,仍然很难会有开发人员会进来,这样的情况下,需要在最后总结可用性测试的时候,将录像或者记录的结果展示给开发人员。

需要多少个tester?

如果是完整的可用性测试,一次5个人左右就可以了,因为理论上能够发现80%的问题。如果是游击式的可用性测试,2-3个人足矣,就算1个人都能发现一些明显的问题。

D.3 测试频率如何?

理论上需要贯穿到迭代整个过程之中。早期应该将不同的设计方案展示给别人,为决定用哪套方案有很好的参考价值。早期敲定的认为很完美的方案,做一些可用性测试,也能发现一些潜在的问题。现实执行过程中,最好是一周专门花几个小时,做一次可用性测试。

E. 完整的可用性测试需要经过哪些流程?

根据现在产品阶段,确定可用性测试目标 -> 制定可用性测试任务 -> 招募可用性测试tester -> 团队内部培训 -> 布置环境、打印相关材料、设备准备 -> 进行测试 -> 分析测试结果,确定问题优先级 -> 修复问题

F. 简易可用性测试应该怎么做?

只需要5分钟时间,带着纸质原型(或者简易电子稿),设计2-3个核心任务,测试主要功能。其实可以很简单。

G. 要做哪些前期准备?

简易可用性测试

只需要画一个不那么潦草的原型稿,或者静态的原型稿。

完整可用性测试

  1. 导入高保真原型,或者安装开发过程中的产品
  2. 安装录屏软件
  3. 如果有条件,准备一台摄影机,用于录像测试过程
  4. 布置测试环境,能更加模拟实际软件使用过程中的主要场景

H. 实际可用性测试如何开场?测试过程中该如何引导?测试者遇到了问题,该怎么处理?

H.1 如何开场?

开场白需要先跟用户简单聊聊天,让他在这个环境中能够放轻松。接着简单介绍公司、项目组做的产品,和此次测试的目的。最后说几个要点:“我们要测试的是我们的设计,而不是你本人,所以在测试过程中碰到了任何疑惑的问题,反映的都是我们产品的问题”

H.2 测试过程中该如何引导?

有一个重要的原则,即:只告诉tester需要完成的任务目标,而不是告诉他们具体点击哪里。

H.3 测试者遇到了问题,该怎么处理?

如果用户一直无法完成任务,可以考虑给一点点提示点击,也可以当时终止本次任务,并说已经发现了产品存在的问题。如果过了很久用户仍然无法完成,千万不能表现出不耐烦或者沮丧。

根据用户实际进行测试时的表现,来决定是否继续其他任务的测试。

I. 怎么处理测试的结果

测试完成后,团队内部需要当天迅速召开一个会议。与会者除了参加了测试了工作人员,还需要团队内部重要的开发及测试工程师。每个参加测试的人员将测试过程中发现的问题一一罗列陈述出来,这样做的好处:

  1. 帮助其他参加测试人员回忆起当场记录遗漏的内容
  2. 自己整理分析出最严重的问题
  3. 开发人员能够听到最热乎的测试结果,从而更加理解产品存在的问题,便于后期执行修改。

将所有发现的问题罗列出来,以重要性和紧急程度,按照P0-P4确定问题优先级。对于P0-P1的问题,需要立即修复。而对于其他问题,则需要排期修复。

千万不要对于测试结果进行横向比较,也不要对测试结果做任何统计学或形式化的评估。可用性测试提供的是定性的数据,而不是定量的,做形式化分析会产生误导作用,且毫无必要。

千万不要写长篇大论的测试报告。制作报告以及分析问题会花去大量的时间,在现在的敏捷开发团队非常不值得,而且制作的复杂的报告,大家不会花时间去研读。赶快制定问题优先级,更改设计或者修复程序问题更重要。

J. 写在最后

实际在执行过程中,招募测试者通常是个比较麻烦的事情。如果是较为完整的可用性测试,论坛发布消息、网页刊登招募消息、或者通过求助于公司HR都是很有效的方法。对于简易可用性测试,先找朋友、家人测试都可以。经验证明,即使同一个公司的人,如果不属于同一项目组,通常对于产品尤其是新功能的认知也较低,也可用来做可用性测试。

简易可用性测试,其实可以随时随地,打游击式的好处在于几乎不需要准备,随时随地都能上。比如:有一次我在地铁上,发现坐在我旁边有两个台湾人,我就找他们试试我们的注音输入法,短短几分钟,发现了我们键盘某个按键的微小问题。