编辑导语：可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。每个产品的迭代都需要进行可用性测试，可以说“可用性测试”是交互设计中进行验证必不可少的环节。本篇文章分享了一些不一样的“可用性测试”技巧，希望对你有所帮助。
之前群里的设计师提起了可用性测试，说面试的过程中被问到了，其实它的流程跟方法并不难，网上的教程资源也不少，很多参与过或了解过的人即使没有主导过却也能说个一二。
哪这门蕴含科学的测试研究方法真就这么简单?借着这个机会结合个人的一点小心得，来聊一点不一样的“可用性测试”技巧。
一、可用性测试的应用场景与作用
可用性测试(UsabilityTest)的应用场景是没有行业的明确界定的，它一般发生在产品研发上线的前中期，在功能或交互流程有待商榷之时，通过可用性测试可以获得更加真实的反馈来帮助决策或改进。
当然已上线的产品，同样可以使用可用性测试为下个版本优化迭代做投资。
其中探索式跟验证式是常见的两个可用性测试类型，探索式适合企业对产品进行创新设计以迎合新时代发展的步伐与商业竞争力，验证式适合企业追求精益运营或增长设计。
对于可用性测试的概念，这里我用一段类比的情景来揭示出其中奥妙。
做好一个饭馆，而菜品必定是馆子的核心竞争力之一，菜不好吃，那就很难形成竞争力或留住客人，所以开发新的菜品或改进就很重要。
当厨师开发了新的菜品后，首先肯定是厨师们互相品尝，并不会直接上菜谱开售，这就像是内测过程，当厨师们觉得还可以时，就会找食客们进行免费试吃，通常这个时候厨师们需要食客们给出反馈或一定意见，如果食客们大多表示这个菜不错，下次还愿意吃，那么就是表示这个新菜品的可行性很高，用户满意度不错，就可以考虑对菜品优化上菜谱了。
而这个过程就像可用性测试一样，它为新菜品上菜谱降低了风险，为菜品对菜馆整体体验提升了保障，其中“菜馆的食客”就像是测试的目标用户，请求他们尝试新的菜品并给出意见，这便是招募用户和测试阶段，询问食客是否还会再点这个菜品，觉得这个菜品在什么价位区间，就算是对用户满意度或可行性衡量了。
相比专业可用性测试，只是少了更多的测试流程、测试技巧与科学严谨的分析汇报，但是基本概念是一致的。
但值得注意的是针对单个菜品的研究并不是面向整个菜馆的，可用性测试很少用于研究用户对产品或服务的整体体验。
所以可用性测试的本质就很好理解了，以互联网产品为例，其实就是服务数字化后的功能与流程含有不确定性，而决定找到目标用户还原使用场景进行测试验证，以评测设计是否行得通、哪里需要改进，为功能上线减少风险加强容错，减少试错的成本。
二、高保真原型与测试场景还原
要测试就得有测试内容，所以测试对象是必不可少的内容，这个过程是我们还原真实用户在特定场景下进行产品体验的一系列问题反馈，那么为了尽可能的还原“真实”，肯定不能只是在用户的真实性上下功夫，接近真实的高保真原型就显得尤为重要。
以互联网产品来讲，还原一个可交互的高保真原型并不难，成本也不会很高，可能就是信息内容设计与素材准备会相对麻烦点，对于交互动效，基本可用就行，不必过分追求。
并且实现的工具也很丰富，对于大型框架原型可以使用“墨刀、MasterGo、AxureRP”等制作，小型精致的原型可以使用“Principle、Hype3、Flinto、Sketch、Keynote”等制作。
反而是工业产品设计的原型会比较麻烦，有的可能要出3D打印甚至开发测试样品，尽管这些工作会花费一定的时间与成本，但是从产品稳健发展的战略来看，这些投资是值得的，也是老板们可以接受的。
在大多数的可用性测试文章或教程中，用户都是在一个相对降噪的会议室或实验室进行的，其目的是为了更好的布置设备用于过程的观察与记录，同时为用户测试减少干扰与评估难度（其实也省钱），但事实上还原产品服务的真实场景是很有必要的，并且一些产品服务自身就会含有一定的场景属性，所以你的测试环境就应该考虑接近真实场景的布置，甚至考虑跳出会议室、实验室。
这样的目的也是为了更加真实的还原使用场景，以取得更严谨科学的有效信息来赋能设计，这也是为什么大多数产品需要上前线测试的原因，就像药品诞生于实验室，上架于临床一样，例如出行、运动相关产品，如果依旧停留在写字楼里测试实验，那就是闭门造车。
三、任务与指标定制化设计
产品的本质是为用户提供服务，用户会为了达成自己的某个目标或需求而花费时间使用产品，而我们需要用户测试一系列功能来评测是否能够协助完成目标任务。
所以我们在设定不同任务的时候应该以某个用户需求或目标为导向来驱动用户使用产品功能，而不是系统的指出完成那些操作任务，那样没办法深入挖掘真实有效的信息。
所以在向用户颁布测试任务的时候，我们应该为用户建立一些任务背景，并且尽可能看起来真实可靠，容易接受和共情，甚至你可以在测试前的暖场环节，根据此次的功能作用推导一些使用场景和需求，并与用户进行简单交涉，看看那些需求很有可能发生在用户身上，并以此需求目标来调整任务的话术来驱动用户完成测试。
值得注意的是如果测试的部分比较明确，那么你的任务目标也应该尽可能的聚焦或明确下来。
好了，为了方便理解我要说人话了。
（1）重点补充
因为在整个测试的过程中，参与测试的用户不止一个，所以在了解用户情况后，可以综合一下共同的特征再去提炼优化任务目标，以保证在多个参与者中维持评估的一致性。
并且任务目标应该尽可能的准确有效，我们是要测试新的拍摄识别功能，那我们就应该要求出来，而不是说看完书后使用APP的笔记并尝试各种功能支持，产品或功能所没有的就不要提。不保证有效性，最后也只能让用户感到困惑而已。
通常完成测试任务的过程中，会涉及到多个功能之间的交互，所以任务目标涉及的多个阶段应该贴合实际的操作顺序或流程规范，另外尽可能的避免专业术语的出现，务必考虑“适老化”一下。
（2）关于指标定制化
通常在可用性测试中，是否可用的指标被划分成了三大面：有效性、任务效率、满意度，对于这三方面我们可以继续细化成若干个二级指标用于界定产品可用性。
至于你家的产品是什么行业、什么阶段、什么用途、有何特性，应该满足哪些指标为可用，我就不深入了，相信大家心里都有数。
简言之核心就是考虑产品的特性与阶段，灵活的配置可用性的指标，这里整理了些常见的指标与说明用于参考。
四、用户测试中常见的问题
尽管我们有测试脚本甚至测试排练，已经尽可能的保障了可用性测试的稳定可靠，但实际上在用户测试的阶段还是会出现各种问题，用户像一个熟睡的婴儿，何时醒来何时哭泣不可预见，所以这就要求测试的主持人能够灵活变通，同时在技巧上符合可用性测试的科学严谨。
可用性测试过程中的科学严谨一方面体现在方案的合理性、测试主持的技巧上、及评估分析量化的方法上，这些大多可用性测试的文章或教程中都会提到，这里就不展开啰嗦了。
常见问题举例：
1.他似乎在想些什么但是没有说出来？
你在想什么可以分享一下吗？
2.用户好像卡住了或遇到bug了。
这没事儿，是我们产品设计的问题，你可以考虑跳过这一步好了。
3.就是这个，它怎么就那啥了？表述不清。
你刚刚打算做些什么，如果是你，你准备怎么去设计？有没有一些参考。
4.然后我要怎么做呢？
对于用户提问说明遇到了障碍，尝试反问你平时会怎么做？
5.用户反馈了一些趋势或点子，看起来很有价值。
尝试深挖，顺着点子或趋势向用户多问一点，但是不要直接问“为什么”，可以尝试问好在哪里或者哪里不好，让问题更有头绪一点。
以上不难看出，即使有了脚本，但是用户依旧是一个变量因素，所以脚本依旧需要不断调整，也只有去调整才能更好的保障测试结果的有效性，同时主持者也需要随时准备灵活的应对各种幺蛾子。
五、创新与颠覆性设计如何测试
可用性测试被很多人视为评估体验的制胜法宝，但实际上很多产品在行业中已经逐步成熟，并有大企业花费大量资源进行研究摸索，让生态系统更进一步，所以说要是你的产品没有特殊的创新或瓶颈，而是传统的功能研发，其实并不一定要花费成本去做可用性测试，直接按照行业标杆也是没问题的。
那么你的产品就是有创新或颠覆性设计怎么办？
通常这个时候就会面临一个问题，打破传统或者颠覆用户的常识。类似这种颠覆式或创新技术其实非常多，例如按键手机一下到了触屏时代、智能驾驶、语言助手的诞生、刷脸支付等，这对企业是机会也是风险，所以在进行可用性测试的时候也会有些不大一样的地方。
我们悉知在可用性测试的三大指标中就有一项是“效率”，对此也会有一些完成任务的时间作为指标，这些指标通常是根据内部人士或专家完成任务的时间乘上2倍或者更多倍做为一个评测指标。
但是对于颠覆性的变化，我们需要给用户首次测试留出更多的时间去学习去适应，在此之后，可以让用户再进行1～2次的测试，并且比较多次任务完成的时间变化，如果时间能够大幅度缩减且完成任务，那就表示可用，而这样做也是为了保障测试的科学严谨性，以避免学习门槛对创新性的评测影响。
六、多版本Battle你需要小型可用性测试
可用性测试需要招募用户进行测试，预算时间精力可谓一项都不能少，但是大多公司的窘境却是公司小资源又有限，又不给预算招募，可用性测试做不起来？内部产出版本过多，不知何去何从？别担心，小型可用性测试了解一下！
1.什么是小型可用性测试(SmallUsabilityTest)？
小型可用性测试就是在标准的可用性测试的基础上减少了一些流程与要求，这就像是大公司与小公司之间会有各自的研发流程一样，两者各有千秋，对应公司规模与背景对症下药。
在小型可用性测试中，也有脚本、简易的暖场、用户定义、测试目标、测试任务、测试原型、测试参与者、测试观察、思考总结，更多的也是发生在功能上线之前的推敲阶段，它比较适合设计师在自测阶段后的验证以及多版本Battle，帮助你Pick一套更加合适的方案。
但是整个过程相对正式可用性测试会更加简单易行，其中价值观念与目的都是一致的，都是以用户价值与用户目标来驱动（使用动机）使用产品，并且观察用户的使用过程以获取有效的反馈来改进或决策。
不过呢，脚本会更加简易一些，原型材料也不用那样精细，主要能表达功能作用与信息流程为主，其中测试者更多的是寻求那些关心我们产品或有需求的用户，另外也不会准备那些知情书、协议、录制设备、测试指标啥的，更多的是寻求熟人或哪些有意向的用户快速进行测试并观察，这样不仅时间成本都节省了，难度降低了，也能拿到一定的有效测评结果。
基本上主要的实践步骤就这五点，还有一些布置会穿插在其中，后面代入案例讲解一下。
2.案例代入讲解
便于直观的了解和感受小型可用性测试，这里代入一个老案例讲解一下，关于案例背景这里简单交代一下。
（1）背景
平台服务于游戏相关的订单交易、互动娱乐，本次测试的内容是新的游戏订单定制服务，通过推出一批专供用户定制游戏服务的客服来完成沟通与定制下单，其价值在于帮助用户快速了解平台游戏服务以及快速定制服务并完成下单转化，以沟通的方式减少用户下单的操作流程与门槛。
（2）任务流程
设计服务入口与流量分发-用户选择心仪的小鱼（专供客服的代称）-进入小鱼的会话界面-沟通需求目标-小鱼制定用户专属服务订单-用户支付确认-转到订单流程
为了加快讲解和体现测试的价值与方法，这里就不跑全套流程了，就以小鱼入口的设计与流量分发来代入讲解，测试前提是聊天会话界面中已经集成了“小鱼”所受理的主要游戏业务介绍，以及快速下单的入口。
当然一般都是在用户向“小鱼”倾述目标需求后，由“小鱼”进行服务定制，并向用户发起订单等待用户确认支付，之后便是等待订单完成到验收评价，平台转交佣金。
（3）首先定义用户与目标
在这个测试任务开展前一定要知道开展目的是什么，然后就是这个过程中你的功能或产品是为什么样的人服务，能为他们带来什么样的价值，也就是前面一直提到的价值与目标驱动用户的概念。
为此你可以建立一个简易的用户原型来定义用户的特征属性，使得目标群体再具体一些。
然后将小鱼的服务价值写出来，让参与者能够快速知道小鱼功能有什么用：
（4）创建适用于目标的测试任务
对于测试任务的创建，应该是围绕目标的。
根据流程的多少或复杂程度，可以划分为多个阶段，这样具有阶段性会更好控制测试节奏或分段进行，然后就是将多个任务按照流程顺序或是操作难度排序，目的是使得任务流程正确或是用户接受起来更容易。
当你把任务清单罗列出来后还不算完，这套清单你可以放在脚本里，但是当你描述给用户时，你应该代入对方视角去描述并且带有目标性，所以还需要进行一次调整后应用：
（5）找到合适的测试参与者
关于参与者我们会参考第一步中所设定的用户原型，不需要全部中标，但至少这些人要看起来会用得上你的产品才行，通常这些人建议通过熟人关系去寻找，甚至可以是你的同事，只要他们对产品没有额外的偏见，且不是相关设计者、营销运营者或技术研发人员，因为这些人对该领域的知识掌握甚多，有失真实性。
当你找到这五六个接近真实用户的参与者后，你只需要将起初写下的“功能价值阐述”告诉他们，让他们知道要做一个怎样的服务测试，然后预约他们在不同的时间节点上花费半个小时来做一个简单的功能测试即可。
（6）观察参与者如何执行任务
在这个阶段，你需要保证已经准备好了测试原型，以及一份脚本，脚本中会规范以上的功能价值、测试任务、一些简易的指标、