腾讯高级产品经理教你如何做产品的可用性测试(案例详解)

思考人们如何使用

首先,你要了解的是人们用你的产品做什么

这些人使用产品过程中最重要的行为是什么?产品用户的目标是什么?企业/组织的目标是什么?什么是需要完成的工作/任务?

相信这个世界上最好的网站(或其他任何东西)可用性测试者是创作者本身。(译者注:大多数情况下,创作者对自家产品带有明显的主观偏见,一般情况下,建议创作者作为辅助人员参与测试,而不是主导;另外,由于企业内部还有其他相关部门,可以由其他相关部门人员主导测试。)

他们自然知道什么是重要的,这就是为什么不举别人的例子,而是只和你们说我们自家产品(X 产品,因为还没有面世,所以先这么称呼了)的原因了。

我们希望人们浏览我们的营销网站,了解更多关于我们的信息,从而了解我们的营销工作是否有意义。

我们也希望看到,人们注册、创建账户或申请成为测试人员这一过程,是多么的简单。

当然,还有更多我们想了解的事情,但这样足以开展下一步了。

一句话任务列表

根据前一步骤收集到的信息,为可用性测试提出了这份任务清单:

  1. 创建一个帐户
  2. 成为测试人员
  3. 开通服务

现在自己试着做一做。

考虑人们(应该)在你的网站/应用上做的所有重要事情,并写下一个简短的一句话任务列表。

不要在细节上浪费时间,只需要列出清单就好,我们将在下一步中处理其余的事情。

一个好的任务列表包含与网站或产品成功相关的用户交互。

如果希望人们在网站或产品上购买东西,应该有一项要求测试这买东西的任务。

如果你想让人们创建一个帐户,应该让他们注册你的网站。

很快就会意识到,你和你的团队为自己的网站或产品列任务清单是多么容易。

这是进行可用性测试的一个好处,而且你可以随时采用更好的方式。

编写特定的任务场景

编写好的任务场景非常简单,有一些规则可以遵循,而无需成为专家。

但首先,让我们来看看有关 X 产品的例子,以便更好地了解如何编写自己的任务。

任务:创建一个 X 产品的帐户

你在一家电子商务公司工作,工作是为网站或者产品探索不同的可用性测试服务。了解 X 产品,看看它是否可以解决这个问题。选择一个计划并尝试创建一个账户。

任务:成为测试人员

你正在寻找机会在网上赚钱,并偶然发现这个网站或者应用。请尝试通过测试 X 网站或者应用来找出自己可以赚多少钱,并申请成为测试人员(如果需要,可以使用假电子邮件地址)。

任务:开通服务

想象一下,你有兴趣了解更多关于如何进行可用性测试的信息。请看看这个网站或者应用,找到一篇关于可用性测试的文章。快速阅读该文章,并尝试通过电子邮件订阅文章(如果需要,可以使用假电子邮件地址)。

在上面提到过,有一些编写任务场景的规则可以遵循:

  • 避免在场景中提供线索。不要在网站或应用中使用罕见或独特的词汇。为什么?测试者将扫描屏幕以查找这些单词,并且也无助于获得关于可用性的更多见解。
  • 写得清楚、易懂、易于遵循。写下你说话的方式,不要用科学或学术词汇或者口吻。与同事或朋友预先测试任务,确保他们通俗易懂,确保人们真正知道你希望他们做什么。
  • 修剪任何不必要的细节。任务场景应设置上下文,并为用户提供必要的详细信息,如用户名或特殊交付地址,其他一切都是不必要的。尽可能缩短任务场景,保证测试者能够自己搞清楚。

奖励提示:让人们首页浏览

什么是首页浏览?

这是史蒂夫·克鲁格的观点,这是他在每个可用性测试中都要做的事情,以便在他们提供实际任务之前让参与者开始工作。

下面是一个基于史蒂夫《Rocket Surgery Made Easy》(中文书《妙手回春:网站可用性测试及优化指南》)一书的例子:

请浏览这个网站或者应用,告诉我们你的想法是什么:

  • 你注意到的第一件事是什么?
  • 你可以在上面做什么?
  • 它提供了哪些产品或服务?
  • 它的目标用途有哪些?

多浏览一下(或者说全面的浏览),说出你想到的一切。如果你想滚动或者划动页面都可以,但请不要点击任何东西。

你当然可以(也应该)根据你自己的需要来调整它。

首页浏览会告诉你,人们是否可以理解你的产品提供什么,并且了解你的产品是什么,即使是他们通常用不到甚至不需要的东西。

结果会告诉你为什么人们在理解你的产品或服务的时候存在困难。

你可以观察他们第一次使用你的网站或应用,并且了解他们对此的态度和想法。

这可以帮助你确定内容、信息,甚至是架构中哪些有用,哪些存在不解和困惑,哪些可能仍然处在游离状态(未击中目标)。

另外…

避免通过使用“你对…的第一印象”或“你对…的看法……”等方式询问测试者的想法。

测试者只会评价颜色方案、字体选择、布局和其他视觉设计元素。

虽然你可能会对这些信息感兴趣,但这不是你需要从可用性测试者那里听到的。

原文地址:https://userbrain.net/blog/write-better-tasks-to-improve-usability-testing

工作中在遇到大的产品改版,或者对某个设计拿捏不准的时候,经常会使用到可用性测试。在网上搜索可用性测试相关的文章,大多都描述的非常专业,很容易让初学者望而生畏,尤其是让很多初级产品经理或者小型初创公司觉得太专业没有资源,所以干脆不做。

而笔者的看法是这样的:

要做到完全符合流程和标准的可用性测试,确实有一定难度,需要的成本也很大,但是,需要注意的是:我们做可用性测试的目的不是“做可用性测试”,而是“发现用户真实使用情况中遇到的问题,来提升产品的可用性”,所以,目的最重要,只要能达到这个目的,流程完全不必如此复杂,有些可以省的步骤当然可以省,只要最重要的核心流程和注意点我们把握好即可。

另外,可用性测试一定要做,从原型设计到产品发布,任何阶段都可以做,有什么样的资源就做到什么样的程度。可用性测试是一种定性研究方法,有研究称,只要5个人就可以发现大部分共性问题,而这大部分共性问题,在版本发布前发现并解决掉,是一种非常节省资源,规避风险的方法,甚至有时候可以救产品一命。脑补一下,某个产品进行了一次大的改版,产品经理们觉得这次改版非常棒,老板也觉得很满意,然后释放给用户,用户反馈和数据都非常糟糕,那么这个时候,想要再补救,需要投入的成本就会非常大,最重要的是,用户很容易产生晕轮效应,使得产品其他优秀的点也会被牵连,这对于导入期和成长期的产品来说非常不利,很可能会导致用户的流失。原因很简单,产品经理往往对自己的产品太熟悉了,就会发生太多的想当然。

怎么做

下面,笔者将会走一遍标准的可用性测试流程,阐述一下那些必须做到的点,和那些大可不必较真的流程。

第一步:资源准备

资源准备包括测试环境和工具,包括办公室、观察间、网络、测试设备(手机、电脑等)、麦克风、录屏软件、屏幕共享软件、摄像机、眼动仪等。

这些资源里:办公室可以用会议室代替;测试人员和用户可以坐在一起,所以观察间可以不要;只要测试的功能不牵扯到网络使用,网络可以没有;屏幕共享软件和麦克风主要用于测试人员在观察室进行观察,也可以不要;眼动仪主要用于跟踪眼球运动,可以省略;录屏软件用于将屏幕记录下来,也可以省略,但是免费的录屏软件非常多,建议还是安装一个。那么剩下的,就是测试设备,测试设备当然是不能省略的了,因为这是测试的基础,用户总得有可操作的东西才可以进行测试。

可以看到,资源准备的时候,在最简陋的情况下,我们只要准备测试设备,和一个会议室就可以了,当然,测试人员需要准备纸笔做好记录。

第二步:任务设计

任务设计就是准备你要用户去做的事情,这一步当然是不可避免,而且必须去做好准备的,这样才能将每一次测试的收益最大化。

准备任务的时候,产品经理首先要明确一个问题:此次测试的目的是什么?是测试整个改版后的产品?还是测试某个功能的可用性?或者只是测试某个功能的视觉效果?

目的很重要,目的不同,我们设计任务的时候,问题的维度和场景就会有区别。

接下来根据我们的目的,来设计测试任务,这里有几个需要注意的点:

(1)一定要站在真实的用户场景来描述问题

比如:使用下XX产品的录音功能,这样可能看起来没什么问题,但是笔者在以前做可用性测试的时候,发现这种问题会使得用户操作起来没有明确的目的性,那么他们面对这种问题的时候,大部分用户都是瞎点击,随便点点就返回。如果我们这么问:假设你想用XX录音软件,录制一段歌声给你的男/女朋友表白;假设之前开会的时候,你通过录音机记录了会议过程,你现在想找到它并听会议内容。这两个问题就是有明确的用户场景,那么用户在操作的时候,我们观察到的也就是用户在真实生活中的实际可能的操作步骤,发现的问题也就是用户实实在在会遇到的问题。

(2)在问题描述的时候,千万不能有任何引导性语言

比如刚才这个寻找录音文件的例子,如果我们这样提问:假设之前开会的时候,你通过录音机记录了会议过程,请你现在进入录音列表,通过快速滚动条滑动找到它,然后点击听会议内容。这个问题就明确地引导用户怎么去操作,但是用户真实使用中,一定会这么做吗?也许用户根本不会用到快速滚动条?如果这么描述的目的是为了看用户使用快速滚动条的情况,那么最应该的做法是,不告诉用户滚动条的事情,让用户自己操作,看用户是否会发现快速滚动条,发现后是怎么操作。笔直之前做的一个可用性测试即是想看到用户对快速滚动条的使用情况,结果非常吃惊,大部分用户没有发现这个滚动条的存在,而发现的用户居然不会使用,或者不知道是快速滚动条。我想如果在测试前告诉了用户滚动条的事情,那么也就无法发现这些问题了。

第三步:用户招募

一般情况下,需要寻找产品的目标用户做可用性测试,我们可能需要在网上公开招募,或者通过公司的资料库联系用户等方法来寻找测试用户,但是很多情况下,我们无法快速寻找到合适的测试用户,这个时候其实不用那么死板,可以稍微转下脑筋,就近考虑,是不是前台小妹或者楼下保安也可以做为测试用户呢?再简单一点,隔壁产品组里,对我们产品不怎么了解的工程师是不是也可以呢?用户招募只是其中一环,我看到有些同事为了招募用户耽误了大量的时间,其实是得不偿失的,尽快进行测试的重要性更高,因为项目排期和交付日期可不会因为用户招募需要时间就延迟的,而如果因为用户招募导致没来得及做可用性测试,那真的是非常可惜了。

有数据称一般情况下,只需要五个用户即可发现大部分共性问题,但是如果找不到,根据经验三个用户也是可以发现大部分的严重问题,所以在用户招募方面,不要太严格和死板很重要。

第四步:测试执行

执行测试过程的时候,有观察室、录像机、屏幕共享软件等完备的测试环境当然最好,不过这里只描述最简单的情况:不需要主持人,产品经理做测试人员,一个会议室和一个测试设备。

首先,我们要向用户说清楚此次测试的目的,并记录下用户的基本情况,尽量以聊天的方式进行,让用户尽量放松,不要感到压力。如果用户很紧张,那么测试结果可能会大打折扣。另外,不要用太专业的术语和用户沟通。接下来我们就可以让用户按照之前准备好的测试任务进行操作,这个时候,测试人员需要在一旁用纸笔做好记录。

测试过程中,有一些点是测试人员一定要严格注意的:

(1)测试过程中,不要去打扰用户,也不要给用户任何提示,所有的问题都等到测试结束再进行询问和沟通

有时候在测试的时候,测试人员看见用户遇到了障碍便去进行提醒或者提问,这是不可取的方式,因为真实用户场景中,不会有人去提醒用户,而测试中所做的任何提示,都有可能导致问题无法暴露,这个时候应该做的事情是用纸笔记录下来,并在测试完成后,和用户进行沟通,询问用户当时在这里出现障碍是遇到了什么问题,当时自己是怎么想的。另外还存在一种情况,就是用户遇到问题的时候,会主动问测试人员,这个时候笔者给的建议是,直接回答用户:我也不知道。当然有一种极端的情况,用户实在是操作不下去了,那这个时候就必须给用户一点提示了,否则也许测试过程没法继续进行了,这个度需要测试人员自己做好权衡。

(2)测试人员要随时观察用户的表情

一般情况下,测试人员只会注意到用户操作过程中的操作手法,而不怎么注意用户表情。而很多情况下,用户可能遇到一些小的问题后,直接放弃操作去做其他事情,这个时候如果只看用户操作,可能会忽略掉这种问题,但是如果观察用户表情,可能会发现用户出现皱眉或者微笑等一些明显的表情变化,这个时候将用户表情和当时在进行的操作进行联系,测试完成后和用户进行询问沟通,往往可以发现一些问题或者一些惊喜。

(3)要求用户进行测试的时候,使用“发声思维”

很多时候,用户说的和做的是不一样的,而且在测试完成后,和用户再进行沟通,用户可能已经忘记了,那么他们这个时候的描述和当时的操作可能就会存在差异。而“发声思维”可以很大程度解决这个问题,即用户在操作的时候,让用户同时说出来,说出自己的思考过程,比如:自己要做什么事,先做什么,再做什么,为什么要这么做等。这个时候,一旁的测试人员只需要做好记录和观察即可。

第五步:报告呈现

报告尽量简短,形式不重要,重要的是内容和可读性,一般要包括测试对象的基本信息、测试的任务清单和测试结果、用户反馈以及问题整理整理和改进建议。

另外,笔者建议测试报告尽量包括测试过程的简单描述,对以后回顾问题的时候会有比较大的帮助,当然这部分可以不放到测试测试报告的正文里,如果用xls整理报告,可以在其他表单里记录。

最后一步:问题解决

这一步才是可用性测试最终实现它价值的地方。经过前面四步,我们已经得到了测试的结果,那么接下来就需要产品经理将这些问题进行归类,并进行需求分析和优先级评估,确定出需要修改的问题,进行排期,这就是产品经理的日常工作了。

最后的最后:其他需要注意的点

(1)针对某次发版的可用性测试一般建议不能做太晚,如果等到产品快上线了,才做可用性测试,并且发现了很严重的问题,那么这个时候就有点于事无补了。所以,在做可用性测试的时候,有产品就用产品测,有Demo就用Demo测,有原型就用原型测,什么都没有,也可用用竞品做测试,这样避免我们去 踩竞品的坑。

(2)可用性测试什么时候都可以做,要贯穿到整个产品的设计过程中,作为产品经理的一项基础日常工作,想想看,如果我们可以用上述的“简版”可用性测试方法,性价比还是很高的,比如笔者曾经做过一个可用性测试,用户招募就是简单的从公司里找了一些小白,测试的功能是通过带有时间的快速滚动条来快速定位图片(测试之前,快速滚动条的样式是半黑透明,上下端是两个小箭头,点击该滚动条出现时间,用户可以开始滑动,停止点击几秒后,时间消失)但是通过下面的测试结果看到,如果没有这次的可用性测试,那么这个功能释放给用户后的结果将是:无人使用。

而这整个测试过程,当时只花费了2个小时。所以“简版”的可用性测试的性价比真的非常的高。

(3)针对来测试的用户,在测试完成后,给用户一些实际的奖励,比如可以准备一些奖品或者纪念品给用户,也可以奖励用户一些产品的虚拟货币或者积分、虚拟宠物之类的,并且和用户进行友好的沟通,询问用户是否愿意接受以后的测试。这些都会更方便以后做可用性测试招募用户。

这些思考将分为五个点:

(1)预测试;

(2)尽可能邀请相关方参与;

(3)及时调整脚本;

(4)可用性问题的优先级排列;

(5)注意报告好的用户评价。

其中(1)和(2)是可用性测试之前的准备,(3)是可用性测试中需要注意的,(4)和(5)是可用性测试结束后需要注意的。下面将按照可用性测试前、中、后分别进行概述。

可用性测试之前

预测试

预测试是在正式可用性测试之前安排的一场模拟测试。

进行预测试的主要目的在于确保测试中的硬件和软件是否正常运行、脚本是否清晰、任务是否可行、访谈的问题设计是否合理和清晰等。如果遇到这些问题,要及时进行调整和修改,这样可以避免一些无效的测试或可能出现的错误,从而降低时间成

预测试可以找身边的同事,但这个同事不能是参与产品开发和设计的相关人员,可以考虑行政、后勤等非产品相关人员,测试和访谈结束后可给予一定的礼品或者请吃一顿饭。

尽可能邀请相关方参与

与产品相关的人员可能包括但不限于设计师、产品经理、研发、运营等。在进行可用性测试之前,尽可能提前通知相关方测试的时间和地点,并邀请相关方参与现场的观察。

邀请相关方现场参与是互利共赢的:对于用研来说,这是用研报告最终得到相关方理解并认可的方式之一,也利于用研后续工作;对于相关方来说,由于对产品非常了解,可能从测试中观察到主持人没有留意到的行为或态度,从而获得更多启发。

由于公司、项目和需求的不同,邀请的人也不同。这里需要明确的是,邀请合适的人来现场观察测试,比如我之前的项目最初是交互设计师想对某个页面各个功能点及页面布局的考察,最终邀请了3名交互设计师,当然也可邀请该页面所对应的产品经理和研发人员。如果相关方实在感兴趣,但临时又由于某些原因来不了,可以使用一些商业软件进行远程录制和播放的共享。

可用性测试之中

及时调整脚本

在可用性测试进行了几次后,可能会发现有些我们认为很重要的问题也许并不那么重要,有些我们认为不很重要的问题甚至很必要。或者发现了用户对于比较宽泛的问题存在疑惑、不解。或者发现了用户之间的一些共同趋势并希望了解这种趋势。这时,我们应该及时调整脚本,增加或删减一些内容,而不是继续按照原来的脚本进行。

定性研究是探索性的研究,目的在于构建理论,随着测试和访谈的进行,会产生一些新的想法,所构建的理论框架也会越来越清晰,这时就需要对原来的脚本进行细化。

如果有可能,我们可以每做完一次可用性测试都相应的调整一次脚本,虽然这种方式会相对较累,但也许可以给我们带来更多信息。

可用性测试之后

可用性问题的优先级排列

在测试完后会发现一系列可用性问题,理想的情况下,每个问题都希望在产品上线前被解决,但这是不现实的,究竟哪些问题先解决,哪些问题后解决呢?这时就需要对这些问题进行优先级排序,从而合理安排迭代和开发的顺序。

关于可用性问题的优先级排列,国际上有很多不同的评估指标和分级标准,本篇不再累述,可参考我微信公众号之前的一篇文章。这里想说的是,没有一个模型是通用的,我们需要找到最适合我们自己产品的模型,当然,也可以根据需要适当地修改指标或评级。

需要注意的是,可用性测试得到的问题优先级排列是用研人员基于用户的测试而给出的结果,这个优先级顺序并不是产品开发的实际优先级顺序。首先,用户对产品的认知和产品相关人员对产品的认知肯定是存在一定差异的。其次,这些问题的解决还需要考虑设计周期,开发周期,业务成本等。所以,用研应该和产品团队一起从用户的角度来理解这些问题的重要程度,再由相关人员决定实际的优先级排次序。

注意用户的正面评价

可用性测试可以测出产品或系统的一些问题,但是如果一份可用性测试报告通篇都是问题,可想而知,产品相关方或利益相关者在情感上肯定会很难受,想着自己辛辛苦苦做出来的东西,被批的一无是处。

在可用性测试中,当用户提到产品的某个或某些优点时,我们同样需要记下来,并在事后的报告中提及,特别是一些被多次提及的优点。这样做的好处有两点:

  1. 对于报告的接收者——产品相关方或利益相关者来说,心理上不会那么受挫,感受到用研的一种中立态度(优点缺点都有),会利于用研后续的合作和沟通;
  2. 引起对这些多次被提及的优点的重视,以免在后续的迭代版本中丢失

曾经在实习时看过不同人做的可用性测试报告,每个人做的报告都不一样。可以说,报告可用性测试结果没有绝对标准绝对正确的方法,重要的是选择一种方式,及时向相关人员呈现报告。

以上五点内容是在最近做项目中的一些感悟。

总体来说,可用性测试中会碰到很多细节,需要在做测试的过程中不断积累和思考,以便下次做的更完美。另外,如果有能力的,也可以推荐看看Jeff Rubin的那本《Handbook of Usability Testing》,本书对可用性测试的介绍非常详细。

如果你在做可用性测试的过程中,也有一些问题或者思考,欢迎随时留言讨论,期待思维的碰撞!

总结

如标题,可用性测试真的很难吗?我想看过这篇文章后,读者会有自己的见解。笔者在这里只需要强调一次前面已经说过的话:可用性测试一定要做,从原型设计到产品发布,任何阶段都可以做,有什么样的资源就做到什么样的程度

原创文章,作者:海阁,如若转载,请注明出处:http://www.pm28.com/1415.html

发表评论

电子邮件地址不会被公开。 必填项已用*标注

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息