可用性测试

[帝国文明]

可用性测试就是让一群具有代表性的用户对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。 要做到完全符合流程和标准的可用性测试，确实有一定难度，需要的成本也很大，但是，需要注意的是：我们做可用性测试的目的不是“做可用性测试”，而是“发现用户真实使用情况中遇到的问题，来提升产品的可用性”，所以，目的最重要，只要能达到这个目的，流程完全不必如此复杂，有些可以省的步骤当然可以省，只要最重要的核心流程和注意点我们把握好即可。 另外，可用性测试一定要做，从原型设计到产品发布，任何阶段都可以做，有什么样的资源就做到什么样的程度。可用性测试是一种定性研究方法，有研究称，只要5个人就可以发现大部分共性问题，而这大部分共性问题，在版本发布前发现并解决掉，是一种非常节省资源，规避风险的方法，甚至有时候可以救产品一命。 脑补一下，某个产品进行了一次大的改版，产品经理们觉得这次改版非常棒，老板也觉得很满意，然后释放给用户，用户反馈和数据都非常糟糕，那么这个时候，想要再补救，需要投入的成本就会非常大，最重要的是，用户很容易产生晕轮效应，使得产品其他优秀的点也会被牵连，这对于导入期和成长期的产品来说非常不利，很可能会导致用户的流失。原因很简单，产品经理往往对自己的产品太熟悉了，就会发生太多的想当然。 可用性测试什么时候都可以做，要贯穿到整个产品的设计过程中，作为产品经理的一项基础日常工作，想想看，如果我们可以用上述的“简版”可用性测试方法，性价比还是很高的，比如笔者曾经做过一个可用性测试，用户招募就是简单的从公司里找了一些小白，测试的功能是通过带有时间的快速滚动条来快速定位图片（测试之前，快速滚动条的样式是半黑透明，上下端是两个小箭头，点击该滚动条出现时间，用户可以开始滑动，停止点击几秒后，时间消失）但是通过下面的测试结果看到，如果没有这次的可用性测试，那么这个功能释放给用户后的结果将是：无人使用。