小鱼|可用性测试你不知道的Buff

编辑导语：可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。每个产品的迭代都需要进行可用性测试，可以说“可用性测试”是交互设计中进行验证必不可少的环节。本篇文章分享了一些不一样的“可用性测试”技巧，希望对你有所帮助。

文章插图
之前群里的设计师提起了可用性测试，说面试的过程中被问到了，其实它的流程跟方法并不难，网上的教程资源也不少，很多参与过或了解过的人即使没有主导过却也能说个一二。
哪这门蕴含科学的测试研究方法真就这么简单? 借着这个机会结合个人的一点小心得，来聊一点不一样的“可用性测试”技巧。
一、可用性测试的应用场景与作用可用性测试(Usability Test)的应用场景是没有行业的明确界定的，它一般发生在产品研发上线的前中期，在功能或交互流程有待商榷之时，通过可用性测试可以获得更加真实的反馈来帮助决策或改进。
当然已上线的产品，同样可以使用可用性测试为下个版本优化迭代做投资。

文章插图
其中探索式跟验证式是常见的两个可用性测试类型，探索式适合企业对产品进行创新设计以迎合新时代发展的步伐与商业竞争力，验证式适合企业追求精益运营或增长设计。
对于可用性测试的概念，这里我用一段类比的情景来揭示出其中奥妙。
做好一个饭馆，而菜品必定是馆子的核心竞争力之一，菜不好吃，那就很难形成竞争力或留住客人，所以开发新的菜品或改进就很重要。
当厨师开发了新的菜品后，首先肯定是厨师们互相品尝，并不会直接上菜谱开售，这就像是内测过程，当厨师们觉得还可以时，就会找食客们进行免费试吃，通常这个时候厨师们需要食客们给出反馈或一定意见，如果食客们大多表示这个菜不错，下次还愿意吃，那么就是表示这个新菜品的可行性很高，用户满意度不错，就可以考虑对菜品优化上菜谱了。
而这个过程就像可用性测试一样，它为新菜品上菜谱降低了风险，为菜品对菜馆整体体验提升了保障，其中“菜馆的食客”就像是测试的目标用户，请求他们尝试新的菜品并给出意见，这便是招募用户和测试阶段，询问食客是否还会再点这个菜品，觉得这个菜品在什么价位区间，就算是对用户满意度或可行性衡量了。
相比专业可用性测试，只是少了更多的测试流程、测试技巧与科学严谨的分析汇报，但是基本概念是一致的。

文章插图
但值得注意的是针对单个菜品的研究并不是面向整个菜馆的，可用性测试很少用于研究用户对产品或服务的整体体验。
所以可用性测试的本质就很好理解了，以互联网产品为例，其实就是服务数字化后的功能与流程含有不确定性，而决定找到目标用户还原使用场景进行测试验证，以评测设计是否行得通、哪里需要改进，为功能上线减少风险加强容错，减少试错的成本。

文章插图
二、高保真原型与测试场景还原要测试就得有测试内容，所以测试对象是必不可少的内容，这个过程是我们还原真实用户在特定场景下进行产品体验的一系列问题反馈，那么为了尽可能的还原“真实”，肯定不能只是在用户的真实性上下功夫，接近真实的高保真原型就显得尤为重要。
以互联网产品来讲，还原一个可交互的高保真原型并不难，成本也不会很高，可能就是信息内容设计与素材准备会相对麻烦点，对于交互动效，基本可用就行，不必过分追求。
并且实现的工具也很丰富，对于大型框架原型可以使用“墨刀、MasterGo、AxureRP”等制作，小型精致的原型可以使用“Principle、Hype3、Flinto、Sketch、Keynote”等制作。
反而是工业产品设计的原型会比较麻烦，有的可能要出3D打印甚至开发测试样品，尽管这些工作会花费一定的时间与成本，但是从产品稳健发展的战略来看，这些投资是值得的，也是老板们可以接受的。

文章插图
在大多数的可用性测试文章或教程中，用户都是在一个相对降噪的会议室或实验室进行的，其目的是为了更好的布置设备用于过程的观察与记录，同时为用户测试减少干扰与评估难度（其实也省钱），但事实上还原产品服务的真实场景是很有必要的，并且一些产品服务自身就会含有一定的场景属性，所以你的测试环境就应该考虑接近真实场景的布置，甚至考虑跳出会议室、实验室。