V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
spasvo
V2EX  ›  问与答

可用性测试的五点思考

  •  
  •   spasvo · 2016-10-28 16:31:06 +08:00 · 943 次点击
    这是一个创建于 2800 天前的主题,其中的信息可能已经有所发展或是发生改变。

    可用性测试的五点思考

    可用性测试( Usability testing )是用来评估产品或系统的一种方法,这种方法起源于经典的实验学,可以进行复杂的大样本测试,也可以进行简单的小样本定性测试。关于可用性测试的具体内容( 5W+1H ),网上已经有很多资料,包括中文和英文。我想了下,在这里,还是不再写普适性的科普文章,而是决定从近期做的可用性测试项目中提取一些个人思考,来与大家分享。   这些思考将分为五个点:( 1 )预测试;( 2 )尽可能邀请相关方参与;( 3 )及时调整脚本;( 4 )可用性问题的优先级排列;( 5 )注意用户的正面评价。其中( 1 )和( 2 )是可用性测试之前的准备,( 3 )是可用性测试中需要注意的,( 4 )和( 5 )是可用性测试结束后需要注意的。下面将按照可用性测试前、中、后分别进行概述。   可用性测试之前   预测试   预测试是在正式可用性测试之前安排的一场模拟测试。进行预测试的主要目的在于确保测试中的硬件和软件是否正常运行、脚本是否清晰、任务是否可行、访谈的问题设计是否合理和清晰等。如果遇到这些问题,要及时进行调整和修改,这样可以避免一些无效的测试或可能出现的错误,从而降低时间成本。   预测试可以找身边的同事,但这个同事不能是参与产品开发和设计的相关人员,可以考虑行政、后勤等非产品相关人员,测试和访谈结束后可给予一定的礼品或者请吃一顿饭。   尽可能邀请相关方参与   与产品相关的人员可能包括但不限于设计师、产品经理、研发、运营等。在进行可用性测试之前,尽可能提前通知相关方测试的时间和地点,并邀请相关方参与现场的观察。   邀请相关方现场参与是互利共赢的:对于用研来说,这是用研报告最终得到相关方理解并认可的方式之一,也利于用研后续工作;对于相关方来说,由于对产品非常了解,可能从测试中观察到主持人没有留意到的行为或态度,从而获得更多启发。   由于公司、项目和需求的不同,邀请的人也不同。这里需要明确的是,邀请适合的人来现场观察测试,比如我之前的项目最初是交互设计师想对某个页面各个功能点及页面布局的考察,最终邀请了 3 名交互设计师,当然也可邀请该页面所对应的产品经理和研发人员。如果相关方实在感兴趣,但临时又由于某些原因来不了,可以使用一些商业软件进行远程录制和播放的共享。   可用性测试之中   及时调整脚本   在可用性测试进行了几次后,可能会发现有些我们认为很重要的问题也许并不那么重要,有些我们认为不很重要的问题甚至很必要。或者发现了用户对于比较宽泛的问题存在疑惑、不解。或者发现了用户之间的一些共同趋势并希望了解这种趋势。这时,我们应该及时调整脚本,增加或删减一些内容,而不是继续按照原来的脚本进行。   定性研究是探索性的研究,目的在于构建理论,随着测试和访谈的进行,会产生一些新的想法,所构建的理论框架也会越来越清晰,这时就需要对原来的脚本进行细化。   如果有可能,我们可以每做完一次可用性测试都相应的调整一次脚本,虽然这种方式会相对较累,但也许可以给我们带来更多信息。   可用性测试之后   可用性问题的优先级排列   在测试完后会发现一系列可用性问题,理想的情况下,每个问题都希望在产品上线前被解决,但这是不现实的,究竟哪些问题先解决,哪些问题后解决呢?这时就需要对这些问题进行优先级排序,从而合理安排迭代和开发的顺序。   关于可用性问题的优先级排列,国际上有很多不同的评估指标和分级标准,本篇不再累述,可参考我之前的一篇文章 [可用性问题的优先级评估] 。这里想说的是,没有一个模型是通用的,我们需要找到最适合我们自己产品的模型,当然,也可以根据需要适当地修改指标或评级。   需要注意的是,可用性测试得到的问题优先级排列是用研人员基于用户的测试而给出的结果,这个优先级顺序并不是产品开发的实际优先级顺序。首先,用户对产品的认知和产品相关人员对产品的认知肯定是存在一定差异的。其次,这些问题的解决还需要考虑设计周期,开发周期,业务成本等。所以,用研应该和产品团队一起从用户的角度来理解这些问题的重要程度,再由相关人员决定实际的优先级排次序。   注意用户的正面评价   可用性测试可以测出产品或系统的一些问题,但是如果一份可用性测试报告通篇都是问题,可想而知,产品相关方或利益相关者在情感上肯定会很难受,想着自己辛辛苦苦做出来的东西,被批的一无是处。   在可用性测试中,当用户提到产品的某个或某些优点时,我们同样需要记下来,并在事后的报告中提及,特别是一些被多次提及的优点。这样做的好处有两点:一,对于报告的接收者——产品相关方或利益相关者来说,心理上不会那么受挫,感受到用研的一种中立态度(优点缺点都有),会利于用研后续的合作和沟通。二,引起对这些多次被提及的优点的重视,以免在后续的迭代版本中丢失。 曾经在实习时看过不同人做的可用性测试报告,每个人做的报告都不一样,可以说,报告可用性测试结果没有绝对标准绝对正确的方法,重要的是选择一种方式,及时向相关人员呈现报告。 本文转自: http://www.spasvo.com/news/html/20161027105412.html

    目前尚无回复
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2599 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 06:30 · PVG 14:30 · LAX 23:30 · JFK 02:30
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.