微信扫码登录

其他登录方式

绑定手机号

注册

我同意用户协议

忘记密码

用户协议

绑定手机号

近期有不法分子打着爱盈利的旗号,制作“爱盈利”名称的App,并伪造爱盈利证件,骗取用户信任,以抖音点赞赚钱或其他方式赚钱为名义,过程中以升级会员获得高佣金为名让用户充值。
爱盈利公司郑重声明:我司没有研发或运营过任何名为“爱盈利”的APP,我司做任务赚钱类产品从没有让任何普通用户充值升级会员。我公司产品均在本网站可查询,请将网站拉至底部,点击“关于我们”可查看爱盈利相关产品与服务。
温馨提示:当遇到此类问题请拨打官方电话或添加官方微信,以免财产损失。爱盈利官网地址:www.aiyingli.com。
  • 推广与合作
X

在近期做的可用性测试项目中,我的五点思考

来源:小释界 2304

6 (2)

可用性测试(Usability testing)是用来评估产品或系统的一种方法,这种方法起源于经典的实验学,可以进行复杂的大样本测试,也可以进行简单的小样本定性测试。关于可用性测试的具体内容(5W+1H),网上已经有很多资料,包括中文和英文。我想了下,在这里,还是不再写普适性的科普文章,而是决定从近期做的可用性测试项目中提取一些个人思考,来与大家分享。

这些思考将分为五个点:

(1)预测试;

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

(3)及时调整脚本;

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

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

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

可用性测试之前

预测试

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

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

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

尽可能邀请相关方参与

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

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

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

可用性测试之中

及时调整脚本

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

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

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

可用性测试之后

可用性问题的优先级排列

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

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

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

注意用户的正面评价

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

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

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

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

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

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

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

分享干货我们是认真的,更多干货尽在爱盈利!

评论

相关文章推荐

SELECT dw_posts.ID,dw_posts.post_title,dw_posts.post_content FROM dw_posts INNER JOIN dw_term_relationships ON (dw_posts.ID = dw_term_relationships.object_id) WHERE 1=1 AND(dw_term_relationships.term_taxonomy_id = 3312 ) AND dw_posts.post_type = 'post' AND (dw_posts.post_status = 'publish') GROUP BY dw_posts.ID ORDER BY RAND() LIMIT 0, 6

京ICP备15063977号-2 © 2012-2018 aiyingli.com. All Rights Reserved. 京公网安备 11010102003938号