继续讨论可用性测试中各种原则的灵活运用和注意事项。

    五．发现问题：真的 VS 假的

    判断发现问题的真假，初看上去似乎不是个困难。多数或全部参与者都遇到的问题毫无疑问是明显的可用性问题。或许有人会建议，根据参与者中发现该问题的人数比例来判断：比例高是真问题，比例低是假问题。前半句话可以接受，后半句话则有待商榷。

     虽然可用性测试是相对严谨的用户研究方法，但是其对无关变量控制的严格程度和真正的心理学实验还是有一定的差距；并且心理学实验对每组参与者数量的最低要求是30人，这样得出的结论(数量比例)才具有推论至一般的意义。而可用性测试一般才8人左右的参与人数(尽管招募的参与者在质的方面非常具有代表性)，但却无法把可用性测试中出现的所有数量比例简单推论至一般。8个参与者中有1人发现某个问题，不代表现实中出现同样问题的真实用户只有12.5%，更不代表这个问题不是真正的/严重的可用性问题。

    问题的真假除了根据问题出现的次数比例，还有很重要的考虑点是：用户“错误行为”背后的认知/思考方式是否合乎逻辑？

    这里顺便借用一下诺曼《设计心理学》里谈到的理论：概念模型――系统表象――心理模型。概念模型可认为是产品设计人员对产品的设计思想；系统表象可认为是产品展现出的交互界面；而心理模型则是用户按照既往经验对如何操作该产品的设想。从这个角度来认识，可用性问题则是“概念模型、系统表象、心理模型”三者的不吻合或矛盾。

    通过分析用户行为背后的认知是否符合逻辑，来判断发现的问题的真假，主要体现在以下几点：

    1.“概念模型、系统表象”的不一致

    产品设计人员突然发现，界面的交互形式根本没有反映出他原先的设计思想！

    2.“系统表象、心理模型”的不一致

    (1)用户的思维方式受已有的同类产品的影响，并内化接受，而新产品的“系统表象”和已有同类产品并不一致。

    (2)用户在日常生活经验中形成了许多并不科学地通俗理解世界的方式(比如通俗物理学、通俗心理学)，但产品设计人员没有意识到用户在以这样一种“自认正确”的错误方式来理解和使用产品。

    如果发现的可用性问题属于以上情况，那么即使只有一个参与者碰到，它也非常可能是一个真正的可用性问题。

    例如：让用户登录购彩网站，查看自己上次购彩结果。大多数用户点击【个人中心】去查看，有2个用户点击【开奖公告】去查看，发现只有开奖号码，没有任何购彩结果信息后，再去点击【个人中心】。仅2个人出现了稍微的偏差，而且很快就找到了正确的页面，这貌似应该不算什么问题。

    但若追究其行为背后的逻辑，并与其他用户的反馈(“我上次买的号码没有直接显示出来？”“这里看不到开奖的号码啊？”)联系起来，可以判断用户的心理模型和产品的系统表象不一致。用户希望能同时对照着开奖号码和自己买的号码很方便地核对，而网站却割裂两部分放在不同的页面，因此需要将这2个用户碰到的问题当作真正的可用性问题来对待。

    六．研究方法：定性 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)我们还可学到一些交互设计和产品的知识。

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

建议继续学习：

1. Xvfb+YSlow+ShowSlow搭建前端性能测试框架    (阅读：54189)
2. 安全测试与渗透测试区别    (阅读：23675)
3. 使用Fiddler对手机应用进行抓包测试    (阅读：6895)
4. 服务器性能测试工具推荐    (阅读：6439)
5. 给Apache做压力测试时遇到的问题    (阅读：5891)
6. WEB性能测试工具推荐    (阅读：5630)
7. 可用性测试好助手——Morae软件的应用    (阅读：5456)
8. 12款很棒的浏览器兼容性测试工具推荐    (阅读：4844)
9. 在线测试不同操作系统不同浏览器网页的显示效果    (阅读：4681)
10. 性能测试工具sysbench简介    (阅读：4731)