报告撰写

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

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

1、把现象当结论

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

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

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

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

测试中我们主要记录以下2种数据：

• 客观指标：行为 （e.g. 完成率、完成时间、错误次数、请求次数、操作的路径）
• 主观指标：动机—>需求–>态度—>价值观 （e.g. 满意度、向别人推荐的意愿） （这些又分为意识vs潜意识）

如果是意识层面的，可以直接问，但需要技巧；潜意识的动机、需要、态度，不一定能直接问到，可能需要投射技术。

总则：

       可用性测试侧重的是用户的操作、是行为，只不过有些时候我们不知道用户为什么进行某个操作的时候，而行为本身不能说话（当然用think aloud的方法能部分弥补），所以我们需要去询问这些操作背后的原因。例如，你想了解用户对这个页面上的某些内容感兴趣，你可以让用户点击浏览他感兴趣的内容，而不是问他：你对上面那些内容感兴趣？所以，如果你要测的产品（e.g.网站）能记录用户的操作行为，比找几个用户过来直接问要准确。

测试过程

• 当用户出现值得关注的操作和行为时，尽量在每个任务结束后，当场询问他刚才在这个操作时，是怎么想的，避免事后根据自己的理解来推测用户当时的心理活动。而且尽量记录用户原话。
• 虽然我们力图将测试脚本写得比较完善，但对于用户出现了脚本上没有测试的行为时，可以把这个操作记录下，并当场询问用户。
• 测试完之后，主持人立刻检查有没有有一些测试题目是没有记录的。如果有的话，当场询问用户。（因为我们这次有部分题目是漏写了的）
• 记录员与观察员之间分开记录，或者在制作脚本时制作2个版本。持人的主要精力应放在观察操作，记录需要进一步澄清的问题和用户不同寻常的问题点，一些脚本上既定的步骤与评价可以让观察记录员来完成。
• 用户在输入密码的地方不要录制。
• 用户在填写SUS量表的时候，主持人尽量不要在场，避免用户因为我们的在场而不敢打低分。如果测试的产品涉及多个版本，可以考虑让用户对几个版本分别评分。

询问技巧

• 避免措辞里对用户的引导。例如，不要给用户选择A还是B。
• 区分主持人评估与测试后问题。例如，像 “是否理解热点的意思”这类问题，可以让用户来解释这些用语，把用户的原话记录下来后，再根据它来判断是否理解。而不是直接问用户，“你理解这个词的意思吗？”，因为他们很可能会回答是，但其实是没有理解的。
• 如果你问用户“你平常会不会和朋友分享应用？”或者“你平常用过语音输入法吗”，他会回答“很少 ”；当你再问你在过去有没有真的，他可能回答没有。
• 有些人认为把用户的所有原话记录下来就是最好的。但我个人认为真实、原本≠好

——————————

以下是其他人总结的经验

脚本撰写

• 预演和预测试：测试脚本的初稿写好后，得把全部过程预演3遍左右；能找到用户预测试就更好了。这可以避免在施测了2、3个用户后才发现脚本有问题。
• 制作测试脚本前，需要将测试产品的所有功能都尝试一次（尤其是开通、取消、查询套餐、搜索等），不能以为不会出现问题，就省略了这个步骤。例如，有一次我们使用了同一个测试手机的号码来完成办理业务，当用户直接点击办理套餐时，只有第一个用户收到的短信才会提示用户，后续的用户都出现的提示语则不是这一条。
• 凡是涉及到呈现次序时（e.g.测试多个竞品或方案），必须考虑顺序效应。
• 十分仔细地检查上一个任务对下一个任务的影响，看看上一个任务结束时的页面对下一个完成时的页面，是否要求任务开始时页面处于什么状态（脚本里注明初始和结束状态），尤其是那种流程类的任务（例如上一个任务是提交信息，下一个任务是修改信息）。
• 第一次使用测试产品时，必须记下自己的任务不适应的、不是很理解地方，哪怕它只是个小问题。因为这些不适应的地方，不算很强烈（但它们很可能就是可用性问题），它们会在你逐渐熟悉这个产品之后而“消失”，你很快就容忍了这些细节的小问题。
• 如果任务涉及到评分，我个人觉得在用户操作完这个任务之后，立刻评分。Yale心理学公开课里提到的一个例子就是当要求被试列举出某个人的3个优点或10个优点时，发现被试会对列举3个优点时评分更高。因为要列出10个优点比较难，很多人列不出来，于是人们对这个人的好感降低。这类研究有很多。

（以下是针对可用性测试而言）

维度1：是否用过本产品？

1、本产品（待思考）

2、同类产品（这种用户会学习和适应所测试的产品会稍快，他们延续其他产品的操作行为来使用和评价测试的对象；对于他们提出来的可用性意见如何采纳？）

3、都没使用过 （这种新手因为不熟悉这类产品的操作，所以可能会“发现”更多的可用性问题）

其他维度：性别？年龄？职业？还是….？

     《采铜学心录》的作者认为，大家习惯性地从性别、年龄、职业、学历等人口统计学的维度来进行划分和筛选用户（例如招募的比例是男vs女1：1，学生vs工作1:1），通常是没有必要的。大家之所以这么做，估计也是习惯了社会学调查、市场调查的做法。

      那具体要不要这么划分呢？

      先问自己：我们为什么想要这样划分？是预期不同性别、年龄、职业、学历之间的人，在使用测试产品时存在差异，以便我们发现的可用性问题能代表广大人民群众的使用习惯和想法，是吗？如果是的话，为什么这几个属性会导致了这种差异呢？原因可能会是：年纪大的人不熟悉手机、电脑操作，学习能力差一点，那我们为什么不直接用“使用手机的时间”、“操作手机的熟练程度”来直接划分用户，而采用年龄这个间接属性来划分呢？（不过话说回来，年龄、职业这些属性很容易获取，而类似操作手机的熟练程度这类属性，如果没有现成的量表，还得自己设计几个问题来测量才行，其信效度又可能被质疑）

     《设计心理学》的作者Donald Norman 之前写过一篇文章说，以人为中心的设计（Human-Centered Design）的理念是如此的深入人心，以至于可能大家在理解的时候会出现一个偏差，于是他提出以活动为中心的设计（Activity-Centered Design）。对于可用性测试而言，我们注重的是用户在完成给定的任务时，他们与界面之间的交互行为，以及这些行为背后所反映的认知模式、体验、态度、需求等。

插曲：

     同人于野兄写过一篇文章《从Web 2.0到推荐引擎2.0》，里面介绍了2种推荐的机制：一种是像Pandora那样，通过分析歌曲本身的特点，推荐曲风相同的歌曲；另外一种是像Hunch那样，它直接分析人的喜好。（个人觉得，分析歌曲相对容易，容易推荐到你喜欢的曲风相似的歌，但一个人可能会喜欢多种风格的歌曲；直接分析人的话，相对复杂）

领了2次工资，写点东西小结一下吧….

作为心理系的学生，第一次接触可用性测试的时候，我感觉：

大家都知道那个”神奇的数字5“，因为Nielsen的研究发现，5个用户可以发现80%以上的可用性问题，他是假设平均每个用户可以发现30%的可用性问题，而且假设所有问题都有同等被发现的概率。

过去的研究已经对测试的样本大小进行过不少探讨，例如：

• Benefits of increased sample sizes in usability testing (2003)
• Why you only need to test with 5 users (2000)
• Five users is nowhere near enough (2001)
• Refining the test phase of usability evaluation: How many subjects is enough? (1992)

可用性量表很多（见下图），SUS只是其中一个。 

SUS简介：

量表作者：John Brooke  (Digital Equipment Corporation, UK, 1986)

问卷组成：10个问题，在5点量表上打分

量表中文版以及计分方式：查看这里

信度：0.85  （见上图）

优点：

• 问卷短，省时
• 最后会得出一个分数，直观
• 免费
• 对于小样本（ n<14），SUS的优势更明显（见下图），图中的意思：随即抽取14名被试的SUS问卷均能判断网站1比网站2要好，而抽取的CSUQ问卷只有90%能做出这个正确的判断，详见这个PPT或原论文）