一、 定义
1. 可用性(usability)：
根据ISO 9241-11的定义，可用性是指在特定环境下，产品为特定用户用于特定目的时所具有的有效性、效率和主观满意度。
有效性是用户完成特定任务和达成特定目标时所具有的正确和完整程度。——能够完成任务。
效率是用户完成任务的正确和完成程度与所用资源（如时间）之间的比率。——快速完成任务。
主观满意度是用户在使用产品过程中所感受到的主观满意和接受程度。——用的很满意
Nielsen认为可用性有五个指标，分别是易学性、交互效率、易记性、容错性和用户满意度。产品只有在每个指标上都达到很好的水品，才具有高的可用性。
易学性(learnability)：产品是否易于学习
交互效率(efficiency)：即客户使用产品完成具体任务的效率
易记性(memorability）：客户搁置某产品一段时间后是否仍然记得如何操作
容错性(errors)：用户使用产品时能够少出错，系统必须防止灾难性错误发生。
满意度(satisfaction):用户使用产品主观上感到满意。
简单来说，可用性可以理解为“多大程度可以使用”，直接关系着产品是否能满足用户的功能性需要，是用户体验中的一种工具性成分，是交互式产品的重要质量指标。
2. 可用性测试：
在产品或产品原型阶段实施的通过观察或访谈或二者相结合的方法，发现产品或产品原型存在的可用性问题，为设计改进提供依据。
该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。
可用性测试不是用来评估产品整体的用户体验，主要是发现潜在的误解或功能在使用时存在的错误。
二、什么时候做
有了产品原型之后就可以做：
可以是灰度产品原型，这时候多采用访谈的方式；
也可以是高保真原型，这时候通常观察与访谈相结合；
一般使用高保真的Demo，可以用Prott，Flinto，proto，墨刀等来制作,制作力求真实还原应用的最终实现效果。
制作高保真Demo比较耗时，可以忽略一些动效，界面等。在验证产品概念的阶段，也可以直接用会的模型。具体依实际情况而定。
三、怎么做
按照可用性测试所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。
形成性评估：是指在产品开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。
形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高。
总结性评估：横向评估多个版本或者多个产品，输出评估数据进行对比。
通常我们提到可用性测试，大多是指形成性评估。
1. 几种常用的测试方法：
认知预演(Cognitive Walkthroughs):
由Wharton等（1990）提出。测试步骤;
a. 定义目标用户、代表性的测试任务、每个任务正确的行动顺序、用户界面
b. 然后进行行动预演并不断地提出问题: 包括用户能否达到任务目的，用户能否采用适当的操作步骤，用户能否根据系统的反馈信息评价是否完成任务
c.最后进行评论，诸如要达到什么效果，某个行动是否有效，某个行动是否恰当，某个状况是否良好。
该方法优点在于能够使用任何低保真原型，包括纸原型。
该方法缺点在于：评价人不是真实的用户，不能很好地代表用户。
产品经理或设计人员的自我审查法？
启发式评估(Heuristic Evaluation):
由Nielsen和Molich（1990）提出。
由多位评价人（通常4至6人）根据可用性原则反复浏览系统各个界面，独立评估系统，允许各位评价人在独立完成评估之后讨论各自的发现，共同找出可用性问题。
10大可用性原则
十大可用性测试原则：
状态可见原则(Visibility of system status)：
用户的任何操作，单击，滑动，按下按钮等，页面应即时给出反馈。“即时”是指，页面响应时间小于用户能忍受的等待时间。
环境贴切原则(Match between system and the real world)：
产品的一切表现或表述，应该尽可能贴近用户所在的环境（年龄、学历、文化、时代背景）。
系统应该用用户的语言，用词，短语和用户熟悉的概念，而不是系统术语。
《iPhone人机交互指南》里提到的隐喻与拟物化是很好的实践。
用户控制性与自由度，撤销重做原则(User control and freedom)：
不要替用户做决定。
为了避免用户的误用和误击，产品应该可以撤销，重做。
一致性原则（Consistency and standards)：
同一用语，功能，操作一致。
防错原则(Error prevention)：
比出现错误信息提示更好的是更用心的设计防止这类问题发生。在用户选择动作发生之前，就要防止用户容易混淆或者错误的选择。
识别比记忆好，易取原则(Recognition rather than recall)：
尽量减少用户对操作目标的记忆负荷，动作和选项都应该是可见的。用户不必记住一个页面到另一个页面的信息。系统的使用说明应该是可见的或者是容易获取的。
灵活高效原则(Flexibility and efficiency of use) ：
中级用户的数量远高于初级和高级用户数。为大多数用户设计，不要低估，也不可轻视，保持灵活高效。
审美与简约设计--易扫原则(Aesthetic and minimalist design):
互联网用户浏览网页的动作不是读，不是看，而是扫。易扫，意味着突出重点，弱化和剔除无关信息。
帮助用户识别，诊断，并从错误中恢复-- 容错原则(Help users recognize,diagnose, and recover from errors) ：
错误信息应该用语言表达（不要用代码），较准确地反应问题所在，并且提出一个建设性的解决方案。
人性化帮助原则（Help and documentation)：
帮助性提示最好的方式是：1、无需提示；2、一次性提示；3、常驻提示；4；帮助文档。如果系统不使用文档是最好的，但是有必要提供帮助和文档。任何信息应容易去搜索，专注于用户的任务，列出具体的步骤来进行。
该方法的优点在于专家决断比较快、使用资源少，能够提供综合评价，评价机动性好，但是也存在不足之处：
一是会受到专家的主观影响，
二是没有规定任务，会造成专家评估的不一致---可以预设评估任务，
三是评价后期阶段由于评价人的原因造成信度降低，
四是专家评估与用户的期待存在差距，所发现的问题仅能代表专家的意思。
用户测试法(User Test):
让用户真正地使用软件系统，由实验人员对实验过程进行观察、记录和测量。
这种方法可以准确地反馈用户的使用表现、反映用户的需求，是一种非常有效的方法。用户测试可分为实验室测试和现场测试。实验室测试是在可用性测试实验室里进行的，而现场测试是由可用性测试人员到用户的实际使用现场进行观察和测试。
一般情况下我们讲可用性测试，指的是用户测试法：让一群有代表性的用户尝试对产品进行典型操作，同时观察员在一旁观察，聆听，做记录，从而发现产品的可用性问题，为设计提供改进依据。
套用来自网易uedc的一张图:
可用性测试
2. 用户测试法详细测试流程
可用性测试的一般过程
2.1. 测试之前--确定目标与范围
产品的不同阶段，测试目标及侧重点有所不同，开始之前我们需明确一些基本问题。
WHY：为什么进行这个测试？测试目标是什么？
是探索型测试--发现产品可用性问题，还是验证型测试--验证不同设计方案的合理性，最终选择最优方案？
WHEN：什么时候测试？时间需与用户协调
WHERE：在哪里测试？实验室模拟还是真实环境？现场测试还是远程测试？测试设备还是用户设备？
WHAT: 测试什么？测试的功能点等。
在产品设计初期，需关注产品整体层面的问题，如导航的合理性、页面逻辑关系等，这个阶段可能只有低保真原型可以用于测试，这时任务设计需宽泛有弹性，关注核心流程。
产品设计基本完善，开始进行细节的修改迭代，且有可用的高保真原型或现成产品，则需要精细的任务设计。
最后我们还要准备测试工具：
用以记录用户操作行为，用户手势，最好同步记录用户表情和声音。一般使用镜像软件扩展屏幕+摄像头/麦克风记录表情声音+PC录屏。
常用方案：
iOS--Display Recorder + QuickTime；
Android--Mobizen + AirDroid
2.2 典型测试任务设计
a. 列出任务清单
资源有限，任务不宜过多，只列出重要的，核心的，你觉得可能有问题的任务。
b. 将任务还原为场景
这和需求分析阶段的由场景抽象任务的过程刚好相反。场景是要读给用户听或给用户看的内容，对用户来说，你的功能并不重要，重要的是他们的目的以及他们完成目的的过程，因此场景必须包含用户行为目标与动机。
应尽量避免“直接指导操作”式的语言描述方式：
例如：想考察豆瓣读书页面【想要】按钮是否能被看到、是否具备可点击感。下面列出两种表述方式，以作对比：
A.请找到您喜欢的那本书，并在该页面点击【想要】。（×）
B.请找到您喜欢的那本书，并在该页面对其作个标记。（√）
c. 确定任务完成的必要条件
需要提前准备提供给用户的东西，比如是否需求新的账号
d.预测试
预测试是正式实施可用性测试前的一次模拟， 模拟有助于发现问题，这时候邀请同事即可。把正式测试的流程走一遍，包括设配的调试、访谈切入、问题的提问、记录者的记录等，然后把记录的录音、视频等放出来看看效果如何，效果不如意的时候再进行调整。
总之，预测试可以帮助发现问题，包括以下几个方面的问题：
设备的问题。举个例子，录音设备放置的位置会影响录音的效果。
测试脚本的问题。测试问题是否足够清晰。
访谈的切入以及问题的提问。
记录者的记录。
发现问题之后去解决问题，才能使正式测试的时候达到更好的效果。
2.3. 典型用户招募
a. 找谁来
可以从三个角度入手：
人口学特征，性别、年龄、学历、职业、地域等
使用动机，如买家/卖家、企业/个人等
使用经验，如产品使用时长、竞品使用情况、互联网使用年限等。
这里的重点是有代表性的用户，依据分析前期的用户画像，尽量包含多种类型的用户。
b. 找多少人来
Nielsen的研究发现，5个用户可以发现80%以上的可用性问题，一般不超过5个用户。
c.怎么找用户
同事（非同部门）或者好友也是目标用户，可以选用同事或者好友作为测试人员
通过官方微博，微信，论坛等进行招募
委托第三方机构寻找
2.4. 正式测试
-1. 事前接待
-2. 暖场介绍
-3. 正式测试
-4. 结束感谢
测试中有三种角色：用户，主持人，记录人。
用户：
使用产品，完成测试任务，说出自己的想法
主持人：
可能是用研人员，也可能是产品和设计人员自己。引导用户完成测试任务。
要强调的是，在测试中不要试图教用户如何使用产品，也不要试图向用户推销你的产品。
测试前主持人做什么
测试中
测试后
记录人：
记录时都要注意，记录的重点不是用户说了什么，而是用户如何使用。
记住，在测试中，做了什么比说了什么更重要。
可以同时记录问题，但不要急于讨论问题的解决方案。因为马上想到的方案或者用户提出的方案并不一定是最好的，这个工作可以留待可以安静思考或者大家讨论时进行
发声思考:
被测试者一边使用系统，一边不停地说出他们的想法——在操作用户界面的同时，把他们所想的东西简单地转化为语言，表达出来。
2.5. 数据分析——可用性问题分级
-1 汇编和总结测试中获得的数据
任务完成度：每个测试任务都对应一个目标，只有当用户达到目标之后，我们才认为他们完成了任务。对于每个任务，用户完成的情况如何？有多少用户最终没能完成任务？多少用户需要在主持人提示下完成任务？多少人可以自行完成任务？这些都是很重要的指标。
完成任务的时间：每个任务需要完成多少时间，决定了交互设计流程和界面的设计是否足够友好。
主观情绪：用户对于任务的主观感受，比如是否足够简单，是否容易找到信息，可以让用户衡量一下。
偏好和建议：可以让用户说出产品中哪些地方很喜欢？哪些地方不喜欢？或者让他们提一下建议。
-2 可用性问题分级
经过可用性测试，可能会发现产品或页面的很多可用性问题。为了方便内部人员决策，需要对这些可用性问题进行分类或等级界定。常见的分级方法有：
a. 五级划分
5级：无关紧要的错误
4级：问题虽小但却让用户焦躁
3级：中等程度，耗费时间但不会丢失数据
2级：导致数据丢失的严重问题
1级：灾难性错误，导致数据的丢失或者软硬件的损坏
b. 三级划分
低：会让参加者心烦或沮丧，但不会导致任务失败。
中：与任务的失败有一定关系但不直接导致任务的失败。
高：直接导致任务失败的问题。
c. 二维划分。根据出现频率和影响严重性划分。
d. 决策树。根据以下三个因素综合决定的：
频率（Frequency）：偶然的or经常性的
影响（Impact）：容易克服or很难克服
持续性（Persistence）：一次性的or持续的
e. 多维划分。根据问题所属范围和问题出现频率 :
问题所属范围：交互、视觉、文案、功能、bug
问题出现频率：N个人出现同样的错误
-3 根据问题的严重程度和紧急程度排序撰写最终测试报告。
四、小结
大厂有可用性测试实验室，普通公司，有可用性测试就不错了。那一般公司有哪些机会可以进行可用性测试？
产品经理自测法：
认知预演，启发式评估，没有人，对照可用性原则，自己来
同事：
-原型阶段，向同事解说你的原型，在说明的过程中，大家会贡献很多问题及建议
-有了可运行产品，设计典型任务，请同事帮忙预测试
客户现场：观察客户操作
不管是请同事测，还是请客户试用，抓住与使用者接触的机会，都可以做一些小批量的可用性测试，上文中的一些主持人的引导，注意事项都是通用的，个人感受最深的几点是：
不要和用户讨论，这很容易变成争论；
不要评论用户的意见，既不要批评也不要反对，这很容易失焦，表示“知道了”就可以；
不要在当下想解决方案，这通常都不是最佳方案；
一句话，少说多听。
