可用性测试的权衡之道

《可用性测试的权衡之道》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、可用性测试的权衡之道对于可用性测试，业内人士存在一些普遍认可的原则。它们神圣地如同自然科学里的理论，似乎我们只能对其言听计从、俯首称臣才能践行出“好的可用性测试”。其实，即便是科学，它的一个特征也是“可证伪性”——理论的正确性总是存在前提条件的。真理再向前一步就成为谬误！可用性测试中的原则同样如此，需要根据目的、资源、环境的不同，灵活把握、权衡取舍，而非一味恪守某一个或某几个原则，也许这才是可用性从业人员经验重要性的体现。一．任务设置：精细VS宽泛制定的任务过于精细，一般原则上是反对的。理由很清楚，如果你的任务精细到一步一步“引导”用户进行操作，那太不符合用户现实中的使用情境，平时没有人

2、在旁边“引导”用户的每一步操作；而且过于控制用户的操作步骤，用户缺乏真实使用时的灵活性。是不是我们设置的任务只能是宽泛的，不能细化呢？这就必须根据研究的目的来做抉择。如果产品处在设计的初期，我们需要关注一些宏大的问题（如：网站的整体架构、导航和分类的合理性、页面的逻辑关系），此时就需要通过宽泛而有弹性的任务，来查找宏观层面的问题。如果产品的设计已经非常完善，开始进行细节的修改迭代，此时就需要通过设置相对具体的任务来查找特定的细节问题（如：对某个命名的理解、按钮的使用、链接的点击、表单的填写）。按照《Don’tmakemethink》一书的观点：一般用户使用互联网产品时满足于能用就行，不会

3、寻求最好的使用方法；只扫描网页，不会仔细阅读。所以，如果完全宽泛有弹性地设置任务，虽然更吻合实际使用情况，但是很可能用户直接跳过你想考察的细节。实际工作中，由于时间和资源的限制，无法做到每个产品从设计初期到上线前后进行多次可用性测试。可能在一次的可用性测试中即需要同时关注宏观方面和细节上的问题。此时，还是需要和产品经理、交互设计师反复沟通，确认测试的主要目的，同时通过对任务设置精细程度的权衡把握，使次要目的也尽量得以满足。不过，即便是想考察细节的任务，也要尽量避免“直接指导操作”式的语言描述方式，这样能让任务与真实使用情境不会相距太远。例如：想考察豆瓣读书页面【想要】按钮是否能被看到、是

4、否具备可点击感。下面列出两种表述方式，以作对比：A.请找到您喜欢的那本书，并在该页面点击【想要】。（×）B.请找到您喜欢的那本书，并在该页面对其作个标记。（√）二．任务数量：多VS少任务数量的多少与可用性测试考察范围有关，与任务的精细程度也有关。如果对网站全站进行考察和只对其中某个页面、某个操作流程进行考察，所需的任务数量自然不一样。在同样的考察范围下，如果任务设置得越精细，所需任务数量也就越多。Lindgaard和Chattratichart（2007）的研究发现任务数量与发现可用性问题比例存在显著的相关关系（r=0.82，p<0.01）。为了尽可能多地发现可用性问题，我们就尽量多地设

5、置任务给用户吗？此时要考虑任务数量过多可能带来的弊端：学习效应和疲劳效应，尤其是靠后的任务更可能会受影响。心理学实验中处理此问题的方法是顺序平衡，抵消影响。但是可用性测试中设置的场景和任务存在特定的先后次序，不适合采用顺序平衡的方法。基于我们的经验，还是通过对测试的任务数量进行控制，确保正式测试环节最多不超过1小时，加上前后的欢迎语、访谈、问答等，整个过程不超过1.5小时。此外，任务数量的多少还会间接影响到测试所需参与者数量的多少。三．用户人数：5个足够VS 5个不够Nielsen的研究发现，5个用户可以发现80%以上的可用性问题。这个结论得到许多人的推崇，因此称之为“魔法数字5”。这个

6、结论的来源依据是每个用户平均可以发现30%的可用性问题，且假设所有问题都有同等被发现的概率。不过，当设置的任务数量过多，且任务的精细程度和难度多种多样时，这个前提有可能不成立。Lindgaard和Chattratichart（2007）的研究发现测试用户数量与发现的可用性问题比例并不存在显著的相关关系。这个结论似乎又支持我们选择少量用户进行测试即可。其实，在用户招募阶段，比用户数量更需要重视是用户的代表性的问题。能否招募到有代表性的用户将直接影响可用性测试的成败。如测试一个医疗软件产品，招募到医护人员和患者作为测试用户，那5个用户可能就足够了；但如果只招募到医学实习生来测试，就必须超过5

7、个以上的用户（即便这样，也未必能推论到整个产品的用户群）。由此看来，招募用户的人数和任务的数量、精细程度、用户的代表性也是息息相关的。参考TomTullis（2009）和本人经验：当可用性测试范围限定在一定的范围（20个任务内、或30个网页之内），且招募到很强代表性的用户，那么5个足够了。如果存在着差别较大的亚群体，争取做到每个亚群组有5个左右的代表性的用户（当然，目标用户的特征及分类应该是在可用性测试之前的用户调研阶段就解决的问题