“可用性”这个概念自入行以来就听说过，但是没有好好的深入学习过，去年转正报告的未来工作计划也提了一下想对在做的几个系统进行可用性测试，虽然不知道日程计划能不能提上去，这两周还是着重学习了一下可用性测试，本文做一些归纳总结。
一、什么是可用性
可用性有如下五个属性：
1.易学性（Learnability）：系统应该容易学习，这样用户可以快速开始使用这个系统来完成某些工作；
2.效率（Efficiency）：系统的使用应该具有效率，一旦用户学会使用系统后，就有可能提高生产率；
3.可记忆性（Memorability）：系统应该基于记忆，以便用户离开一个系统一段时间之后能够重新使用这个系统，而不用从头开始；
4.错误率（Error）：系统应该具有低的错误率，使得用户在使用系统的过程中就很少出错，即使出错也能够迅速恢复。而且必须保证不会发生灾难性错误；
5.满意度（Satisfaction）：系统应该使用起来令人愉悦，让用户在使用时主观上感到满意并喜欢这个系统。
而“可用性测试”就是邀请一批真实的典型用户针对典型场景操作产品，并鼓励他们在尝试完成任务的时候出声思考，可用性工作人员在一旁观察、聆听、记录，发现产品使用过程中的可用性问题。它适应于产品前期设计开发、中期改进和后期维护完善的各个阶段，是以用户为中心设计思想的重要体现。
二、为什么要做可用性测试
我们作为产品的Manager、Designer、Coder，作为产品的爹妈，孩子身上有几颗痣都很清楚，孩子性格随我没毛病，认为这个功能理所当然应该这样设计。所以产品设计者是专家用户，而用户知识普通用户，我们不能完全代表典型用户的想法。听听来自用户的真实声音，有利于提升设计价值。
所以可用性测试主要是为了从易学性、效率、可记忆性、错误率和满意度五个维度衡量产品可用性，同时定位产品问题及产生原因，进而优化产品。
再有一点，设计需要平衡产品与商业之间的关系，所以可用性测试也与公司商业目的紧密相关，只有这样，测试才能成为解决问题和寻求机会的有效工具。
三、什么时候做可用性测试
NNG的Jacob Nielsen列出了以下三个场景：
1. 在迭代的过程中，特别是两个迭代之间的时候。我们需要知道我们本期的设计是否解决了之前的问题，或者我们还需要继续改进我们的设计方案。
2. 数据不会骗人——对于竞品的可用性分析，可用性测试得到的指标是非常有用的。
3. 在每一次新的发布之前，我们需要在脑海中有一个清晰的目标。当我们对现在的设计方案没有很大的把握的时候，一次可用性测试可以告诉我们，新的版本是不是已经准备好发布了。
四、如何进行可用性测试4.1 测试前4.1.1 明确测试目的
需要确定可用性测试的问题焦点，需要尽可能的精准、清晰、可测量、可观察，比如关于功能点、界面、流程等。可以询问利益相关者，理解他们想要知道的信息，专注于能够实现产品ROI的研究目标。
4.1.2 设计测试任务
首先我们需要有一个共识：“可用性测试任务是为了用户的实际目标，而不是我认为用户想要做的事”。其次下面是任务设计的几条核心方法：
a) 根据测试目的列出任务清单，任务不宜过多，必须是紧贴核心测试部分的；
b) 对每个任务给予用户合理的动机，对于用户来说，产品的功能不重要，重要的是用户使用产品想要达到的目的；
c) 将任务赋予真实场景，毕竟用户使用产品都是有真实场景的。
总之，设计测试任务就是“谁在什么情况下要做什么事”，紧抓“人”、“情景”、“目标”三个要素。
4.1.3 撰写测试脚本
撰写测试脚本是为了预防在正式测试时不知道该问什么，该记录什么，没有头绪，一片混乱。可以根据测试结束后的结果统计分析的维度出发，结合任务清单，自下而上的分析应该在测试时需要问的问题，还有需要观察的注意点。比如：
询问：进入页面，首先看到什么？然后看到什么？ 用户会想点开什么地方？每个分类上面的数字，用户有没有注意到？……
观察：用户探索了那些内容？用户说了什么？正面评价？负面评价？用户的表情，是否有皱眉噘嘴等负面表情？
4.1.4 测试环境准备
测试实验室所需要的硬环境肯定是要完善的，比如：
a) 实验室环境：不管是会议室、还是专门的装有单面玻璃的观察实验室，至少要干净整洁，能让用户心情放松的；
b) 测试设备：使用什么终端产品、网络环境要畅通、账号要先注册等；
c) 记录设备：录音、录像、录屏等，记录测试过程可以帮设计师会议访问的场景，填补一些缺失的笔记。可以用一些录音机、摄像机、眼动仪、鼠标轨迹记录、QuickTime、Mobizen、Display Recorder、SCR、Magitest等软硬件。
4.1.5 预测试
预测试就是正式实施之前，邀请同事模拟几次，发现测试时的问题。把正式的流程走一下，包括设备调试、访谈切入、问题提问、观察记录、结果分析，把录音和录像都看一遍，从中发现测试时的问题。
4.1.6 招募用户
样本数量：根据Nielsen和Landauer的研究，可用性测试发现系统中问题数量与测试人数遵循以下公式：P=N （1-（1- L ） n ）
其中P为发现问题的数量，N是系统中存在问题的总量，L是通过研究单个用户可以发现的用户比例，根据经验L的值一般被定义为31%。此时我们可以绘制出P关于n的曲线，如下图所示。此外，Nielsen还给出了以下的一份数据：根据83例NNgroup最近进行过的可用性咨询的案例分析可以得出下右图的可用性问题数量——招募用户数量的关系。我们可以看到，在招募5-8名用户的时候，就足以暴露出系统中的大部分可用性问题了。而此时再测试更多的用户，并不会为我们的洞察带来明显的提升。
寻找用户：分为三步骤，招募信息投放—>筛选问卷—>电话联系，核心原则是“让最具有代表性的用户参与”，通过了解用户的态度、行为、目标来甄选，与用户画像匹配的用户。
4.2 正式测试4.2.1 调节氛围
从测试当天接待用户开始就需要保持一个友好态度，能够让用户放下警惕，能够有一个愉悦的心情去面对测试。开场主持人可以做一些自我介绍，热热场，缓和一下测试的氛围，表明测试的目的，告知用户我们非常希望您能畅所欲言，这个测试没有对错之分，不要担心做不好，真诚的希望我们和您一起去发现产品的问题。而且如果有录音或录像，一定要让用户知晓有此类行为，但是会对测试资料保密，可以签署保密协议。
4.2.2 开始测试
根据准备的测试脚本进行测试，至少需要两位工作人员，一名主持人做任务引导、询问问题工作，一名观察记录员观察用户情绪、动作、记录用户行为、想法。测试中需要注意以下几点：
a) 观察：察言观色，识别用户的情绪，思考中、皱眉、犹豫、惊讶等，通过用户情绪判别任务的难易，用户是否无法完成任务，那么就应该终止该任务的测试，并且舒缓用户情绪。
b) 询问：询问采用一般疑问句，具体客观地重复用户刚才的行为表现，如果用户没有自己主动说出原因，可以“顺便”问以下“为什么？”或通过身体前倾、目光注视等非语言方式来暗示用户你希望能听到更多内容，若用户很快、坚定地说出原因，则该理由的可信度较高；如果用户犹豫、或难以说出原因，就不要继续追问。
c) 倾听：做一个好的聆听者，用户讲话时，可以用点头、嗯嗯、眼神交流等反馈给予用户提示我们在认真的听，您继续讲下去。
d) 鼓励：鼓励用户出声思考，测试中的问题大胆讲出来，而且要肯定用户的建议，给予鼓励夸奖，认同其价值。用户遇到困难时，不要提供帮助，可以适当鼓励。
4.3 数据整理与分析
首先一位用户测试结束后，可以先趁着记忆犹新，简单的做半小时整理工作，主持人和笔录互相核对。然后等全部测试完成再进行可用性水平和问题分析。这里按照我的理解做了一份可用性问题的总结模板：
五、简易的可用性测试
在《Don`tMakeMeThink》中Steve提到一种10美分的简易可用性测试，对于早期起步阶段、需要快速迭代的产品，可以采用这种方式简单做一下可用性测试。
六、可用性经验准则
《可用性工程》中讲到11条可用性的经验准则，也一起记录一下：
简洁而自然的对话
使用用户的语言
将用户的记忆负担减到最小
一致性
原创文章，作者：筱凯，如若转载，请注明出处：https://www.jingyueyun.com/ask/484.html
