可用性测试的权衡之道(3)

　　六.研究方法：定性 VS 定量

　　可用性测试，很多时候被认为是一种定性研究方法;但也有人说它是一种定量研究方法。究竟是怎么回事呢?

　　个人认为，可用性测试实质上结合了定性和定量两种方法的特点，到底哪种成分更多，要看你的使用目的以及细节上如何操作。

　　定量研究的思路是基于对一定数量样本的测量，以将研究所得的结论推广至总体。除了强调样本的代表性，还对样本的数量有具体的要求，同时会考虑抽样误差、置信度、置信区间的度量。并且定量研究过程中非常注重对某些自变量操控、及无关变量的控制。

　　而定性研究重视对主观意义的理解(如背后隐藏的原因)，采用解释建构的方法，比如访谈法等。

　　平时工作中以“形成式可用性”测试为主，即便它稍微偏向于定性研究，但在允许的范围内，我个人还是尽可能地遵循着定量研究的方法去实施。这样整个测试过程的严谨性能得到保证，结论的客观程度相对更高(近几个世纪来，量化研究一直是科学研究的主要范式，也正是这个原因)。具体做法如下：

　　1.在任务的设置上：因为参与者可能存在差别较大的亚群体，不可能要求完成完全相同的任务。但必定会设置大部分基本的、都需要完成的公共任务，再针对不同亚群体设置少量的特殊任务。在后期统计分析的时候，基本的公共任务则可以进行数量化的统计，并横向比较。

　　2.在测试过程中：关注参与者完成任务时的相关行为，用数字来记录(以0、0.5、1分别表示失败、帮助/提示下成功、成功)。主试尽量少地言语及体态姿势的干扰，只在必要时进行适当地言语交流。

　　3.在报告呈现：对任务完成情况(效率、完成率)统计呈现，对不同任务的完成情况进行比较，对亚群体间的任务完成情况进行比较，对所有可用性问题按数量化指标进行排序等。或者比较迭代前后独特问题的频次是否减少，以及严重程度高的等级里面可用性问题数量的变化情况。

　　4.测试过后，我们通常还会收集用户自我报告式的数据，作为“感知可用性”的一个总体反映。

　　(1)推荐使用系统可用性量表(SUS)，因为有研究表明SUS在少量样本时即可产生较为一致的评分结果。

　　(2)为减少用户在填写这些量表时的反应心向，不要求填写任何个人信息，且主试最好暂时回避。

　　(3)只统计分析所有参与者SUS量表总分的平均值，切勿再拆分比较亚群体之间的差异，因为即便信效度再高的量表，当样本量极小时都会变得很不靠谱!

　　七.问题优先级：单指标 VS 多指标

　　除了在可用性测试过程中，最终报告也必须体现出量化、客观地特点。例如，报告发现的可用性问题的列表，我也会以量化的方式排列出问题的优先级别。

　　这样做的好处在于：首先，发现的可用性问题肯定有一些比另一些更严重;其次，考虑到产品和设计人员的精力和资源总是有限的，必须帮助他们梳理出最亟需整改的问题。站在别人的角度考虑问题，这样他们才能更“友好地”接受我们的报告。

　　可用性问题列表的排序，涉及到采用单指标还是多指标、以及指标分为几级的问题。

　　先就量化的客观性而言，“出现频率”指标是最客观、最易量化的;而其它三个指标都需分析人员的主观判断。

　　就指标的代表意义而言，“严重程度”、“出现频率”与用户体验最相关，与用研人员的职责也最相关。另两个指标可能更多地是产品人员的职责。

　　就指标的价值而言，多个指标的综合显然比单一指标更有价值。

　　基于上述考虑，实际工作中我会选择“严重程度”和“出现频率”两个指标的综合，作为可用性问题的优先级指标。“严重程度”分为3级，而不是5级(分析人员主观判断时，3级指标的误差率要低于5级指标);“出现频率”采用计算的具体数值，而非4级分类。这两个指标合并时，采用1：1的权重，具体公式为：

　　问题优先级=严重程度的级别+出现频率的具体值×3

　　八.报告呈现：优点 VS 问题 VS 建议

　　当产品设计人员辛辛苦苦做出的产品却被你报告上罗列的各种问题批评得一无是处时，即便理智上认可你的成果，情感上也很难接受。因此报告中列出哪怕一条最重要的优点，也会让产品设计人员感到欣慰、感受到你中立的态度，增加对报告的接纳程度。列出优点的另一个好处是，在测试中被参与者多次自发提及的优点确实带给用户某种惊喜;当你在报告中再次强调时，可以避免在后期迭代开发中丢失掉原本的优点。

　　问题的列举肯定是报告中非常重要的部分，但切勿罗列出清单就草草了事，因为：

　　1.某个(些)问题和另一个(些)问题是有关联的，但是报告中的问题列表部分却割裂了这些联系。

　　2.产品设计人员无法一直参与旁听/观察可用性测试的过程，导致对报告中文字描述的问题缺乏感性认识。

　　3.只提问题却不提供解决方案，就不是“建设性地提问”!

　　因此，我们需要在可用性测试报告的后半部分提出针对重要问题的解决方案。其目标并非是强迫产品设计人员一定要采纳我们提出方案，而是：(1)把一些相关问题联系起来看，(2)加深报告阅读者对于问题的感性认识和背后原因的理解，(3)使整个报告的思路更清晰、完整，(4)我们还可学到一些交互设计和产品的知识。

　　总之，可用性测试施行起来既简单又复杂。简单是因为不管你如何施行，终究能发现一些问题;复杂则在于发现可用性问题的质量、重要性、对测试的利用效率、对产品设计人员的帮助程度可能相距甚远。一次成功的可用性测试体现在从前期策划、测试过程、后期报告等整个过程中是否遵循了这些原则，并在某些难以两全的原则面前做到合理的权衡取舍。

原文转自：http://www.ltesting.net