• home > design > ID >

    可用性测试非典型应用

    Author:[email protected] Date:

    可用性测试(Usability Test)作为用户研究方法体系中,过程相对最为成熟可控,输出最为显性的方式之一而被广泛使用。甚至在一个已有产品形态团队接触用户研究工作初始,常以它去试水去研


    可用性测试(Usability Test)作为用户研究方法体系中,过程相对最为成熟可控,输出最为显性的方式之一而被广泛使用。甚至在一个已有产品形态团队接触用户研究工作初始,常以它去试水去研究双方的合作方式,普及可用性知识,了解彼此对产品的思维角度。

    然而今天要说的,并不是UT执行细节上的思考(若对执行方法有兴趣可点击http://ucdchina.com/topic/99)。今天想分享的,在个人实际工作中,一些非典型情况下使用可用性测试的方法后,取得意想不到结果的情况。

    首先,回顾下可用性测试的特点是什么?

    这个问题,研究员们应该都情不自禁背了出来:是从真实用户那儿获得的问题,更加真实客观;不仅能获得问题,还能知道问题背后用户的思考(原因);是真实情景下获得的问题,更加有价值(但对于普通软件类产品,现在更多在实验室测了)……

    再想想,除去这些显性的优点,还有什么隐性特点?

    我们不妨再回顾下UT的执行过程:一名用户在合适的环境下,通过主持人引导完成一系列任务操作,并(通过引导)告诉主持人自己在每个步骤/页面上的思考和疑惑。

    因此,可用性测试的另外两个特点是:

    1、结构化认知:由于主持人在场,被测会严格按照场景任务完成操作,覆盖了产品主要功能下的主要路径,并且在每步操作中,都会有人追问从而导致产生较强烈印象。使得被测在短短几十分钟后,对产品能有个较深刻的、结构化认知。
    2、微观层面的客观思考:我们平时都说,可用性测试的一个优点是数据足够客观,但这多是对数据收集者而言。其实对于被测自己而言,通过他人引导/追问,对自己的感性认识进行理性拆分,更是一种震撼的过程。全程就像接受了一次心理咨询,让自己的喜好感受层层剥开,最后产生“原来我是这样看待问题的,是因为XX才觉得好/不好”的感受

    那么,通过上述两个特点,UT还可以在什么时候(可能)发挥出作用呢?

    实践,个人尝试过的4个非典型场景

    下述是个人尝试过的一些非典型场景,仅供参考。

    1、影响高层领导

    典型问题:有没有遇到过这样的情况,领导对自己的产品都是浅使用,但是一旦有些零散感受就开始点评一通,下达的修改意见往往不符合经理的长远规划,让本就焦头烂额的产品经理(们)更加头痛。

    邀请领导作为被测试人,是为了让领导对产品形成结构化认知,并潜移默化的和领导互通信息

    优点

    1、有助PM项目规划:领导在认真的完成主要功能操作后,更明白产品的功能形态,明白哪些地方才是体验差异化的发力点,这对产品后期规划简直有莫大帮助

    2、让领导冷静思考:这恐怕是唯一的机会,领导能够平等的坐下来,在专门的主持人引导下,进行更为客观的思考,真正评估一下产品细节,而非上来就表扬或痛批

    3、有助于PM大革新探底:在对一款产品进行大革新前,产品人员往往希望知道领导对上一代产品真实看法,和这次革新有什么底线。这些都可以通过测试获得

    风险与难点:

    1、不适合现有团队的不成熟产品:可用性测试是发现问题的,领导发现这么多不足后可能冲冠一怒。所以要么产品比较成熟,要么是新团队推翻重做时比较适合

    2、领导不愿意花费时间:领导们都忙得来去无踪的,在引起足够重视前可能不愿意参与。这时需要有推动力的人让领导知晓,平时冗长而低效,动辄几个小时的XX讨论会其实弱爆了。通过一次测试,说不定就能有个客观全面认识哦亲。

    2、帮产品经理理清思路

    典型问题:如果你是一名交互设计师,最常抱怨的多半是产品经理思路不清晰,造成需求经常变更;或者不知道产品经理的长远规划,无法把握节奏;而对产品经理而言,在忙得七晕八素各种信息扑面而来时,或许自己本来就没有总体规划

    邀请产品经理作为被测试人,目的是帮其进行信息总结和打破固有思维

    优点:

    1、信息总结:产品经理们是最忙的一群人,事情过杂造成信息碎片化,对产品把握虽细但散;而在平时工作环境中,和其他忙碌的PM们讨论,也多非体系化通过一次可用性测试,让自己安静下来按主要功能/流程走一遍,有个重新思考和总结

    2、打破固有思维:产品经理和产品接触最久,很容易对(特别是新手问题)敏感度降低,或对产品形态有了固有思维。平时疲于应对各方看法和意见,自己都不知道该怎么看了。而当被他人引导说出来的一刹那,反而比较清楚。

    风险与难点:

    1、很难测出问题:这点其实在测试之前明确就好。对于产品经理来讲,很难测出可用性问题(特别是流程问题),主要目的还是辅助梳理思路。而且交互设计师和产品经理相左的问题,也可以提前告诉研究员,你懂的(just kidding:))

    3、作为头脑风暴的主持形式

    典型问题:在产品组日常讨论时,往往是针对几个主要功能点,以散点或者页面为单位进行讨论,进行点对点的头脑风暴。由于缺乏专门的主持人,讨论时部分人参与感不强,或者场面容易跑题,或者容易被一两个强势产品经理主导

     将UT的主持形式引入头脑风暴,主要是引入一种讨论路径、和更客观的主持人

    优点

    1、以任务为单位的讨论路径:在产品组的讨论中,缺乏严格按场景任务的讨论路径方式,当讨论是以覆盖面广为目的时可以理解,否则以完整的任务为路径讨论时会更加make sense

    2、更客观的主持人和提问方式:产品组讨论时多半由最有经验的PM来主导,有时难免遇到某些产品经理过于强势,而引入一个更客观,有主持经验的主持人,更能保证每个人客观表达;此外,产品经理的讨论很容易直接进入设计,通过主持人引导,先对问题本身进行讨论也会更有意义

    风险与难点

    1、主持人能力对效果影响很大:显然的,要对一群产品经理组织头脑风暴,一方面要对产品熟悉不亚于产品经理,另一方面要有极强的场控能力,才能把强势的产品经理拉得回来

    4、可用性专家测试

    典型问题:在定性方法中,常用的是专家评估和可用性测试。当产品经理希望获得一些创意性意见(而非只是可用性问题)时,常常会寄希望于资深人员的评估。但由于日复一日进行可用性/设计相关工作,UX人员有时难免对创新出现疲态。

     

    让可用性专家作为被测参与测试,还是归为专家评估,主要是激发可用性人员思考激情

    优点

    1、保持可用性人员思考激情:如果你是一名UX从业人员,相信会有这样的体会,在天天研究各种产品可用性之后。敏感度虽然高,但是表述的欲望有时反而降低,对产品评估出现疲态。毕竟在可用性人员眼里,普天之下无不是错误百出的产品。但如果有人和自己进行深度沟通,不断去挖掘和总结自己说的话,则有助于保持思考的欲望。

    2、完整的路径走查方式:无论是研究员还是设计师,在经验越多情况下,有时反而难以沉下心完全按任务路径进行走查。而当有主持人在场的话,则可以避免这个问题,会在交流中对每个步骤的微观层面都进行思考。

    风险和难点:

    1、只作为专家评估使用:毕竟是可用性专家作为被测,结果切勿作为可用性测试使用。不然很可能让人质疑公正性。若定位成一种创意输入的方式,则会在发现点的数量和质量上收获颇丰

    总结

    以上是笔者对于可用性测试的形式,在一些非典型情境下使用后的心得,效果并未进行严格的实验量化,权当一些跨界实验。
    总结一下,可用性测试的跨界使用,主要是对被测试者而言,通过几十分钟的深度交流,被灌输信息、客观的理清自己真实想法,并对信息进行结构化的总结。因此,但凡存在上述需求的场景,都可以尝试使用。
    需要说明的是,上述场景的执行过程,难免遇到各种实际问题。方法有风险,尝试需谨慎。

    欢迎探讨

    个人邮箱:liuke-ued#360.cn
    新浪微博:www.weibo.com/newco318


    转载本站文章《可用性测试非典型应用》,
    请注明出处:https://www.zhoulujun.cn/html/design/ID/2016_0202_496.html