报告撰写

• 可用性问题的描述格式：用户的具体操作（现象）、用户这样做的理由（测试现场对用户的追问+事后分析）、导致的结果
• 注意可用性问题的归纳，不只是把原始数据搬过来就算了（因为有些问题可能是源于同一个的原因）。同时，看看哪些量化的数据可以支撑这些可用性问题。
• 仅仅是罗列问题是不够的。作为用研的人员，我们大部分是过程导向，巴不得把所有做过的东西、流程写上去（就像在学校里写论文一样）；但对于产品的开发者来说，他们更倾向于结果导向。例如向我所外派的单位，他们希望听到说：他们需要做什么，为什么要这么做，怎么做(what, why, how)。在可用性报告里，我们可能把发现的问题罗列出来，但个人觉得这种形式不好。看报告的人看了一堆的问题，不好修改。如果以建议点为中心，紧跟着为什么要这样改的理由，对于一些问题不算很大、不知道是否有修改的必要的问题另外列出来，与之前的建议点区分开。

以下是大前研一在《思考的技术》里提到的

1、把现象当结论（缺乏现场追问和事后分析）

2、金字塔：你最有信心的结论位于金字塔顶端，而结论下方都是支持这个结论的，支持的论据少一个都不行（就像类积木那样）

3、如何提建议：最典型的错误就是，把所发现的问题反过来表述，就当做是给客户的建议，e.g.  业务员没有精神，所以应该把业务员打起精神

4、做报告的顺序：不是自己想说的顺序，而是对方理解的顺序

5、用5分钟把45分钟的内容讲出来

以下摘自网易《可用性测试的权衡之道（二）》

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

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

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

 

“可用性专家经常遭遇的挑战之一，就是通过量化的结果展示可用性测试的价值。要说服一个顾客投资数万美元在可用性测试上，总是需要一些实实在在的数字，明明白白地告诉他投资回报会有多少。客户可能会说，“是的，可用性测试会告诉我网站有多糟糕，用户有多么讨厌填网站上的表单。那又怎样？”从客户的角度，真正的问题在于：我怎么知道它能帮助我达到商业目标——增加销售、降低成本还是提高转化率？仅仅强调提高用户满意度是远远不够的。”