用户研究甚是有趣,上次专门研究可用性测试是半年之前了。本文将结合自己近期实际工作中的经验,谈谈移动可用性测试,以下为本文涉及到的范围:
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时,将情境因素引起的认知负担纳入了其中。有三类:
- 环境情境 用户所处的环境、文化规范、所正在进行的活动
- 任务情境 用户的使用目标、注意力、多任务状态
- 设备情境 移动设备本身、网络连接情况、运营商
需要评估移动情境对于本次移动可用性测试的重要性,再来决定移动情境在本次可用性测试中的优先级
- 根据产品使用环境评估移动情境重要性,比如触宝电话的免费电话更加可能是在室内,但是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. 要做哪些前期准备?
简易可用性测试
只需要画一个不那么潦草的原型稿,或者静态的原型稿。
完整可用性测试
- 导入高保真原型,或者安装开发过程中的产品
- 安装录屏软件
- 如果有条件,准备一台摄影机,用于录像测试过程
- 布置测试环境,能更加模拟实际软件使用过程中的主要场景
H. 实际可用性测试如何开场?测试过程中该如何引导?测试者遇到了问题,该怎么处理?
H.1 如何开场?
开场白需要先跟用户简单聊聊天,让他在这个环境中能够放轻松。接着简单介绍公司、项目组做的产品,和此次测试的目的。最后说几个要点:“我们要测试的是我们的设计,而不是你本人,所以在测试过程中碰到了任何疑惑的问题,反映的都是我们产品的问题”
H.2 测试过程中该如何引导?
有一个重要的原则,即:只告诉tester需要完成的任务目标,而不是告诉他们具体点击哪里。
H.3 测试者遇到了问题,该怎么处理?
如果用户一直无法完成任务,可以考虑给一点点提示点击,也可以当时终止本次任务,并说已经发现了产品存在的问题。如果过了很久用户仍然无法完成,千万不能表现出不耐烦或者沮丧。
根据用户实际进行测试时的表现,来决定是否继续其他任务的测试。
I. 怎么处理测试的结果
测试完成后,团队内部需要当天迅速召开一个会议。与会者除了参加了测试了工作人员,还需要团队内部重要的开发及测试工程师。每个参加测试的人员将测试过程中发现的问题一一罗列陈述出来,这样做的好处:
- 帮助其他参加测试人员回忆起当场记录遗漏的内容
- 自己整理分析出最严重的问题
- 开发人员能够听到最热乎的测试结果,从而更加理解产品存在的问题,便于后期执行修改。
将所有发现的问题罗列出来,以重要性和紧急程度,按照P0-P4确定问题优先级。对于P0-P1的问题,需要立即修复。而对于其他问题,则需要排期修复。
千万不要对于测试结果进行横向比较,也不要对测试结果做任何统计学或形式化的评估。可用性测试提供的是定性的数据,而不是定量的,做形式化分析会产生误导作用,且毫无必要。
千万不要写长篇大论的测试报告。制作报告以及分析问题会花去大量的时间,在现在的敏捷开发团队非常不值得,而且制作的复杂的报告,大家不会花时间去研读。赶快制定问题优先级,更改设计或者修复程序问题更重要。
J. 写在最后
实际在执行过程中,招募测试者通常是个比较麻烦的事情。如果是较为完整的可用性测试,论坛发布消息、网页刊登招募消息、或者通过求助于公司HR都是很有效的方法。对于简易可用性测试,先找朋友、家人测试都可以。经验证明,即使同一个公司的人,如果不属于同一项目组,通常对于产品尤其是新功能的认知也较低,也可用来做可用性测试。
简易可用性测试,其实可以随时随地,打游击式的好处在于几乎不需要准备,随时随地都能上。比如:有一次我在地铁上,发现坐在我旁边有两个台湾人,我就找他们试试我们的注音输入法,短短几分钟,发现了我们键盘某个按键的微小问题。