这样做的好处在于:首先,发现的可用性问题肯定有一些比另一些更严重;其次,考虑到产品和设计人员的精力和资源总是有限的,必须帮助他们梳理出最亟需整改的问题。站在别人的角度考虑问题,这样他们才能更“友好地”接受我们的报告。
可用性问题列表的排序,涉及到采用单指标还是多指标、以及指标分为几级的问题。
先就量化的客观性而言,“出现频率”指标是最客观、最易量化的;而其它三个指标都需分析人员的主观判断。
就指标的代表意义而言,“严重程度”、“出现频率”与用户体验最相关,与用研人员的职责也最相关。另两个指标可能更多地是产品人员的职责。
就指标的价值而言,多个指标的综合显然比单一指标更有价值。
基于上述考虑,实际工作中我会选择“严重程度”和“出现频率”两个指标的综合,作为可用性问题的优先级指标。“严重程度”分为3级,而不是5级(分析人员主观判断时,3级指标的误差率要低于5级指标);“出现频率”采用计算的具体数值,而非4级分类。这两个指标合并时,采用1:1的权重,具体公式为:
问题优先级=严重程度的级别+出现频率的具体值×3
八.报告呈现:优点 VS 问题 VS 建议
当产品设计人员辛辛苦苦做出的产品却被你报告上罗列的各种问题批评得一无是处时,即便理智上认可你的成果,情感上也很难接受。因此报告中列出哪怕一条最重要的优点,也会让产品设计人员感到欣慰、感受到你中立的态度,增加对报告的接纳程度。列出优点的另一个好处是,在测试中被参与者多次自发提及的优点确实带给用户某种惊喜;当你在报告中再次强调时,可以避免在后期迭代开发中丢失掉原本的优点。
问题的列举肯定是报告中非常重要的部分,但切勿罗列出清单就草草了事,因为:
1.某个(些)问题和另一个(些)问题是有关联的,但是报告中的问题列表部分却割裂了这些联系。
2.产品设计人员无法一直参与旁听/观察可用性测试的过程,导致对报告中文字描述的问题缺乏感性认识。
3.只提问题却不提供解决方案,就不是“建设性地提问”!
因此,我们需要在可用性测试报告的后半部分提出针对重要问题的解决方案。其目标并非是强迫产品设计人员一定要采纳我们提出方案,而是: (1)把一些相关问题联系起来看,(2)加深报告阅读者对于问题的感性认识和背后原因的理解,(3)使整个报告的思路更清晰、完整,(4)我们还可学到一些交互设计和产品的知识。
总之,可用性测试施行起来既简单又复杂。简单是因为不管你如何施行,终究能发现一些问题;复杂则在于发现可用性问题的质量、重要性、对测试的利用效率、对产品设计人员的帮助程度可能相距甚远。一次成功的可用性测试体现在从前期策划、测试过程、后期报告等整个过程中是否遵循了这些原则,并在某些难以两全的原则面前做到合理的权衡取舍。
原文转自:http://blogread.cn/it/article/5764?f=sa