对于可用性测试，业内人士存在一些普遍认可的原则。它们神圣地如同自然科学里的理论，似乎我们只能对其言听计从、俯首称臣才能践行出“好的可用性测试”。其实，即便是科学，它的一个特征也是“可证伪性”——理论的正确性总是存在前提条件的。真理再向前一步就成为谬误！
可用性测试中的原则同样如此，需要根据目的、资源、环境的不同，灵活把握、权衡取舍，而非一味恪守某一个或某几个原则，也许这才是可用性从业人员经验重要性的体现。
一．任务设置：精细 VS 宽泛
制定的任务过于精细，一般原则上是反对的。理由很清楚，如果你的任务精细到一步一步“引导”用户进行操作，那太不符合用户现实中的使用情境，平时没有人在旁边“引导”用户的每一步操作；而且过于控制用户的操作步骤，用户缺乏真实使用时的灵活性。
是不是我们设置的任务只能是宽泛的，不能细化呢？这就必须根据研究的目的来做抉择。如果产品处在设计的初期，我们需要关注一些宏大的问题，此时就需要通过宽泛而有弹性的任务，来查找宏观层面的问题。如果产品的设计已经非常完善，开始进行细节的修改迭代，此时就需要通过设置相对具体的任务来查找特定的细节问题。
二．任务数量：多VS少
任务数量的多少与可用性测试考察范围有关，与任务的精细程度也有关。如果对网站全站进行考察和只对其中某个页面、某个操作流程进行考察，所需的任务数量自然不一样。在同样的考察范围下，如果任务设置得越精细，所需任务数量也就越多。
Lindgaard和Chattratichart（2007）的研究发现任务数量与发现可用性问题比例存在显著的相关关系（r=0.82，p<0.01）。为了尽可能多地发现可用性问题，我们就尽量多地设置任务给用户吗？
此时要考虑任务数量过多可能带来的弊端：学习效应和疲劳效应，尤其是靠后的任务更可能会受影响。心理学实验中处理此问题的方法是顺序平衡，抵消影响。但是可用性测试中设置的场景和任务存在特定的先后次序，不适合采用顺序平衡的方法。基于我们的经验，还是通过对测试的任务数量进行控制，确保正式测试环节最多不超过1小时，加上前后的欢迎语、访谈、问答等，整个过程不超过1.5小时。
此外，任务数量的多少还会间接影响到测试所需参与者数量的多少。
可用性测试的主要目的虽然是发现问题，但也需要了解问题背后的原因，而仅仅依靠观察用户的操作行为是无法获悉所有问题背后的原因的，此时，我们就希望用户能采用“出声思维法”，出声思维就是集中于如何与产品进行交互的意识流。如果测试中的氛围比较平等、自然、融洽，用户又特别愿意表达，那么用户就会在进行任务操作同时，表达他们想做什么、打算如何做、背后的原因是什么。此时，不仅是操作行为、用户表达出来的想法和原因、以及语言中透露出的疑惑、失望、不满、惊讶、犹豫等情绪同样是需要我们加以关注的。但是，有些用户比较内向，不善于主动表达自己的想法，此时就需要主试跟他进行简单的交流，以引导用户说出背后的原因。
所以，在实际的可用性测试，基本应该以关注用户的行为为主，少量、适时地进行询问交流也是需要的。但这个度如何把握呢？
1.当用户出现犹豫、惊讶、任务失败（过程节点上出现自然而然地稍微中断/暂停）的时候才进行简单的询问。
2.询问采用一般疑问句的句式，重复用户刚才的行为表现（要具体客观）：“你刚才没有……，是吗？”——虽然没有直接问“为什么”，但暗示了希望听到他进一步的解释。
3.如果用户没有自己主动说出原因，可以“顺便”问一下“为什么？”或通过身体前倾、目光注视等非语言方式来暗示用户你希望能听到更多内容。若用户很快、坚定地说出原因，则该理由的可信度较高；如果用户犹豫、或难以说出原因，就不要继续追问。
冀公网安备 13010402001110号
