360UXC-可用性测试非典型应用

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

总结

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