不做可用性测试，你没资格说你的产品是个好产品！

一、什么是可用性测试？

1、可用性测试概念

其实可用性测试并不复杂，简单概括就是观察用户使用产品。如果稍微扩展一些，我们可以将其解释为：通过观察有代表性的用户，完成产品的典型任务，而界定出可用性问题并解决这些问题。而目的呢，则是为了让产品用起来更容易。

2、可用性测试指标

有效性：用户能够达成自己的目标

效率：用户不必做无用功，就能以最短的途径达成目的

主观满意度：用户在使用产品过程中所感受到的主观满意和接受程度

3、可用性测试类型

形成性测试

总结性测试

（形成性测试与总结性测试对比图）

形成性测试就像学生读书期间进行的阶段性测验，通过这些测验确定学生对该阶段内容的理解程度，并对自己的教学方法进行改进（形成性测验不是为了打分，而是为了改善）；总结性测试则是检验学生对这学期综合掌握程度，用分数表示成绩，然后分析得分情况。

原则上来讲，总结性测试一般在开发后期使用，形成性测试一般在设计过程中反复使用。本文主要描述的是形成性测试。

二、什么时候进行可用性测试？

可用性测试要尽早开始，所谓越早测试，越早发现问题。

适用于【概念原型阶段、产品原型阶段、产品上线前阶段】

适用于解决的问题：

确定测试产品的可用性水平

与预期目标、与竞争对手、与老版设计相比的可用性水平

比较不同方案，确定哪个方案更加可行

现测试产品的可用性问题

三、可用性测试流程

（可用性测试流程图）

1、确定目标

可用性测试之前，需要明确这次可用性测试是为了完成什么样的目的，如果没有目标，就像一个没有方向盘的超级跑车，即时拥有最强有力的引擎，最终仍是废铁一堆，发挥不了任何作用。

2、确定测试方案

确定了目标后，就要考虑测试方案的设置，即如何设计测试任务。在设计任务之前，需要反复问自己的问题：“我设计的测试任务是真的反应了用户的实际目标吗？（而并不是我认为用户想要做的事情）”

设计任务的方法：

A 列出功能清单

首先内部沟通确定一份功能点清单，一般选择产品4-6个功能点进行测试（不宜过多），这些功能点可以是用户常用功能、新增功能、关注度高的功能及先前版本中存在问题的功能。

B 将功能变成场景

场景是你需要读给用户听或给用户看的内容，必须包含用户的目标和动机，对用户来说，你的功能并不重要，重要的是他们的目的以及完成目的的过程。

C 测试大纲

测试目的介绍

保密协议

测试场景

操作评分表（主试打分）

问卷（被试打分）

结束提问

对被试进行简要小结

D 确定任务需要的准备的资料

测试账号

工具（写字板、笔记本、录音、录像、软件）

计时器

文档：

测试脚本

被试安排表

任务卡片

记录表

问卷

保密协议

小节撰写

礼物收单

3、预测试

在正式测试前，需要进行预测试和修正情景与任务，可以先请一两位同事，简单的进行一下预测试，主要目的在于核对资料是否准备齐全，整个流程是否能够顺利进行，情景任务是否合理，通过预测试并及时调整这些内容，也能给自己长点信心。

4、招募用户

A 找什么用户？

我们测试中最关注的是用户的操作行为，因此在做用户招募时，更应该关注的是产品使用经验和使用行为，而不是人口统计学特征。

step1：从描述开始，尝试描述你想要什么样的用户来参与测试

step2：优先关注产品使用经验和行为

·与该产品相关的经验，例如相关的知识技能水平，使用基本功能的频次等

·与相似产品的相关的经验

·用户的网络使用经验，例如上网频率，网络应用等

B 找多少用户？

根据尼尔森公式“有5人参加测试，就能够发现大多数（约85%）的产品可用性问题。”不过，当任务设置数量过多，且任务的精细程度和难度多种多样时，这个前提可能就会不成立。如果在招募用户时，注重用户的代表性，那么5人就已经足够了，如果代表性不是很强的，就需要超过5个了，原则上一次测试最多不会超过12个用户。

（测试用户选择个数图）

在项目过程中也有一种迭代特快的测试方法，每轮测试3个用户，每轮测试完成后发现问题并修改，接着进行第二轮测试。通常这种测试方法能够快速帮助产品进行迭代。

C 如何找用户？

有这么一种说法，通过6个人你就可以认识世界上的任何一个人，也就是说我们和世界上的任何一个人都存在间接关系，充分利用你的人脉，无论是找同事、朋友、朋友的朋友，网站论坛广告等，只要快，并且在招募时，坚持要求即可。

5、正式测试

测试开始前，需要和所有工作人员进行一个简单的沟通：讲解测试的目的，为什么要设置这样的情景任务，需要完成那些重点，在测试的时候有哪些地方需要特别注意用户的操作，如何与用户接触，当测试进行不下去怎么办，发现用户情绪不对了如何安抚，是否需要终止任务等状况。

工作人员安排：

主持人：串联其整个可用性测试

观察者：观察和记录

助理：端茶递水加观察

接下来终于到了正式测试了~

主持人流程大致如下：

A 欢迎

自我介绍

解释测试目的和时间

向用户强调测试对象是系统而非用户

请用户尽量“出声思维”

告知测试会录像，但结果完全保密

签署保密协议

B 提问

职业

平时上网情况（每天上网时间，上什么网站）

平时使用产品偏好

C 测试中

宣读任务

不要以任何方式表现出用户正在犯错或操作太慢

仔细观察，并认真聆听用户的建议

识别用户的情绪，必要的适合选择停止任务

用户遇到困难的时候尽量不要提供帮助，可给予适当的鼓励

在用户完成一个场景时，可简单的问一下“为什么刚才要那样操作”

D 提问

询问在过程中想要深入询问的问题

询问观察的同事关心的问题

E 道别

感谢用户

将用户送出门口

保存录像，整理记录

以上为主持人流程，那么作为观察的同事，在测试过程中需要记录些什么呢？

行为：用户的动作和步骤

想法：用户的话

问题：记录你认为严重的问题，但不急于写解决方案

观察些什么？

用户能执行要求的任务吗？

期望的信息有没有找到？

用户找到有效的途径了吗？

用户理解自己正在做的事情吗？

他们碰到了什么问题？

他们能从错误中恢复吗？

倾听和试探

仔细倾听用户（如意外的感叹词“哎呀”是一个很重要的数据）

注意任何犹豫不决的情况

探寻以获得深层次的动机

提醒他们把所想的说出来

提防暗示性的问题（比如“你会如何关闭一个文件”，问题漏了答案，应该说“这个文档你已经处理完了，现在你会做什么？”）

6、数据分析

完成测试后，需要主持人和观察人员趁着记忆犹新的时候快速地有用的信息整理出来，可以采用便利贴，把用户相关的操作，提出的问题，和我们发现的问题迅速的写出来，但不要快速下结论。后续与产品，交互等一起进行改进。 这样就差不多完成了一次可用性测试，以上的流程也可以根据自己的实际情况再进行修改。

趁着记忆犹新马上整理！

1小时测试，30分钟整理

如有必要当场检查录像

不要评论用户或讨论设计，也不要太快下结论

分析是为了马上找出要修复的问题

只讨论观察到的情况

重点是那些最重要的问题

四、可用性测试原则

1、尼尔森可用性10原则

可视性原则

不要脱离现实

用户拥有自由控制权

一致性原则

预防出错

识别好多回忆（让用户选择而不是让用户回忆）

灵活且高效

美观简洁（易读性）

明确的错误信息

帮助与说明

2、施耐德曼八项黄金法则

力求一致性

允许频繁使用快捷键

提供明确的反馈

在对话中提供阶段性的成果反馈

使错误处理简单化

允许可逆操作

用户应掌握控制权

减轻用户记忆

参考资料：

可用性测试-新浪UCD

可用性测试的权衡

快速简单的可用性测试

可用性测试

用户体验与可用性测试