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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

总则：

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

测试过程

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

询问技巧

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

——————————

以下是其他人总结的经验

《采铜学心录》的作者提醒大家，以下内容通常不适合通过用户研究来直接获取，这也是很多人误用用户研究的地方：

偏好：偏好类问题受个体差异影响很大，所谓萝卜青菜各有所爱，除非有较大的样本，否则意义不大，甚至可能会产生误导。

对想象中的产品的评价：用户没有能力对想象中的产品作出评价，其结果也可能产生误导。使用原型给用户评价会缓解这一问题，但是还是需要谨慎。

对功能的期望：用户的期望包含了比较多的随意臆想的成分，不能以此为依据来设计功能，而是因从对用户现有行为的分析中挖掘机会点。

具体的设计建议：用户不是设计师，设计师也不该由用户来教导怎么做设计。所以，不应由用户给出具体的设计建议。工作中经常遇到这样的情况，设计师或者产品经理会让用研向用户“转达”有关具体设计建议的提问，但其实这是不妥当的，因为这等于是把产品设计的复杂性传递给用户，让用户来化解这种复杂性。例外的情况是，如果是对使用经验十分丰富且对该产品领域有深入研究的专家用户，可进行以上提问。这也是MIT创新管理学教授埃里克·冯·希普尔的观点，他认为越来越多的企业通过让专业级的用户参与到设计中来让企业获益良多。但是，对于一般的用户而言，询问有关如何设计某个产品的问题是不合适的。

以下摘自采铜学心录《用户研究经验谈（3）：访谈设计》

基于用户现有的经验提问。这一点在本系列的第一篇文章中就提到了，我可能比较固执，坚持认为用户对想象的、未知的以及各种不够熟悉的事物的判断是不可靠的，包括各种期望、建议和设想，比较可以信赖的是用户的经验本身，如果我们能让用户真实、自然地把自己的经验陈述出来，访谈就算取得80%的成功了。剩下的20%就是，与用户共同发现、探索其行为背后的心理动因，说是“共同发现、探索”是因为用户绝大多数的行为并非是深思熟虑的，甚至很可能是无意识的，他们很可能从来想过为什么要这么做，而研究员则可以引导用户去思考这些问题。

 

在问题的明确性和开放性之间找到平衡。有时候，当我们过于考虑提问的开放性、避免引导用户时，可能会走向另一个极端：让用户不知道这个问题到底要问什么、应该如何回答。比如：“您觉得您的手机怎么样？” “请谈谈您对社交网站的看法” “您怎么看待QQ？”。当一个问题过于模糊时，回答者最常见的应对方式就是同样给出模糊的回答，这些回答通常无法传递有效的信息，比如：“我觉得很好啊” “我觉得很OK啊” “感觉还不错”。

 

避免排比式提问。不要连续问几个问题：设想如果坐在你面前的用户研究员一直用同一种句式向你进行排山倒海式地提问——“你使用智能手机的频率是多少？通常在哪些情景下使用？”

 

引导用户从表面的行为开始思索，清理出行为背后的动机、需求乃至价值和文化观念。

 以下摘自《产品策划的修养》

传统的用户访谈，并不能完全解决深刻了解用户的问题。需要产品策划天天都泡在产品里，和用户一起，不是访谈而是谈心。且不只是一个用户，而是大量的用户，和他们交流沟通。你耕深几分，便能收获几分。你一分不耕，依靠用户反馈或者焦点小组之类，除非已经早就找对方向，否则仍是盲人摸象。

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

1.用户的操作行为永远是可用性测试的重点。

2.鼓励用户采用“出声思维法”。

3.适时、少量地向用户提问，禁止对同一个问题反复追问“为什么”。

4.采用真正地“倾听”技术保持和用户的交流状态，而非通过过多的话语。

5.开放、不预设立场地观察、倾听用户“没有说的”语言。

6.询问采用一般疑问句的句式，重复用户刚才的行为表现（要具体客观）

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

测试前准备

• 在测试前，统一观察员和主持人对脚本的理解。例如，怎么定义任务已经完成。
• 测试机vs用户自己的手机，手机vs电脑。如果测试的任务涉及这些设备之间的切换，请注意在脚本上注明。
• 如果测试任务需要用到无线网络，在每次测试前检查一下，看看是否需要重启无线路由器。

小结：

如果测试中涉及到以下操作都得留意

• 测试机、用户自己的手机、手机与电脑切换
• 上网（GPRS还是wifi）
• 在用户手机上安装应用
• 注册开通等操作

• 活跃，非活跃，新手（全新）
• 本产品，流失，竞品

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

维度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那样，它直接分析人的喜好。（个人觉得，分析歌曲相对容易，容易推荐到你喜欢的曲风相似的歌，但一个人可能会喜欢多种风格的歌曲；直接分析人的话，相对复杂）

怎么发现“其他维度”呢？

      《采铜学心录》的作者给了一些供大家参考：

• 使用动机、用户的使用经验和能力水平、用户的个性特征（如根据大五人格理论进行评估）
• 用户的生活方式和价值观（如通过VALS量表来评估）
• 用户对新的技术产品的态度（可根据罗杰斯的创新扩散模型将用户分为创新者、早期采用者、早期采用人群、后期采用人群和迟缓者等类型）等。
• 用户所在的组织和地区的文化特征（可基于霍夫斯坦德的文化模型进行评估）

定了维度之后，接着就是确定用户的比例

• 以前大家学过的抽样方法在这时候派上用场了。
• 可能一个偷懒的做法是：已工作和学生、男和女的比例都是1:1。由于样本的代表性是高度影响到稍后测试或访谈的质量（尤其是小样本抽样），那么什么叫有代表性呢？其实就是你抽取的样本基本能反映总体样本的各类用户，所以可能得做一下文献研究，看看总体样本在你已经确定的那几个维度上的分布和比例。

——————

如果是焦点访谈等用于了解用户需求的话，可以参看《采铜学心录》以下的建议：

用户研究（尤其是定性研究）中甄选用户的一般原则应是：寻找那些（在目标产品、相同领域产品或共通领域产品）有丰富体验的用户。不过这里还要澄清三种情况：

推荐阅读：

• 细说“用户分类”：如何避免教条主义与想当然
• 用户模型和数据（一）

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

（我很好奇：为什么知乎的领域分类里，最多人关注的领域是用户体验）

————————-

以下是做了3次可用性测试之后，思考的问题：

1）可用性测试只能保证你所测试的产品能用，但不能让它变得好用，让人喜欢用。因为找我们做用户体验的部门，都想改善他们产品的用户体验，但可用性测试只能发现产品中是否存在可用性问题，最多只能让新手在第一次使用产品的时候，比较容易上手、能比较顺畅地完成软件所提供的功能和操作，但不能保证用户会喜欢用它。（可用性 –> 易用性 –> 好用性 –> 喜用性）

2）假如你只会做可用性测试、你的用研部门水平一般的话：可用性测试对于做得比较烂的产品，意义才比较大，或者说只有这么烂的产品，用研才有存在价值。假如你所测试的产品，其研发团队很一般的话，研发团队听完你列出来的产品问题、然后作出修改后，还会有新的问题出现（因为研发团队很一般）

3）在学校里所学习都是实验的、定量的研究方法，而现在要做用户体验的时候，如何了解用户需求和想法却是十分重要，它可能更需要用各种定性的方法

4）我们在短短1个小时内、用10个左右的用户所发现的问题（包括通过可用性测试和访谈时用户所提到的问题），跟用户在某个论坛发帖所提的建议、给客服所抱怨的东西，这两者有什么异同？

5）当我们发现了问题后，把它写到报告里，但产品开发人员看到我们的报告后可能会问，我们真的需要这样改吗，你有足够的理由支持这个改动吗？坦白说，很多时候我们没有充分的理由。因为在一次可用性中（约10个用户），我们更倾向于记录用户的反馈，是发现问题的过程，而不是验证某个假设的过程。

6）当你实力比较弱的时候，模仿是你最好的壮大自己的途径。我发现了一个现象：一个很简单的登陆页面，客户还是会出现很多问题（e.g.没有找回密码的地方、注册入口不明显等等）。如果什么事情都想着从0开始、由自己去摸索，你会犯很多很多错误，而这些错误其实都是可以不必要的。尤其是当你的开发团队实力不强，那就好好把别人现成的、优秀的产品一字不漏地抄过来（就已经不错了，哪怕不能保证用户喜欢，但最起码使用起来不会有问题）。

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

• 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或原论文）

用途：

• 同一个界面，完成不同的任务之间进行比较（因为有的任务可能会更难或不常使用，例如安装软件这个操作可能只需执行一次，而不像其他操作那样频繁使用；用户在完成不同类型和难度的任务之后，分别评多次SUS的分数，然后再进行对比，因为如果所有任务只评一个SUS分数的话，可能会因为某些任务较难而降低了评分）；
• 同一个界面，先后不同版本之间进行比较（不过需要注意的是增加新功能或改版后，用户在初期可能会不适应，而导致SUS在短期内会下降，但长期会回升）
• 备用方案之间、竞品之间进行比较。
• 不同种类的界面之间进行比较（例如同一个产品有PC版、网页版、Android版、iSO版；或者百度地图与微信之间比较）

（Bangor没怎么解释为什么可以在不同任务、不同时间、不同界面之间进行比较）

如何解释SUS分数？

1）SUS分数反映的是总体的可用性，单独抽取某个题目的得分在产品之间作横向比较意义不大

   理由：

   a）10道题目之间高度相关；

   b）Bangor等人在2008年的那篇paper中，通过因素分析结果发现，10道题只提取出一个因素 ；但2009年有研究者提出，SUS分数反映了总体的满意度，同时第4和第10道题测量了易于学习性（learnability），而其他8道题测量了可用性。（详见）

2）如果某个界面的SUS分数为76，这表示什么？

解决方案一：

      AT&T Labs的Bangor,Kortum 和Miller在2009年发了一篇文章来解决这个问题。他们在SUS的结尾增加了1个问题（见下图），让用户使用Poor、Ok、Good等形容词来总体评价这个用户界面，其用意是想将SUS与这些形容词关连起来。

      以下是每个形容词对应的SUS分数：按照这次的数据，被用户评为Good的那些界面，SUS的平均分为71.4（标准差为：11.6，感觉有点离散）。

      不过Bangor等人并没有明确说，是否有足够的证据来证明可以使用71.4或某个分数来判断一个产品是否合格

解决方案二：

     就像GRE的分数一样，将SUS分数转换成percentile百分位数，解释的时候就说：“比百分之xxx的其他界面的SUS分数要高”。（不过这需要一个相对较大的SUS分数库）

     例如，由Jeff Sauro开发的SUS Package收集了500多个研究、5000多份SUS问卷。在这个分数库中，如果SUS得分为74，那么它比500多个界面中的70%都要高（见下图）

结合其他2篇paper中的SUS平均分，可以看出当一个界面的SUS得分为78时，可以说它大约比75%的其他用户界面都要好

a) Bangor, Kortum & Miller, 2009的研究中，3个百分数如下

    75%：77.8

    50%：70.5

    25%：62.6

a) Bangor, Kortum & Miller, 2008的研究中，3个百分数如下

    75%：78.5

    50%：70.9

    25%：62.3

如何报告SUS分数？

     可以参考一下Jeff Sauro的SUS Package

图A：计算SUS，并区分出Usability和Learnability 2个维度

图B：将SUS转换成百分位数

图C：比较SUS

      SUS十年回顾

Bangor等人在2008年发的那篇论文，总结了从1996年开始，收集了206个研究、2324份SUS问卷（即2324个被试）。（注：以下内容以这篇paper为主，同时辅以其他论文上的数据）

一、SUS分数的分布

•   2324份问卷的SUS平均分为70.14，标准差21.71，取值范围是0-100；206个研究的SUS平均分为 69.69，标准差 = 11.87，取值范围是30-93.9；
•  2324份问卷的SUS分数呈负偏态分布，206个研究的SUS平均分接近正态分布

(注：Figure 2是直接计算2324个被试的2324份问卷的SUS平均分；

因为一个研究大约会有10个被试左右，所以Figure 3是先计算每个研究所有被试的SUS平均分，再计算这206个研究的平均分)

结合其他2篇paper和blog中的SUS平均分，可以看出当一个界面的SUS得分为70时，可以说它达到了平均水平

1. M=69.69   206个研究、2324份问卷    (Bangor, Kortum & Miller, 2009)
2. M=69.69   273个研究、3500份问卷    (Bangor, Kortum & Miller, 2008)
3. M=68        500个研究、>5000份问卷  (Jeff Sauro)

2）不同类型的界面测到的SUS分数差异不大

       将206个研究界面分成6类，方差分析发现，6类之间差异不显著

3）SUS与任务完成率、完成时间不太相关

Jeff Sauro发现，SUS分数与任务完成率、完成时间的相关系数为r=.24，属于轻度相关（但原文中没说是否显著）。r=.24的意思是：任务完成率与完成时间这2个数值5.76%的方差可以用SUS分数来解释（5.76%=0.24 x 0.24）。不知道Sauro是如何可以计算SUS与另外2个变量的相关，却得出一个相关系数，而不是2个

参考文献 & 推荐阅读：

Bangor, A., Staff, T., Kortum, P., & Miller, J. (2009). Determining What Individual SUS Scores Mean : Adding an Adjective Rating Scale. Journal of Usability Studies, 4(3), 114-123.  [PDF下载]

Bangor, A., Kortum, P., & Miller, J. (2008). An Empirical Evaluation of the System Usability Scale. International Journal of Human-Computer Interaction,24(6), 574-594. [PDF下载]

Jeff Sauro：Measuring Usability With The System Usability Scale (SUS)