产品经理干货:可用性测试的那些事

标签: 可用性测试 产品经理 | 发表时间:2013-11-04 14:55 | 作者:游某
出处:http://www.woshipm.com

keyongxing

可用性测试是指通过对典型用户实施测试来对产品或服务做出评价。在一次典型的测试中,用户要完成一系列典型任务。与此同时,观察者会在一旁观察、倾听、做笔记。可用性测试的目的就是为了发现可用性问题,收集定性和定量的数据,并评估用户对产品的满意度。

可用性测试的好处

可用性测试有助于设计和研发团队在产品成型之前发现问题。问题发现和修正的越早,从工时和对日程的潜在影响来看,修正的代价就越小。可用性测试可以帮助你:

  • 了解参与者能否顺利完成特定任务
  • 了解完成特定任务的时间
  • 了解参与者对网站和其他产品的满意度
  • 找到为改善用户表现和满意度所需的改变
  • 通过分析用户表现来考察其是否满足你的可用性目标

你不需要一个正式的实验室

有效的可用性测试并不一定需要正式的实验室。你可以在这些背景下实施:

  • 由2-3个相连的房间改装的实验室,同时配备有录音和视频设备
  • 配备有可携带录制设备的房间
  • 没有录制设备的房间没关系,只要有人在观察用户并做笔记
  • 远程测试,用户在不同的地方(有主持的或者没主持的)

影响成本的因素

影响成本的因素有:

  • 测试的类型
  • 配备给测试的团队规模
  • 测试参与者的数量
  • 测试的天数

记住要安排不止一次测试的预算。网站或其他产品的可用性设计是一个迭代的过程。

为可用性测试安排预算时要考虑下面的因素:

  • 时间:你需要时间来计划可用性测试。需要时间来让可用性专家和团队熟悉网站,试验测试场景。确保为测试准备安排足够的时间,当然还有实施测试、分析数据、撰写报告和呈现结果的时间。
  • 招募成本:要考虑你要怎样和在哪里招募参与者。你要考虑到招募的工时以及让招募公司按照你的要求招募被试的时间。
  • 参与者报酬:如果你要为参与者的时间、旅费支付报偿,那就将这些也考虑进预算。
  • 租金成本:如果你没有监控或录制设备,你需要为实验室或其他设备支付租金,这也是预算的一部分。你可能需要保证一个测试的地点,比如一间会议室,这也是要考虑的。

制定测试计划

计划的目的就是记下你要做什么,你要如何实施测试,你要收集哪些测量数据,测试多少参与者,以及使用的场景。

通常,可用性专家会和网站或产品的拥有者以及研发团队的成员碰面,讨论决定计划的主要要素。然后,可用性专家会制定出计划的初步方案,告诉管理者和团队的其他成员。每个人发表自己的意见,并对最后的计划达成一致,可用性专家会修改计划来反映最后的决定。

测试计划的要素

可用性计划包括如下要素:

  • 范围:你要测试什么:给网站、网站应用、或其他产品取个名字。说明测试覆盖的产品方面,例如,截止到某个日期的原型;导航;导航和内容。
  • 目标:确定测试的关注点、问题和目标。目标可能很宽泛,例如,“用户从原型主页的导航能够定位到重要信息吗?”也可能很具体,例如,“用户能够很容易地找到放在目前位置的搜索框吗?”在每轮测试中,你肯定会有一些或宽泛或具体的关注点。场景要依据你的关注点设置。
  • 日程和地点:什么时候以及在哪测试。日程安排要详细说明一天中有多少次的会谈,每次会谈的时间安排怎样。
  • 测试阶段:每个测试阶段的说明、时长(通常一个小时到90分钟)。在安排参与者时,在测试阶段之间通常要预留30分钟的时间来重新布置环境,与观察者简单回顾讨论这个测试阶段,或者为测试阶段推后或参与者迟到提供缓冲。
  • 设备:说明设备的类型。台式机、笔记本、手机或智能手机。如果与测试相关,也应包括显示器的尺寸和分辨率,操作系统,浏览器等。也要说明你计划录音或录像,或使用到某种特殊的可用性测试工具和协助工具。
  • 参与者:说明你计划招募的测试参与者的数量和类型。介绍你要怎样招募这些参与者。可以考虑将筛选标准放在附录。
  • 场景:说明测试中任务的数量和类型。通常,对于一个60分钟的测试,你可以为台式机或笔记本的测试安排10(+/-2)个场景,为手机或智能手机测试安排8(+/-2)个场景。你可以在测试计划中包含更多的场景,这样团队就可以从中选择合适的任务。
  • 测量数据:主观测量数据:包括你准备在每个测试阶段前(如背景调查问卷)和每个任务场景完成后(任务的容易度和满意度问题)询问参与者的问题,以及每个测试阶段结束后整体的容易度、满意度以及使用和推荐的可能性等问题。
  • 定量测量数据:列出你在测试中要测量哪些定量数据,例如成功率,错误率和完成任务所需时间。
  • 角色:参与可用性测试的员工名单和他们的角色。可用性专家应该成为测试的主持人。可用性团队成员可以是主要的记录者。其他团队成员可以作为观察者或记录者。

招募参与者

你要招募熟悉网站的用户做测试的参与者。

根据网站或产品的不同,你可能有许多不同的潜在用户群(例如,内科医生、病人、研究者或青少年、父母和教育者)。每个用户群要尝试着招募一些典型用户,或者最好的情况是,如果你想收集基于角色的信息或关注功能,你也可能单独对每个用户群实施测试。

如果你的网站是针对外部受众的,一个常见的错误就是使用内部员工来做参与者。只有内部员工也是网站的目标受众时,他们才能作为参与者。

  • 数量:对于一个诊断性的可用性测试,6-8个用户通常就足以发现产品的主要问题。

如果你想开展正式的定量测试,你需要从更多的人那里获得数据结果,但是可用性测试通常不会这样做。

如果你计划在开发网站时做迭代可用性测试,许多用户会对网站的好几个版本进行测试。你需要将这个考虑进你的招募和预算计划。

  • 招募:如果你的团队能够找到典型用户,你可以从他们当中招募。如果你的团队找不到,你可以雇用一家商业招募公司。大部分招募公司需要两到三周来寻找和安排必须的参与者数量和类型。一些招募公司也可能帮你管理报酬费。最好和他们讨论下你的团队所需要的额外服务。
  • 筛选问卷:筛选问卷可以很简单,只有性别和年龄;也可以很复杂,包括一系列目标受众的规定。
  • 成本:包括寻找参与者的花费,也包括激励参与者的花费(如礼物或酬金),某些情况下也包括旅途费用和停车费。

测试准备

确保你准备好了所有材料、知情同意书和需要的文件。在测试前再检查一遍。让一个志愿参与者初步试验一下设备和材料。初步试验可以帮助你:

  • 测试设备
  • 让主持人和记录者练习一遍
  • 了解到参与者能否清晰地理解你的问题和场景
  • 做最后的调整

在正式测试前用1-2天做试验性的测试,这样你就有时间处理一些技术问题、或有必要的话调整场景或其他材料。

实施可用性测试

以下是一个测试阶段的例子:

1.  主持人对参与者表示欢迎,并向其说明接下来的测试阶段,邀请参与者签下授权协议,询问测试前的人口统计学问题。

2.  主持人说明出声思维,并询问参与者有没其他问题。主持人告知如何开始。

3.  参与者大声阅读任务场景,并一边依据场景开始工作,一边出声思维。

4.  记录者记下参与者的行为,评论,错误以及是否成功完成每个任务。

5.  直到所有任务场景全部完成,测试阶段也就结束,或分配的时间已经过去

6.  主持人询问测试阶段结束后的主观性问题,或者让他们完成一个在线调查,感谢参与者,给参与者报酬,护送他们离开测试环境。

7.  主持人随后重新布置材料和设备,和观察者简单讨论,等待下一个参与者的到来。

测试度量

在测试中可以收集下面几种测量数据:

  • 任务成功率:每个场景都需要用户获得特定的数据以完成任务。当参与者找到问题的答案或完成任务目标时,场景任务就算成功完成了。在某些情况下,你可能想要询问多重选择的问题。记住,在测试计划中要有问题和相应的答案,并将这些告诉记录者和观察者。
  • 关键错误:关键错误是指偏离场景目标的行为。例如,由于参与者的工作流程而报告了错误的数据。这种情况下,参与者本质上是不能完成任务的。参与者可能意识到或没有意识到没有完成任务。
  • 非关键错误:是指参与者自己恢复的错误,或没有导致任务失败的错误。这些错误只是造成完成的效率更低。例如,打开错误的导航菜单栏目的探索性的行为,或不正确地使用一个控件。
  • 零错误率:参与者在没有出现任何错误(关键和非关键错误)的情况下完成任务的百分比。
  • 完成任务时间:参与者完成任务所需的时间。
  • 主观测量:参与者自我报告的关于满意度、易用性、找到信息的容易程度等方面的评价,使用5-7点量表测量。
  • 喜欢,不喜欢和建议:参与者最喜欢网站的哪些方面,最不喜欢网站的哪些方面,以及改善网站的建议。

数据分析

根据你使用的测量数据的不同,你最后会得到几种不同的数据类型。这包括定量数据(成功率、完成任务时间、错误率、满意度评价)和定性数据(参与者使用流程的观察、出现的问题、评价与建议、开放性问题的回答)。

重要结果报告

为了保证报告了重要结果,当你检视数据时要考虑问题在整个网站中的普遍性以及问题的严重性。

你的发现可能对网站的其他页面也有参考价值(普遍性)。例如,你可能发现,由于文字太密集,参与者在网页上找不到想要的东西。你可以说仅仅是这个页面需要调整,但你也需要考虑其他页面是否也存在这个问题。

一些问题相比其他问题对于参与者完成任务更为关键。许多组织会在3-4点量表评价问题的严重性。例如:

  • 非常重要:如果我们不修正这个问题,用户就没法完成场景任务。
  • 重要:如果不修正这个问题,用户会感到受挫,并最终放弃。
  • 次要:用户有点恼火,但这并不影响他们完成场景任务。这个问题有待不久后商榷。

撰写报告

一个好的报告应该包括测试计划的相关信息,并呈现刚好足够的细节以便后续测试能够重复这一方法。每一部分尽量简洁,用表格呈现测量数据。把发现和建议作为重点,并使用可视化的例子来说明问题区域。

你的报告要包括:

  • 背景总结:对你测试了什么(网站或网站应用)、什么时候在哪里测试、设备信息、在测试中你做了什么(可以将所有的测试材料放在附录)、测试团队和问题的简单描述做一简短的总结。
  • 方法:呈现测试方法以便他人可以重复你的测试。说明你是如何实施测试的,包括介绍测试阶段、测试界面的类型、收集到的测量数据、测试场景概述。介绍参与者情况,用一个总结性的表格呈现他们的背景/人口统计学特征的信息,例如年龄、职业、网络使用情况、访问的网站等。对人口统计学数据做简单的总结,但不要透露参与者的全名。
  • 测试结果:介绍主持人和数据记录设备的收集的结果。介绍最高和最低完成率的任务。总结每个参与者的成功率、任务和每个任务的平均成功率,并用表格呈现出来。以这种方式呈现所有的测量数据。
    • 完成每个场景和所有场景的参与者数量和百分比,可以用条形图呈现。
    • 完成每个场景平均所需的时间
    • 满意度结果
    • 作为例证的参与者的评论
  • 发现和建议:用你的数据列出你的发现和建议(定量的和定性的,笔记和电子表格)。每个发现都应基于数据,即你实际看到和听到的。你可能只想将所有发现和建议列成一张总表,或者一个场景一个场景的介绍,又或者不仅有一张主要发现的列表,也有依据场景任务划分的建议,同时也有一个场景一个场景的报告。记住:
    • 虽然大部分的可用性报告只关注问题,但报告正面的发现也是有用的。那些工作良好的特性在未来的研发必须保留。
    • 一个完全负面的报告可能会让人心灰意冷;它有助于团队知道一个工作良好的网站的许多问题。
    • 每个发现应该包括尽可能具体的对情境(situation)的描述。
    • 每个发现(或每组互相关联的发现)应该包括怎么应对的建议。
  • 严重性评级:如果你将问题区分为局部性的和整体性的,且有严重性评级,要报告这些。附上截图和视频片段。加入视觉元素能够报告更富信息量也更加有趣。截图能让读者看到你在测试什么。它能表现哪些地方工作良好,哪些地方给用户带来使用困难。如果你是在电子设备上呈现报告,并且能让读者看到视频片段,要附上一些短视频来说明特定的点。通过观看相关的视频片段,没有观察到实际测试阶段的人能够更加确信问题的所在,并由更强的意愿去修正。
  • 执行和重新测试:要想实现可用性测试的价值,你必须将你所了解的应用到网站的改善中去。你可能没法执行所有的建议。开发任何产品都是一系列权衡的过程,你要考虑需要的日程安排、预算、人手和改变。如果你没法执行所有的建议,你可以基于全局性和严重性来判断优先级。做出优先级判断后,推进用户需要的改变。当一个网站还在开放阶段时,为一个设计糟糕的网站的用户提供支持的成本远远大于修正网站的成本。

最佳实践

  • 尊重被试,让他们感觉舒适自然。
  • 记住你是在测试网站而不是用户。让他们理解他们是在帮助我们测试原型或网站。
  • 保持中立。你是在听和看。如果参与者问你问题,你可以这样回应“你认为呢?”,“我好奇你会怎么做。”
  • 不要突然跳出来帮助参与者,也不要引导参与者。如果参与者放弃了并向你求助,你要决定是否要终止场景、提示还是给到更多的帮助。
  • 团队必须决定当参与者明显去到一个错误的路径时,你要提供多大程度的提示,以及允许参与者完成场景花费多少时间。
  • 做好笔记。记录者要尽可能详细地记录下参与者做了什么和说了什么。笔记做的越好,分析也就越容易。
  • 测量行为表现和主观(偏好)度量。表现测量包括:成功率、时间、错误率等。主观测量包括:用户自我报告的满意度和舒适度评价。人们的行为表现和主观偏好并不总是一致的。用户经常在表现糟糕时,主观评价却很高。反之亦然。
  • 可用性测试不仅仅是对项目进度的检查。团队应该知道测试的目的是什么,然后执行结果。

转自:http://article.yeeyan.org/view/200085/384744


本文链接《 产品经理干货:可用性测试的那些事
官方微信:woshipm,干货天天推荐,欢迎订阅

相关 [产品经理 干货 可用性] 推荐:

产品经理干货:可用性测试的那些事

- - 人人都是产品经理
可用性测试是指通过对典型用户实施测试来对产品或服务做出评价. 在一次典型的测试中,用户要完成一系列典型任务. 与此同时,观察者会在一旁观察、倾听、做笔记. 可用性测试的目的就是为了发现可用性问题,收集定性和定量的数据,并评估用户对产品的满意度. 可用性测试有助于设计和研发团队在产品成型之前发现问题.

产品经理干货:如何活用使用场景做产品测试?

- - 一个产品经理的博客...
  产品测试一般都是围绕需求为主的产品需求设计说明书PRD文档来展开测试的,针对每个功能点编写测试用例,去验证功能的正确性和完整性. 这种方式在正常的开发上线进度下都不会有问题,相反是一种很好的验证功能需求实现的方式. 但在敏捷开发模式或者因为赶进度的原因,造成产品测试时间非常紧的情况下,用这种方式就会有点捉襟见肘.

产品经理

- - 人月神话的BLOG
再谈下怎样能够算得上一个合格的产品经理,一个人不是说你能够有产品构思,能够画点原型,能够做团队和项目管理就是产品经理. 苏杰原来有本书叫《人人都是产品经理》,看了后大家可能会觉得做一个产品经理是挺容易的一件事情,但是自互联网提供和设置了大量的产品经理岗位后,产品经理这个词基本就烂大街了. 我们如何来界定一个产品经理,如果简单点来讲可以理解为 根据自己长期的项目和运营实践,通过自己的敏捷洞悉能力和分析能力,能够将当前的市场需求或潜在的市场需求转化为具体的产品需求,并能够核心的定义产品功能模型和价值输出,同时能够通过项目和团队管理的能力,凝聚一个小组形成一个真正的团队,将自己的产品构思付诸于最终产品实现的人.

产品经理好与坏

- lnsoso - 随心所记 - 生活中的dodo
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- 张金龙 - 所有文章 - UCD大社区
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理好与坏

- abcd - 所有文章 - UCD大社区
例如李明远,设计了百度贴吧和百科这两个重量级产品,只可惜我并没有亲见这些产品设计的过程,客观的说,我还不知道什么才是厉害的产品经理. 既然我有限的经历无法胜任点评产品经理这个重任,那就来感性的说一下我所欣赏和厌恶的产品经理类型吧,权当我所谓的好与坏. 我很欣赏曾经的百度有啊中充满想象力的产品经理,明远和东宝都能算作具有这样特质的人.

产品经理是炮灰

- Neglect - 坏脾气的小肥
前些日子有篇网文,鼓吹产品经理的重要性,几乎夸上了天. 有人评论道:“是为了争取加薪吗. 一个人能取得多大的成功,取决于两点:1、他有多少才华与热情,2、这些才华和热情是否能战胜环境中的困难. 很遗憾,摆在产品经理面前的障碍大部分是不可战胜的. 在这篇文章里,我们只讲靠谱的产品经理,不讲不靠谱的. 不论PM靠不靠谱,都分为两种,或者在大中型公司工作,或者在小型公司(创业团队)工作.

产品经理“玩”数据

- - 一个产品经理的博客...
  产品经理生来就是要解决问题的. 那如何才能更好、更高效地解决问题?首先要求我们能发现问题,数据分析就是一种常用的发现问题的手段. 通过数据定位问题,然后用设计方案来尝试解决问题,之后再用量化的数据指标来评估问题是否解决了,解决了多少. 通过迭代优化,问题就能够得到较好解决.   本文结合自己在在登录产品的体验优化中积累的一些实战经验,重现过程中的设计点滴,有效果明显的方案,也有效果不明显的优化尝试,最后将总结一些通用的设计思路.

好的产品经理,差的产品经理

- - Xiaoxiao's Weblog
本文转载至 译言网 作者: Ben Horowitz. Ben Horowitz这篇不朽的杰作诞生于1996年,但时间的久远丝毫不影响其对当前的警示作用. 彼时,作为Netscape产品管理部门经理的Ben,没有假大空地介绍产品经理的角色和责任,而是很直观地对比了一个好的产品经理和差的产品经理.

一个谷歌产品经理眼中的产品经理

- - 互联网分析
我在创业公司已经呆了好一阵子了,我发现招聘这个事儿在大公司和创业公司还真是截然不同. 在雅虎搜索的时候,我们一直是持续的进行招聘的. 我一周会进行大概5-8次的面试. 简历、面试、offer,总是一个接一个,不间断. 现在我已经不做招聘经理的事儿了,我在创业公司只负责招很少一部分的产品经理. 但是总有人在招产品经理,而我也总是面试团队的一员.