一篇文章总结可用性测试方法

之前总结过一版交互设计流程图,主要是想给自己以后做设计梳理一下过程,但是那份流程里面只有枝干,并没有枝叶,所以针对每个方法我都会撰写一份方法总结,或者说指导,目的就是为以后实践做准备。我期望的效果是,假如一个没有接触过该方法的人看到这份总结,可以按照这个总结一步步完成实验。这就是我最大的目的。下面就是第一份总结《可用性测试方法总结》。

一篇文章总结可用性测试方法

之前总结过一版交互设计流程图,主要是想给自己以后做设计梳理一下过程,但是那份流程里面只有枝干,并没有枝叶,所以针对每个方法我都会撰写一份方法总结,或者说指导,目的就是为以后实践做准备。我期望的效果是,假如一个没有接触过该方法的人看到这份总结,可以按照这个总结一步步完成实验。这就是我最大的目的。下面就是第一份总结《可用性测试方法总结》。

(预警:长文慎入!不过耐心看完肯定会有所收获)

1.可用性测试的过程

可用性测试的过程主要有七个步骤:测试前思考、制作测试原型、撰写测试脚本、招募测试者、设置测试环境、预测师、正式测试以及测试结果统计分析。这七个步骤有些事可以并行的,有些是需要严格按照前后顺序执行的。七个步骤组成的流程图如下:

一篇文章总结可用性测试方法

可用性测试过程

下面我就针对这七个步骤,谈谈具体要怎么做。

2.测试前思考

不论是做哪个平台的可用性测试,比如PC端、移动端或者是WEB端的可用性测试,最最重要的就是要先理清楚一些基本问题。基本问题就是最经典的5W问题:

  • 为什么要进行这个测试(why)?测试可以验证一些设计中的疑惑,或者找出现有的界面、流程设计上的问题,具体问题要具体分析。
  • 什么时候在哪里做测试(when?where?)?时间一般是需要和测试者协调的;地点一般选择在安静的会议室即可,如果公司有专门的实验室那就最好不过了。
  • 谁要作为测试者(who)?这里可以在招募测试者会详细讨论,不过测试者一般是跟我们的persona接近的人,或者换个说法,测试者一般是我们的目标用户。
  • 我们要测试什么(what)?测试一些功能点,测试界面设计,测试流程设计,测试设计中有争议、有疑问的地方。

当然这些问题其实都不太难,但是这些都是至关重要的问题。如果没有经过这个步骤的思考,整个可用性测试做下来就会像无头苍蝇,没有一个总的指导。

3.测试前期准备

在想清楚以上的问题之后,需要为可用性测试做一些准备工作。主要工作有:①招募测试者;  ②撰写测试脚本;  ③制作测试原型。

这三个过程不分先后,条件允许的情况下(人力物力充足时)也可以同时进行。

3.1招募测试者

招募测试者算是可用性测试最重要的一个环节之一的,测试者是否合适直接关系到测试结果的好坏,测试结果直接关系到能否发现产品现有的问题。所以招募测试者是重中之重。理想的测试者是我们的目标用户,所以可用性测试要努力寻找到目标用户作为测试人员。寻找的途径如下:

  • 最简便的,假如同事(非同部门)或者好友也是目标用户,可以选用同事或者好友作为测试人员。
  • 其次,大型公司都会有自己的用户资料库,可以从这个库里面寻找到测试人员。
  • 又或者说,委托第三方机构帮忙寻找测试人员也是允许的,不过效果可能不如自己寻找的。
  • 当然,现在的应用一般都会有自己的微博、微信、官网或者论坛,这些是非常好的寻找测试者的渠道。

我们可以推送招募测试者的公告,让用户填写一份调查之后,我们再筛选得到我们想要的测死者。公告中要注明奖励,一般为小礼品的奖励,保证对测试者有一定的吸引力,同时又不至于让他们会为了这个礼物对个人信息造假。其次,对于测试者,我们需要进行一个筛选【3】。首先需要用户填写必要的个人信息:比如姓名、电话(邮箱)、空闲时间;然后根据调查选择其他一些个人信息:性别、年龄、职业之后,最后留几道问卷题目进行筛选。

筛选的维度主要有:

  • 平台。如果测试的产品与平台有关,比如是Android或者iOS,需要在这里进行一个筛选。
  • 对产品的熟悉程度。比如我们想找一些初级用户和一些高级用户,可以选用“使用时间”这一项来衡量用户对产品的熟悉程度。

3.2撰写测试脚本

测试脚本的好坏直接关系到结果的好坏。在撰写测试脚本之前,我们需要先确定一些结果分析的维度。一般的维度有:a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。对于这些维度的解释具看第文章的最后一部分“测试结果统计分析”。

由于分析的维度会关系到脚本的问题,所以在确定分析维度之后,我们可以对功能点进行任务分析。把所有需要测试的功能点列出来,对每个功能点进行任务设计。对于任务而言,用户最主观的感受就是两个:界面和流程。所以测试脚本又可以从这两个维度去细分。

需要注意的是,可用性测试中,问只是其中的一部分,观察是另外一个重要的内容,所以测试脚本不仅仅要有问的问题,还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时,把总结大纲也写出来,方便后期总结的时候统一结果展示。

特别的,在设计的时候有疑惑的点,或者有争议的点,在可用性测试也可以得到较好的验证。

写完测试脚本之后,可以和利益相关者(项目经理、产品经理、开发等)讨论一下,请他们校验一下测试脚本。

界面:

  1. 当前界面有什么?
  2. 每个东西用户觉得是什么?
  3. 可以操作吗?
  4. 用什么手势操作方式?
  5. 操作之后会怎么样?
  6. 界面显示的内容足够吗,有没有缺少什么东西?

流程:流程的测试就是根据任务来进行的。把产品的需求文档罗列出来,然后给每个需求配上一个合适的场景,当然也会出现一个场景覆盖多个需求的情况,这也是允许的。然后让用户在场景下去进行任务,观察用户,然后随时提问用户,随时准备回答用户的问题。

以上两点适合所有的可用性测试,但是对于版本更新类的可用性测试,我们还需要了解这个更新对于用户来说的接受度如何,所以需要增加一些对比性的问题:比如说:新旧版的操作流畅度、界面表达对比感受。

最后需要注意的是,一次可用性测试能涵盖的范围有限,所以要限制脚本问题的数量,以及对脚本的问题进行优先级的排序。

举个例子:之前做过一个微信端的众筹平台。我就可以设定以下任务:

一篇文章总结可用性测试方法

测试脚本样例

3.3制作测试原型

可用性测试的原型一般是高保真的Demo,可以用Prott、Flinto、proto、墨刀等来制作,制作力求真实还原应用的最终实现效果。制作高保真Demo是一件耗时耗力的工作,所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo最终也可以给开发参考,所以辛苦也是值得的。甚至于,可以请求开发人员制作原生的程序Demo(针对安卓平台),程序Demo体验会更加好。

当然,纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来,然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作,然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用,同时,测试的时间也会大大增长。同时,动效作为设计的一环在这里无法表现出来,所以结果可能会不如高保真Demo来的好。总之各有利弊,根据实际情况来考虑。

4.设置测试环境

测试环境是指测试的时候需要使用的记录设备,通过把测试过程记录下来可以更好地分析用户的行为,特别是用户自己都没有觉察出来的一些东西。

首先,最最重要的一点是录音、录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景,然后填补一些缺失的笔记。另一方面,录音也可以作为一种存档的材料。同时,录音也存在简单、易操作、隐蔽等特点,使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。

录音之外就是录像、如果有录像的话,录音的步骤就可以省略。录像主要是记录用户的表情和动作。有时候,用户的表情和动作可以传达很多东西,通过把这些信息记录下来可以,设计师偶尔可以挖掘到一些闪光的设计点。

除此之外,用户的屏幕记录也是一种方式,通过用户的屏幕、加上用户操作的动作,表情,可以真实还原用户的使用场景,方便后期的分析。

录像和录屏的操作比较难进行,主要的设备可以参考如下【5】,具体可以查看相关的链接:

  • 摄像机:记录动作和部分表情
  • 眼动仪:可以追踪眼球的焦点轨迹,不适合移动端
  • 鼠标轨迹记录:记录鼠标轨迹,只适用于PC端
  • QuickTime (iOS):仅记录屏幕
  • Mobizen (Android):记录屏幕、手势
  • Display Recorder (iOS):手势、声音
  • SCR (Android):记录屏幕、手势、表情、声音
  • Magitest (iOS):记录屏幕、手势、表情、声音
  • Mobizen +AirDroid (Android):现场观察并记录手势、表情、声音

5.预测试

预测试是正式实施可用性测试前的一次模拟, 模拟有助于发现问题,这时候邀请同事即可。把正式测试的流程走一遍,包括设配的调试、访谈切入、问题的提问、记录者的记录等,然后把记录的录音、视频等放出来看看效果如何,效果不如意的时候再进行调整。

总之,预测试可以帮助发现问题,包括以下几个方面的问题:

  • 设备的问题。举个例子,录音设备放置的位置会影响录音的效果。
  • 测试脚本的问题。测试问题是否足够清晰。
  • 访谈的切入以及问题的提问。
  • 记录者的记录。

发现问题之后去解决问题,才能使正式测试的时候达到更好的效果。

6.正式测试

6.1事前接待

测试前的接待工作是测试人员对公司的第一印象,给测试人员留下一个好印象、一个好心情有利于可用性测试的进行。所以在这里将一些注意点说一下。

首先,可以事先确认一下用户的行程。遇到刮风、下雨、下雪等恶劣天气的时候可以事先送上问候短信。

其次,遇上用户迟到的情况下,也要保持克制。在迟到五分钟到十分钟之后再给用户电话询问情况,如果用户因故取消测试,也要保持友好的态度。

在接到用户之后,送上一杯温水或者温热的饮料,然后让用户等待一下。最后可以有专门的人员先和用户聊聊天,可以打听一些事情。

6.2暖场介绍

正式开始之前有个暖场介绍。首先主持人做一下自我介绍,然后介绍一下测试的目的和时间,需要向用户强调测试的对象是系统,希望用户可以畅所欲言。如果有录音或者录像,需要向用户告知会有此类行为,但是结果完全保密。最后还需要签署保密协议。

6.3正式提问

正式提问分两个部分:个人信息的小问题和可用性测试任务问题。

小问题主要是为了让用户有个适应的过程,可以迅速进入状态。一般可以询问产品使用习惯、产品偏好、上网情况等,之后的测试问题就是主要的可用性测试的问题。这里需要把问题放入到场景中,让用户在场景中去完成任务。或者可以询问用户的使用习惯,然后引导到脚本中的问题。需要注意的是,不一定要按照脚本的顺序提问,可以随机应变;所以主持人要非常熟悉脚本的内容。除了询问,聆听之外,主持人还要观察用户的神情以及动作,遇上用户有疑问的表情的时候可以适当穿插新的问题,但是尽量不要提供帮助,也不要指出用户的错误或指责动作太慢,但是可以询问用户“为什么这么操作”,必要的时候可以选择停止任务。

测试过程中还需要有一个记录人员,记录人员需要记录:用户做了什么动作和步骤(重点)、用户说了什么、写下自己的疑问(适当时候可以进行提问或者让主持人提问)。

6.4结束感谢

测试结束之后,主持人可以问一下用户的想法,同时让记录人员补充提问,所有问题结束之后,需要对用户表示感谢。送上礼品并接受用户的一些交通费报销票据等。最后要把用户送到公司门口。

7.测试结果统计分析

测试结束之后,如果有时间可以立马进行整理,因为时间越短,整理出来的内容就越丰富。必要的时候,可以用录音或者录像来辅助。在撰写测试脚本的时候还有一份总结大纲,根据大纲来整理内容。大纲要具备灵活性,可以记录一下测试现场发现的新问题。

记得只是整理而已,每个测试结束都会有一份整理的资料。最后需要汇总多份可用性测试总结,最终出具一份可用性测试结果,根据这份结果进行相应的改进工作。

我们可以从如下几个维度去分析我们的可用性测试【8】(维度之间可能有交叉):

  • 任务完成度。每个测试任务都对应一个目标,只有当用户达到目标之后,我们才认为他们完成了任务。对于每个任务,用户完成的情况如何?有多少用户最终没能完成任务?多少用户需要在主持人提示下完成任务?多少人可以自行完成任务?这些都是很重要的指标
  • 致命错误。严重错误指那些阻碍用户完成任务的错误,这些错误非常重要,每一个都要得到足够的重视。
  • 非致命错误。非致命错误是指用户能完成任务,但是某些地方会有一些阻滞,会停顿或者思考的错误。这些错误相对来说没那么重要,不过如果发生的次数较多,该类错误也需要得到重视。
  • 完成任务的时间。每个任务需要完成多少时间,决定了交互设计流程和界面的设计是否足够友好。
  • 主观情绪。用户对于任务的主观感受,比如是否足够简单,是否容易找到信息,可以让用户衡量一下。
  • 偏好和建议。可以让用户说出产品中哪些地方很喜欢?哪些地方不喜欢?或者让他们提一下建议。

 

本文由 @Autumn阿秋 原创发布于人人都是产品经理 ,未经许可,禁止转载。

原创文章,作者:Catherine,如若转载,请注明出处:https://www.iamue.com/30791/

(0)
CatherineCatherine
上一篇 2017-05-30 05:38
下一篇 2017-05-30 07:47

相关推荐

  • 探讨:对话式交互会成为未来主流的交互方式吗?

    本文详细分析了对话式交互的优缺点和应用场景,适合产品经理、UI设计师和交互设计师来阅读。

    2017-05-07
  • 课件界面交互设计

    交互的概念我们将交互定义为具有信息处理功能的两个实体或对象间信息传递和反馈的过程。具有信息处理功能的实体或对象是指那些在功能上能够完成对信息的接收、处理和发送实体或对象。交互本质上是信息传递的过程。由于交互总是由某一实体或对象出于一定目的引发起来的,所以我们还可以认为交互是一个具有信息处理功能的实体或对象基于解释为定目的对另外一个具有信息处理功能的实体或对象发送信息并得到反馈信息的过程。(孙海民,2005)。一、人机交互概念人机交互是指...

    微信热点 2018-03-01
  • mBack交互方式分析

    本文作者将对魅族最新研发的交互方式—mBack进行分析,从谈论手机操作系统方式与电脑的操作系统方式有着两个较为明显的差异,到分析mBack的缺点,值得一看。乔布斯说:伟大的产品都是只有一个按键的。在已经将交互优化到已经不能再删减时,如何有效的组织和隐藏就显得尤为重要。随意性用户可能使用过类似的产品或服务,有兴趣使用更为复杂的产品,但是不愿意接触全新的产品,除非新功能足够简单。主流用户是最大地群体。他们使用产品的目的是完成任务,他们永远也不会产生学会所有功能的想法。

    2017-05-01
  • Android 和 iOS:两个系统交互设计的不同之处在哪?

    iOS 和 Android 的设计还有许许多多的不同之处,比如字体、Tab bar 设计、物理键操作方式、编辑模式、APP 体现个性的方式……在设计移动端产品的过程中,设计师们可以更多的去思考两者的异同,并且更多的关注一下 Android 系统独有特性的运用,不仅仅节省了开发成本,同时也更好的为 Android 用户所接受。1dp(Android)=1pt(iOS)
    以48dp@160dpi计算的话
    mdpi 48px (160dpi, 1x) 基础尺寸,已经非常少使用
    hdpi 72px (240dpi, 1.5x)低分辨率
    xhdpi 96px (320dpi, 2x) 同iOS @2x
    xxdpi 144px (480dpi, 3x) 同iOS @3x
    xxxdpi 192px (640dpi, 4x) 更大更高更强的分辨率

    2017-05-06
  • 【交互设计】【装置艺术】传统昆曲与数字视觉的结合

    ▼数字与戏曲在数字时代大势所趋的背景下,传统戏曲也进行了一些试探性的尝试。交互性能和身临其境成为了戏曲的一种新的模式。演员通过光影达到像素化的效果,圆滑光影与演员的冲突,减少真实与虚拟的隔阂。打造沉浸式的戏曲艺术。▼沉浸与交互数字技术润滑了装置与观众的联系,发挥更大的互动作用。利用空间互动装置设计,以评估演出、空间和观众之间的联系,从而为观众提供一种身临其境的体验。▼古典与未来昆曲是一种东方古典戏剧艺术形式。数字技术的使用可以带来一种新...

    2018-04-17
  • Sketch 这几招你肯定不知道

    1.精确调整元素属性在点击元素属性旁的箭头时按住 alt 键可以以10px 倍进行调整,按住 option 键则是0.1px 倍。2.用对齐工具对齐锚点Sketch 中的对齐工具不仅可以对齐群组和图层,还能够对齐锚点,非常方便。3.导航栏文本状态调整与其为导航栏每一个状态都重新做一下,不如将导航栏中的所有元素转为一个符号(symbol),这一个符号中调整样式即可。如果要隐藏文字图层的话只需要在符号的对应文字中输入空格键即可。4.直接拖动...

    2018-04-26
  • 8个你需要知道的2017年UI设计流行趋势

    UI界面的设计趋势是不断变化的。随着时间的推移也在不断的成长,进化。虽然有些趋势还有待检验,但我们还是需要不断的去学习新的技术。

    2017-05-15
  • 设计顶峰:如何打造创新有价值的极致体验?

    经常发上手即用的教程和技巧,今天来点不一样的「干货」,聊聊在设计中的价值创新。内文案例丰富,配图生动,也有实战案例,对于「需求」的理解非常到位,来自阿里Heyuchan 同学的分享,如果你恰好是交互设计的,更加不能错过咯。

    2017-05-24
  • (全解析)屏幕尺寸,分辨率,像素,PPI之间到底什么关系?

    屏幕的清晰程度其实是分辨率和尺寸大小共同决定,用ppi指数衡量屏幕清晰程度更加准确。

    2017-06-04
  • 新项目丨青岛东海凤凰:宽建筑[UCD]挑战中国第一仿生建筑

    *文章已由原作者授权发布▲凤凰中心效果图作者:王宽方案设计方:宽建筑 [北京城建] KUAN architects [UCD]项目名称:青岛市西海岸新区文化活动中心地址:中国,青岛,金沙滩设计团队:王宽,周媛,李鹏,梁文杰等结构咨询:中冶京诚工程技术有限公司  卢理杰数字模型&BIM咨询:北京华茂云信息科技有限责任公司施工方:北京城建集团(建筑部)、北京城建集团十六公司、城建精工钢构公司面积:31,313平方米状态:主体结构已封顶预计建...

    2018-03-13