本文从搬运和自己总结两个部分阐述如何使用可用性测试来验证你的设计方案，为大家建立有效的验证设计提供帮助

WHAT: 可用性测试定义

WHEN: 可用性测试什么时候用

适用于产品的不同周期：

WHY: 可用性测试解决了什么问题？

通过对有效性、效率、满意度来查看用户的反应，主要是为了寻找用户痛点，产品缺点，继续改进！不是让你白测试的！！

是让你画个表），记下来到底还需要改进哪些痛点，排个优先级，快速迭代改改改！才能让你的产品更牛逼！

每次测试之后程序设计师都能够对软件加以改进。”

个人总结：为了验证当前的设计方案，

（1）记录下用户反馈的修改的那些痛点

（2）然后将问题进行优先级排序，给予解决方案的建议。

• 产品体验上是否存在问题？
• 期望的设计目的是否能达成？是否满足了用户的期望？
• 了解用户的行为习惯，了解用户的认知，找到某些问题的原因？
• 用户是否会满意？

WHAT: 用什么做可用性测试？

纸面原型、原型图、高保真原型图设计稿、竞争对手产品，都可以（只要有流畅路径即可）

那体验五要素里，适用范围是哪几个：

 后三层，表现层、框架层、结构层。

几个人？

2种：

（1）形成式：小样本5-7人，发现问题为主，不能做定量对比

（2）总结式：大样本，30人以上，定量的评估，可以做对比评估

但是对于我们快速迭代的互联网中，节奏快。

所以，互联网公司经常使用的是第一种，形成式，小样本，以发现问题为主的可用性测试。

第一种的特点是：快速、简易、紧密

说明：根据尼尔森的研究，5个可用性测试参与者就可以发现80%以上的问题

可用性测试具体实施：

老习惯，本人是个讲究多元化方法论的人，我觉得纸上得来终觉浅，绝知此事要躬行

总结：可用性测试就是为了验证当前的设计方案。

我做可用性测试，主要就是自己先去列一些测试目标，比如用户在操作流程会不会有一些卡顿，目前的交互是不是和用户理解的有出入，等等。在可用性测试中，一次一个用户，去观察用户试用一些东西（不管是原型，还是一些关于新设计方案的草图），去完成一些典型的任务，通过观察用户的行为，你可以检测到那些让用户混淆和倍感挫折的地方，并修复。

以下是我在做每个步骤时候的重点：

（1）用户招募筛选很重要：

测试人员筛选也很重要，直接影响结果，忠实用户有时候没用，数据会有问题，声音比较大的老用户可以用。

用那些新用户（吐槽比较大的…）他们的吐槽或许比较有价值！老用户会有一些惯性思维和习惯 反而有时候不可取！比较满意的老客户没多大用。

1-3月的新用户最好，太久了反而不好。

可以想象一下 6个月前你买咖啡的场景你还记得吗？ 反之1个礼拜内买咖啡的人，反馈的问题更真实。

所以最近一段时间购买的人，反馈的问题就是可信的。

这个时间可以这样写，注册半年左右且最近几个月频繁购买的用户

（2）整理表格的满意度这里：

非常高兴 高兴 不高兴 非常讨厌 大概四种表情去表示一下。

用户更多是情绪的表现比较直接 用户非专业人士 不会说：这个可见性 /易读性… 他们只会高兴 不高兴 。

（3）用户数据从哪里来：

一般都是运营部门的人去找IT部门负责人去要这个数据
（4）关于是否用用户的手机：

初步发布，没有正式发布（并且通过内部测试的产品！灰度上线的产品 ）可以用客户自己的手机 这个情况是产品并不是那种保密产品。

若是保密产品，只能用公司测试机。

（5）预测试很重要：

移动可用性测试受到设备、环境、任务等多因素影响，进行预测试可帮助我们发现测试计划，及前期准备中可能存在的问题，从而保证正式测试的顺利进行。

自己人先走查一遍流程是否能跑的通，免得浪费不必要的时间，并且修好发现的问题。

（6）不要提示用户，用户测试任务的时候，不可以提示。

除非是这个功模块弄完了 提示去做另外一个不一样的模块

（7）然后将问题进行优先级排序，给予解决方案的建议。

那个问题转换成设计 （一个按钮 一个banner 或者一个布局排版的改变…）就是测试的价值点了

这个是问题优先级是最后开发整改的时候一起协商排出来的。

（8）可用性测试需要一对一进行测试，

可用性测试需要一对一进行测试，每个记录员都需要记录观察测试人员的操作情况。可以在一个房间内进行多对对测试，如果人力不够，可以分批次测试。

个人经验，不代表全部

Powered by Froala Editor