可用性测试的测试的方法
2024-05-10
1. 可用性测试的测试的方法
所谓可用性评估，即是对软件“可用性”进行评估，检验其是否达到可用性标准。目前的可用性评估方法超过20种，按照参与可用性评估的人员划分，可以分为专家评估和用户评估；按照评估所处于的软件开发阶段，可以将可用性评估划分为形成性评估和总结性评估。形成性评估是指在软件开发或改进过程中，请用户对产品或原型进行测试，通过测试后收集的数据来改进产品或设计直至达到所要求的可用性目标。形成性评估的目标是发现尽可能多的可用性问题，通过修复可用性问题实现软件可用性的提高，总结性评估的目的是横向评估多个版本或者多个产品，输出评估数据进行对比。网站可用性测试包含的步骤有：定义明确的目标和目的,安装测试环境，选择合适的受众，进行测试和报告结果。
2. 如何进行可用性测试和用户研究
可用性测试是一种操作性较强的迭代设计方法。关于迭代设计，还有一种说法叫“MVP"（Minimum Viable Product，最低可行产品），即快速推出产品，后续不断改进。 这能有效地降低产品研发周期，快速占领市场，快速获得客户反馈。 很多人对设计的误解，认为设计师都是些不食人间烟火，深夜案头苦思冥想闭门几个月最终憋出来一个惊世设计方案，而当灵感枯竭时则颓废懒散无所事事的人， 认为设计依赖于捉摸不定的灵感而无法进行项目时间管控。这种观点更多地认为设计就是临门一脚的结果。事实上，假如脱离了中场组织和调整，缺少了必要的控球倒脚，临门一脚往往无果而终。 设计更多是过程，沟通过程。可用性测试提供了这样一种简单直接的沟通方式。通过这种方式获得用户反馈，并以此为设计依据迅速调整产品功能乃至产品方向。 如能秉持这种设计即沟通的理念，自然不会将可用性测试仅仅看做是一种无奈之选。 小到一个图标的辨识，页面导航，功能使用，大到某项业务的办理，都可以拿来做可用性测试。 测试对象的选取也没有过多要求，任何不相关的同事，朋友，甚至路人都可以被请来参加你的可用性测试。除了专业度很高的比如业务处理等，一般性的操作对是否具有真正用户资质的要求并不高。 原因在于，可用性测试最大的作用是发现明显的可用性问题（不要怀疑设计师的水平，有太多设计失败案例是源于看起来简单愚蠢之极的错误），而这些问题多数跟专业无关，只跟常识有关。 具体操作也很简单，无需拘泥于测试地点，准备材料，等等，一张纸一枝笔足够矣。 这里操作关键的点在， 1. 场景代入，2. 观察和倾听。 场景代入是指让被试者知道大概的背景，比如这个软件功能是做什么的，谁会是使用者等，但不告诉具体如何操作（有点小白鼠的意思）。 观察，靠的不仅仅是眼睛，而是心。只有清楚自己要借助测试得到什么，才能不错过转瞬即逝的细节。这要求主试者本人对设计有较深的理解。 其他的工作则是为了确保可用性测试顺利进行。比如前期需要邀请，需要准备任务清单，提问清单，需要记录的设备工具，还有一点小意思。 但真正影响可用性测试质量的只取决于主试者自身的经验和水平。 链接：http://www.zhihu.com/question/20418124/answer/25583970 来源：知乎
3. 可用性测试的评估方法
（User Test）就是让用户真正地使用软件系统，由实验人员对实验过程进行观察、记录和测量。这种方法可以准确地反馈用户的使用表现、反映用户的需求，是一种非常有效的方法。用户测试可分为实验室测试和现场测试。实验室测试是在可用性测试实验室里进行的，而现场测试是由可用性测试人员到用户的实际使用现场进行观察和测试。用户测试之后评估人员需要汇编和总结测试中获得的数据，例如完成时间的平均值、中间值、范围和标准偏差，用户成功完成任务的百分比，对于单个交互，用户做出各种不同倾向性悬着的直方图表示等。然后对数据进行分析，并根据问题的严重程度和紧急程度排序撰写最终测试报告。
4. 可用性测试的评估方法
方法总结自书籍《蝶变：移动用户体验设计之道》
在可用性测试中，如何对任务进行评估呢？本文介绍了一个任务评估模型，并给出了模型的具体使用方法。
可用性测试主要从 可用性 和 功能价值 两大方面进行评估。可用性的维度包括： 有效性、效率、满意度。 功能价值包括：商业价值、 用户价值 。因为商业价值是既有的，不需要在可用性测试中收集数据。
所以可用性测试就从 有效性、效率、满意度、用户价值 4个维度来评估。
1）有效性说明
顺利完成 ：用户轻松地完成任务卡上所有的要求，得1分;
部分完成 ：用户只完成了一部分的任务，得0.5分;
失败 ：超过先点时间仍然无法完成任务;用户认为自己完成不了而放弃了任务，得0分
功能有效性: 有效性=(完全完成任务用户数x1+部分完成任务用户数x0.5)/用户总数
2）效率说明
熟练用时 ：对功能熟悉的人（PM、测试、设计师）按照任务提示进行操作，记录完成操作所需的时间，多个人操作取平均值,四舍五入按秒计时。
限定时间 ：根据熟练用时而定,熟练用时的3～10倍，保证一个任务不超10分钟。计时单位：四舍五入精确到分。
完成时间 ：开始时间：用户拿到任务卡开始计时。不要等用户读完任务卡计时，因为有人喜欢读一条记一条，有人喜欢读完所有任务再操作。结束时间：不要在观察到任务完成了就结束，而要用户宣布自己已完成再结束，因为有人在操作完喜欢检查自己是否操作成功。计时单位：四舍五入精确到分。
四舍五入精确到秒,数值越大效率越低： 效率=平均用时/熟练用时
3）满意度说明
1~7分。1代表非常不满意，7代表非常满意
4）用户价值说明
该功能对完成工作有多大帮助：1~7分。1代表完全没有帮助，7代表有很大帮助。
5)总分计算
对有效性,效率,满意度做量化处理,按照5:3:2的权重计算得分：
可用性水平=有效性x0.5-效率x0.3+满意度x0.2
将任务的有效性、效率、满意度、用户价值4个维度进行衡量评估后，可以将所有任务的数据横向对比，用折线图来展示：
在同一标准下对比不同任务的可用性水平，结合功能价值评估，可以得出下图的 四象限图 。在四象限图中，功能价值高可用性低的任务具有最高优先级。
注意：优化可用性问题时，应以功能(即任务)为单位，而不是以问题为单位，这样能站在更整体的角度考虑问题，不至于修改了很多细节还是不好用。先确定每个功能的优先级，再确定每个功能里的具体可用性问题的优先级。
5. 手把手教你做可用性测试
可用性测试是用户体验设计师采用的一种测试方法，用来确保产品设计可以带给用户好的体验。 可用性测试常发生在低保真设计和高保真设计阶段，根据用户试用的反馈意见，对设计进行修改。这个阶段的修改代价较小，因为只涉及到原型图的修改；如果等到前端页面开发完成后再修改，代价就比较大。同时，可用性测试还可以让用户验证产品的创意，加深产品经理对产品的理解，避免开发团队浪费时间和精力开发没有把握的产品。 尽管可用性测试是设计师常用的方法，但其思想、操作方法也可以被产品经理采用，比如在产品开发完成后、上线前进行测试，尽可能避免上线后因体验不好或功能不完善造成用户流失。 可用性测试可以分为制定测试计划 01 好的用户体验的标准 在具体介绍可用性测试每个步骤之前，先来看一下一个好的用户体验有哪些标准。 1. 易用 产品的设计、结构、意图对用户来说是清晰的；产品功能是容易理解的；产品导航是容易操作的；产品是可以完成某项任务的。比如装在玻璃瓶里的番茄酱非常难倒出来，改成可挤压的设计就会容易的多；使用银行卡付款时，每次输入一长串数字非常麻烦，使用拍照识别就非常方便。 2. 有用 产品设计是否帮助用户解决了痛点或问题？是否帮助用户实现了目标？是否为用户带去了独特的体验。软件产品功能的有用性可能比较难以判断，一个功能或多或少都会有人使用，可以根据使用人数的多少来判断，如果人数太少，那么这个功能或许就不太有用；太多无关紧要功能的堆砌可能会掩饰产品的核心价值，即造成所谓的“功能膨胀”。 3. 令人愉快的 用户使用产品是否感到愉快，这在用户和产品之间创造了一种积极的联系。用户体验设计师通过在制作产品时考虑到用户的想法和感受来促进这种积极的联系。提起令人愉快的设计，第一个想到的可能是苹果公司的设计。用户或许在审美上存在差异，但总体来说，是能够区分出好的设计和不好的设计。 02 示例 Art Travel是一款为艺术爱好者打造的app，用户可以使用app查询他们喜欢的展览并可以预订门票、导览工具和导游；分享参加展览的状态；浏览艺术家的作品。接下来的步骤会用这个app做为示例。 1. 制定测试计划 右边思维导图可以产出，实验计划包含七个部分，分别是项目背景、调研目标、调研问题、kpi、调研方法、参与对象及脚本。 1）项目背景 阐明当前阶段产品情况以及想要调研对象测试的内容，概括整个测试。 以Art Travel为例，背景可以是“我们为艺术爱好者开发了一款可以在线查询展览并预订门票的app；我们想要研究我们的产品是否容易使用，是否存在问题及探究问题解决的办法”。 2）调研目标 你想要从研究中获得什么以及结果如何影响你的设计；目标要小，要具体，以Art Travel为例，可以是“用户能否使用产品完成从发现展览到预订门票，下单支付这个核心流程”。 3）调研问题 是对目标的具体化，要具有实践性，可通过实验来回答；要中立，不要引导用户；要明确收集的数据是定性的还是定量的。 以Art Travel为例，问题可以是“用户完成这个流程大概需要多长时间；我们可以从用户的操作中发现什么问题；支付环节是否容易使用”。 4）kpi 衡量目标的效果，可以是任务上耗费的时间、退出率、转化率、用户错误率、导航或搜索使用频率、购买意愿、推荐意愿、产品可用性评分，以Art Travel为例，可以是“用户下单到结算需要的时间；有多少用户放弃了任务，各个环节的转化率是多少；产品可用性评分是多少；有多少用户愿意使用产品”。 5）调研方法 可分为一手研究(问卷调查、采访、焦点小组和可用性测试)、二手研究(查阅书籍、资料)；定量和定性研究。 以Art Travel为例，这里采用可用性测试的方法。还要说明一下时间、地点、实验方式，比如调研对象根据给出的要求，使用产品完成任务；在任务完成后，需要完成一个调查问卷。 6）参与对象 首先要刻画出要调研的对象的特征（比如性别、年龄、地区、产品使用习惯），然后做出筛选，注意要对象的多样性。以Art Travel为例，调研对象为每个月去参观展览一到两次的艺术爱好者，年龄在18——75，包含学生、全职工作者、退休老人以及艺术家。 7）脚本 描述实验的任务、步骤，以及采访时要问的问题。以Art Travel为例，“打开App，并进行注册”，“请找到个人页面，然后完成资料补充”，“请找到一个你感兴趣的展览”，“在搜索展览时，是否容易操作”。 2. 进行测试 在用户进行测试时，设计人员既可以陪伴在调研对象的身边，也可以不陪伴，两种方法各有自己的优缺点。 1）陪伴 优点是可以获得一手资料，亲自观察调研对象与产品的互动，获得的反馈更加真实；为调研对象提供指导，从而帮助他们完成任务；可以与调研对象交谈，进一步了解他们的想法；对任务进行解释，便于调研对象能够更好理解。 缺点是设计人员可能会影响到调研对象，比如影响参与者的心情，带去偏见，从而影响实验结果。 2）非陪伴 优点是参与者可以自然与产品进行交互；可以按照他们自己的想法使用产品；成本更低，也更方便的安排实验。 缺点是不能需求帮助，设计人员也不能问更多详细的问题，数据也可能更难分析。 链接是谷歌进行的一个非陪伴式测试，可以看一下测试者如何操作的。 在参与者进行测试时，需要对他们的操作进行记录，可以按照这几个维度去记录： 实验任务 点击路径：用户依次点击了哪些按钮 观察：用户的感情、行为以及痛点 直接引用：用户说了什么 易用程度评分 以Art Travel为例，一项任务的记录如下： 任务：搜索展览并从中选择一个你感兴趣的 点击路径：点击搜索框—输入关键字—点击搜索按钮—下滑屏幕—点击进入详情页—返回筛选列表—选择展览 观察：用户有时候不知道输入什么进行搜索 直接引用：缺少排序选项，希望可以按照受欢迎度对筛选结果进行排序 易用度评分：功能完成，但是不太容易使用 3. 结果分析 在完成对参与者操作的记录后，需要对记录进行分析，主要是分析你观察到的，以及参与者所说的。这些记录可以按照不同维度进行分类，比如功能维度、体验维度等。这里提供一个可视化工具方便对记录进行组织。 以Art Travel为例，将记录按照功能为例： 搜索功能：没有说明搜索结果是按照什么排序的；缺少对搜索结果排序的选项；有时候不知道搜索什么 订票功能：没有办法买儿童票和老人票；导览设备是默认的，但不需要；提交订单的时候才被告知已经没有票了；没有显示单价，只显示了总价格 支付功能：支付页没有告诉购买的东西，只显示了总价格；需要输入信用卡账号，非常麻烦；没有显示展览日期，容易忘记 然后对每组的记录进行主题提取，即用简短的话进行总结概括，方便他人理解。并在此基础上，给出洞察、建议。 比如以Art Travel为例，主题可以是根据大多数参与者的反馈，搜索结果无法排序。 洞察：提供可以排序的维度，以便用户按照自己需求对搜索结果排序。 接着，我们需要对主题以及获得的洞察进行优先级排序。产品中存在必须修复的问题，阻碍用户完成任务的因素，欺骗或误导用户的因素，不可访问或难以访问的因素，这些问题的优先级最高。 最后，根据优先级选出几个主题，并根据洞察，对低保真原型图进行修改。 4. 结果分享 这一步是对前面步骤输出的汇总，可以用PPT的形式进行展示。 03 写在最后 这篇文章介绍了可用性测试的基本概念以及实施步骤，希望可以帮你建立起对可用性测试的认知。 最后总结一下可用性测试的意义：以用户为核心，在设计阶段，确保可以产出为用户带来好的体验的产品。
6. 【超详细】可用性测试方法总结
之前总结过一版 交互设计流程图 ，主要是想给自己以后做设计梳理一下过程，但是那份流程里面只有枝干，并没有枝叶，所以针对每个方法我都会撰写一份方法总结，或者说指导，目的就是为以后实践做准备。我期望的效果是，假如一个没有接触过该方法的人看到这份总结，可以按照这个总结一步步完成实验。这就是我最大的目的。下面就是第一份总结《可用性测试方法总结》。
（预警：长文慎入！不过耐心看完肯定会有所收获）
============分割线==================
可用性测试的过程主要有七个步骤：测试前思考、制作测试原型、撰写测试脚本、招募测试者、设置测试环境、预测师、正式测试以及测试结果统计分析。这七个步骤有些事可以并行的，有些是需要严格按照前后顺序执行的。七个步骤组成的流程图如下：
下面我就针对这七个步骤，谈谈具体要怎么做。
不论是做哪个平台的可用性测试，比如PC端、移动端或者是WEB端的可用性测试，最最重要的就是要先理清楚一些基本问题。基本问题就是最经典的5W问题：
·为什么要进行这个测试（why）？测试可以验证一些设计中的疑惑，或者找出现有的界面、流程设计上的问题，具体问题要具体分析。
·什么时候在哪里做测试（when？where？）？时间一般是需要和测试者协调的；地点一般选择在安静的会议室即可，如果公司有专门的实验室那就最好不过了。
·谁要作为测试者（who）？这里可以在招募测试者会详细讨论，不过测试者一般是跟我们的persona接近的人，或者换个说法，测试者一般是我们的目标用户。
·我们要测试什么（what）？测试一些功能点，测试界面设计，测试流程设计，测试设计中有争议、有疑问的地方。
当然这些问题其实都不太难，但是这些都是至关重要的问题。如果没有经过这个步骤的思考，整个可用性测试做下来就会像无头苍蝇，没有一个总的指导。
在想清楚以上的问题之后，需要为可用性测试做一些准备工作。主要工作有：①招募测试者； ②撰写测试脚本； ③制作测试原型。
这三个过程不分先后，条件允许的情况下（人力物力充足时）也可以同时进行。
招募测试者算是可用性测试最重要的一个环节之一的，测试者是否合适直接关系到测试结果的好坏，测试结果直接关系到能否发现产品现有的问题。所以招募测试者是重中之重。理想的测试者是我们的目标用户，所以可用性测试要努力寻找到目标用户作为测试人员。寻找的途径如下：
a)最简便的，假如同事（非同部门）或者好友也是目标用户，可以选用同事或者好友作为测试人员。
b)其次，大型公司都会有自己的用户资料库，可以从这个库里面寻找到测试人员。
c)又或者说，委托第三方机构帮忙寻找测试人员也是允许的，不过效果可能不如自己寻找的。
d)当然，现在的应用一般都会有自己的微博、微信、官网或者论坛，这些是非常好的寻找测试者的渠道。我们可以推送招募测试者的公告，让用户填写一份调查之后，我们再筛选得到我们想要的测死者。公告中要注明奖励，一般为小礼品的奖励，保证对测试者有一定的吸引力，同时又不至于让他们会为了这个礼物对个人信息造假。其次，对于测试者，我们需要进行一个筛选【3】。首先需要用户填写必要的个人信息：比如姓名、电话（邮箱）、空闲时间；然后根据调查选择其他一些个人信息：性别、年龄、职业之后，最后留几道问卷题目进行筛选。
筛选的维度主要有：
·平台。如果测试的产品与平台有关，比如是Android或者iOS，需要在这里进行一个筛选。
·对产品的熟悉程度。比如我们想找一些初级用户和一些高级用户，可以选用“使用时间”这一项来衡量用户对产品的熟悉程度。
测试脚本的好坏直接关系到结果的好坏。在撰写测试脚本之前，我们需要先确定一些结果分析的维度。一般的维度有：a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。对于这些维度的解释具看第文章的最后一部分“测试结果统计分析”。
由于分析的维度会关系到脚本的问题，所以在确定分析维度之后，我们可以对功能点进行任务分析。把所有需要测试的功能点列出来，对每个功能点进行任务设计。对于任务而言，用户最主观的感受就是两个：界面和流程。所以测试脚本又可以从这两个维度去细分。
需要注意的是，可用性测试中，问只是其中的一部分，观察是另外一个重要的内容，所以测试脚本不仅仅要有问的问题，还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时，把总结大纲也写出来，方便后期总结的时候统一结果展示。
特别的，在设计的时候有疑惑的点，或者有争议的点，在可用性测试也可以得到较好的验证。
写完测试脚本之后，可以和利益相关者（项目经理、产品经理、开发等）讨论一下，请他们校验一下测试脚本。
界面：
a)当前界面有什么？
b)每个东西用户觉得是什么？
c)可以操作吗？
d)用什么手势操作方式？
e)操作之后会怎么样？
f)界面显示的内容足够吗，有没有缺少什么东西？
流程： 流程的测试就是根据任务来进行的。把产品的需求文档罗列出来，然后给每个需求配上一个合适的场景，当然也会出现一个场景覆盖多个需求的情况，这也是允许的。然后让用户在场景下去进行任务，观察用户，然后随时提问用户，随时准备回答用户的问题。
以上两点适合所有的可用性测试，但是对于版本更新类的可用性测试，我们还需要了解这个更新对于用户来说的接受度如何，所以需要增加一些对比性的问题：比如说：新旧版的操作流畅度、界面表达对比感受。
最后需要注意的是，一次可用性测试能涵盖的范围有限，所以要限制脚本问题的数量，以及对脚本的问题进行优先级的排序。
举个例子，之前做过一个微信端的众筹平台。我就可以设定以下任务：
可用性测试的原型一般是高保真的Demo，可以用Prott，Flinto，proto，墨刀等来制作，制作力求真实还原应用的最终实现效果。制作高保真Demo是一件耗时耗力的工作，所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo最终也可以给开发参考，所以辛苦也是值得的。甚至于，可以请求开发人员制作原生的程序Demo（针对安卓平台），程序Demo体验会更加好。
当然，纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来，然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作，然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用，同时，测试的时间也会大大增长。同时，动效作为设计的一环在这里无法表现出来，所以结果可能会不如高保真Demo来的好。总之各有利弊，根据实际情况来考虑。
测试环境是指测试的时候需要使用的记录设备，通过把测试过程记录下来可以更好地分析用户的行为，特别是用户自己都没有觉察出来的一些东西。
首先，最最重要的一点是录音，录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景，然后填补一些缺失的笔记。另一方面，录音也可以作为一种存档的材料。同时，录音也存在简单、易操作、隐蔽等特点，使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。
录音之外就是录像，如果有录像的话，录音的步骤就可以省略。录像主要是记录用户的表情和动作。有时候，用户的表情和动作可以传达很多东西，通过把这些信息记录下来可以，设计师偶尔可以挖掘到一些闪光的设计点。
除此之外，用户的屏幕记录也是一种方式，通过用户的屏幕、加上用户操作的动作，表情，可以真实还原用户的使用场景，方便后期的分析。
录像和录屏的操作比较难进行，主要的设备可以参考如下【5】，具体可以查看相关的链接：
·摄像机：记录动作和部分表情
·眼动仪：可以追踪眼球的焦点轨迹，不适合移动端
·鼠标轨迹记录：记录鼠标轨迹，只适用于PC端
·QuickTime (iOS)：仅记录屏幕
·Mobizen (Android)：记录屏幕、手势
·Display Recorder (iOS)：手势、声音
·SCR (Android)：记录屏幕、手势、表情、声音
·Magitest (iOS)：记录屏幕、手势、表情、声音
·Mobizen +AirDroid (Android)：现场观察并记录手势、表情、声音
预测试是正式实施可用性测试前的一次模拟， 模拟有助于发现问题，这时候邀请同事即可。把正式测试的流程走一遍，包括设配的调试、访谈切入、问题的提问、记录者的记录等，然后把记录的录音、视频等放出来看看效果如何，效果不如意的时候再进行调整。
总之，预测试可以帮助发现问题，包括以下几个方面的问题：
·设备的问题。举个例子，录音设备放置的位置会影响录音的效果。
·测试脚本的问题。测试问题是否足够清晰。
·访谈的切入以及问题的提问。
·记录者的记录。
发现问题之后去解决问题，才能使正式测试的时候达到更好的效果。
测试前的接待工作是测试人员对公司的第一印象，给测试人员留下一个好印象、一个好心情有利于可用性测试的进行。所以在这里将一些注意点说一下。
首先，可以事先确认一下用户的行程。遇到刮风、下雨、下雪等恶劣天气的时候可以事先送上问候短信。
其次，遇上用户迟到的情况下，也要保持克制。在迟到五分钟到十分钟之后再给用户电话询问情况，如果用户因故取消测试，也要保持友好的态度。
在接到用户之后，送上一杯温水或者温热的饮料，然后让用户等待一下。最后可以有专门的人员先和用户聊聊天，可以打听一些事情。
正式开始之前有个暖场介绍。首先主持人做一下自我介绍，然后介绍一下测试的目的和时间，需要向用户强调测试的对象是系统，希望用户可以畅所欲言。如果有录音或者录像，需要向用户告知会有此类行为，但是结果完全保密。最后还需要签署保密协议。
正式提问分两个部分：个人信息的小问题和可用性测试任务问题。
小问题主要是为了让用户有个适应的过程，可以迅速进入状态。一般可以询问产品使用习惯、产品偏好、上网情况等，之后的测试问题就是主要的可用性测试的问题。这里需要把问题放入到场景中，让用户在场景中去完成任务。或者可以询问用户的使用习惯，然后引导到脚本中的问题。需要注意的是，不一定要按照脚本的顺序提问，可以随机应变，所以主持人要非常熟悉脚本的内容。除了询问，聆听之外，主持人还要观察用户的神情以及动作，遇上用户有疑问的表情的时候可以适当穿插新的问题，但是尽量不要提供帮助，也不要指出用户的错误或指责动作太慢，但是可以询问用户“为什么这么操作”，必要的时候可以选择停止任务。
测试过程中还需要有一个记录人员，记录人员需要记录：用户做了什么动作和步骤（重点）、用户说了什么、写下自己的疑问（适当时候可以进行提问或者让主持人提问）。
测试结束之后，主持人可以问一下用户的想法，同时让记录人员补充提问，所有问题结束之后，需要对用户表示感谢。送上礼品并接受用户的一些交通费报销票据等。最后要把用户送到公司门口。
测试结束之后，如果有时间可以立马进行整理，因为时间越短，整理出来的内容就越丰富。必要的时候，可以用录音或者录像来辅助。在撰写测试脚本的时候还有一份总结大纲，根据大纲来整理内容。大纲要具备灵活性，可以记录一下测试现场发现的新问题。
记得只是整理而已，每个测试结束都会有一份整理的资料。最后需要汇总多份可用性测试总结，最终出具一份可用性测试结果，根据这份结果进行相应的改进工作。
我们可以从如下几个维度去分析我们的可用性测试【8】（维度之间可能有交叉）：
a)任务完成度。每个测试任务都对应一个目标，只有当用户达到目标之后，我们才认为他们完成了任务。对于每个任务，用户完成的情况如何？有多少用户最终没能完成任务？多少用户需要在主持人提示下完成任务？多少人可以自行完成任务？这些都是很重要的指标
b)致命错误。严重错误指那些阻碍用户完成任务的错误，这些错误非常重要，每一个都要得到足够的重视。
c)非致命错误。非致命错误是指用户能完成任务，但是某些地方会有一些阻滞，会停顿或者思考的错误。这些错误相对来说没那么重要，不过如果发生的次数较多，该类错误也需要得到重视。
d)完成任务的时间。每个任务需要完成多少时间，决定了交互设计流程和界面的设计是否足够友好。
e)主观情绪。用户对于任务的主观感受，比如是否足够简单，是否容易找到信息，可以让用户衡量一下。
f)偏好和建议。可以让用户说出产品中哪些地方很喜欢？哪些地方不喜欢？或者让他们提一下建议。
【1】Adaptingyour usability testing practise for mobile http://www.userfocus.co.uk/articles/testing-for-mobile.html
【2】移动可用性测试(一):概述 – 腾讯ISUX–社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-one.html
【3】网易公司用户访谈活动招募问卷 http://survey.askform.cn/51194-79597.aspx
【4】用户访谈心得总结– 腾讯CDC http://cdc.tencent.com/?p=5690
【5】移动可用性测试（三）：现场测试– 腾讯ISUX– 社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-three.html
【6】用户研究经验谈-采铜学心录-博客大巴 http://xuexinlu.blogbus.com/c4061443/
【7】简单快速的可用性测试|网易用户体验设计中心 http://uedc.163.com/4151.html
【8】Planninga Usability Test Usability.gov http://www.usability.gov/how-to-and-tools/methods/planning-usability-testing.html
7. 【超详细】可用性测试方法总结
之前总结过一版 交互设计流程图 ，主要是想给自己以后做设计梳理一下过程，但是那份流程里面只有枝干，并没有枝叶，所以针对每个方法我都会撰写一份方法总结，或者说指导，目的就是为以后实践做准备。我期望的效果是，假如一个没有接触过该方法的人看到这份总结，可以按照这个总结一步步完成实验。这就是我最大的目的。下面就是第一份总结《可用性测试方法总结》。
（预警：长文慎入！不过耐心看完肯定会有所收获）
============分割线==================
可用性测试的过程主要有七个步骤：测试前思考、制作测试原型、撰写测试脚本、招募测试者、设置测试环境、预测师、正式测试以及测试结果统计分析。这七个步骤有些事可以并行的，有些是需要严格按照前后顺序执行的。七个步骤组成的流程图如下：
下面我就针对这七个步骤，谈谈具体要怎么做。
不论是做哪个平台的可用性测试，比如PC端、移动端或者是WEB端的可用性测试，最最重要的就是要先理清楚一些基本问题。基本问题就是最经典的5W问题：
·为什么要进行这个测试（why）？测试可以验证一些设计中的疑惑，或者找出现有的界面、流程设计上的问题，具体问题要具体分析。
·什么时候在哪里做测试（when？where？）？时间一般是需要和测试者协调的；地点一般选择在安静的会议室即可，如果公司有专门的实验室那就最好不过了。
·谁要作为测试者（who）？这里可以在招募测试者会详细讨论，不过测试者一般是跟我们的persona接近的人，或者换个说法，测试者一般是我们的目标用户。
·我们要测试什么（what）？测试一些功能点，测试界面设计，测试流程设计，测试设计中有争议、有疑问的地方。
当然这些问题其实都不太难，但是这些都是至关重要的问题。如果没有经过这个步骤的思考，整个可用性测试做下来就会像无头苍蝇，没有一个总的指导。
在想清楚以上的问题之后，需要为可用性测试做一些准备工作。主要工作有：①招募测试者； ②撰写测试脚本； ③制作测试原型。
这三个过程不分先后，条件允许的情况下（人力物力充足时）也可以同时进行。
招募测试者算是可用性测试最重要的一个环节之一的，测试者是否合适直接关系到测试结果的好坏，测试结果直接关系到能否发现产品现有的问题。所以招募测试者是重中之重。理想的测试者是我们的目标用户，所以可用性测试要努力寻找到目标用户作为测试人员。寻找的途径如下：
a)最简便的，假如同事（非同部门）或者好友也是目标用户，可以选用同事或者好友作为测试人员。
b)其次，大型公司都会有自己的用户资料库，可以从这个库里面寻找到测试人员。
c)又或者说，委托第三方机构帮忙寻找测试人员也是允许的，不过效果可能不如自己寻找的。
d)当然，现在的应用一般都会有自己的微博、微信、官网或者论坛，这些是非常好的寻找测试者的渠道。我们可以推送招募测试者的公告，让用户填写一份调查之后，我们再筛选得到我们想要的测死者。公告中要注明奖励，一般为小礼品的奖励，保证对测试者有一定的吸引力，同时又不至于让他们会为了这个礼物对个人信息造假。其次，对于测试者，我们需要进行一个筛选【3】。首先需要用户填写必要的个人信息：比如姓名、电话（邮箱）、空闲时间；然后根据调查选择其他一些个人信息：性别、年龄、职业之后，最后留几道问卷题目进行筛选。
筛选的维度主要有：
·平台。如果测试的产品与平台有关，比如是Android或者iOS，需要在这里进行一个筛选。
·对产品的熟悉程度。比如我们想找一些初级用户和一些高级用户，可以选用“使用时间”这一项来衡量用户对产品的熟悉程度。
测试脚本的好坏直接关系到结果的好坏。在撰写测试脚本之前，我们需要先确定一些结果分析的维度。一般的维度有：a)任务完成度b)致命错误c)非致命错误d)完成任务的时间e)主观情绪f)偏好和建议。对于这些维度的解释具看第文章的最后一部分“测试结果统计分析”。
由于分析的维度会关系到脚本的问题，所以在确定分析维度之后，我们可以对功能点进行任务分析。把所有需要测试的功能点列出来，对每个功能点进行任务设计。对于任务而言，用户最主观的感受就是两个：界面和流程。所以测试脚本又可以从这两个维度去细分。
需要注意的是，可用性测试中，问只是其中的一部分，观察是另外一个重要的内容，所以测试脚本不仅仅要有问的问题，还有需要撰写工作人员观察的注意点。同时可以在撰写完测试脚本的同时，把总结大纲也写出来，方便后期总结的时候统一结果展示。
特别的，在设计的时候有疑惑的点，或者有争议的点，在可用性测试也可以得到较好的验证。
写完测试脚本之后，可以和利益相关者（项目经理、产品经理、开发等）讨论一下，请他们校验一下测试脚本。
界面：
a)当前界面有什么？
b)每个东西用户觉得是什么？
c)可以操作吗？
d)用什么手势操作方式？
e)操作之后会怎么样？
f)界面显示的内容足够吗，有没有缺少什么东西？
流程： 流程的测试就是根据任务来进行的。把产品的需求文档罗列出来，然后给每个需求配上一个合适的场景，当然也会出现一个场景覆盖多个需求的情况，这也是允许的。然后让用户在场景下去进行任务，观察用户，然后随时提问用户，随时准备回答用户的问题。
以上两点适合所有的可用性测试，但是对于版本更新类的可用性测试，我们还需要了解这个更新对于用户来说的接受度如何，所以需要增加一些对比性的问题：比如说：新旧版的操作流畅度、界面表达对比感受。
最后需要注意的是，一次可用性测试能涵盖的范围有限，所以要限制脚本问题的数量，以及对脚本的问题进行优先级的排序。
举个例子，之前做过一个微信端的众筹平台。我就可以设定以下任务：
可用性测试的原型一般是高保真的Demo，可以用Prott，Flinto，proto，墨刀等来制作，制作力求真实还原应用的最终实现效果。制作高保真Demo是一件耗时耗力的工作，所以在制作的时候可以适当忽略一些动效、界面等。不过做出来的Demo最终也可以给开发参考，所以辛苦也是值得的。甚至于，可以请求开发人员制作原生的程序Demo（针对安卓平台），程序Demo体验会更加好。
当然，纸面模型也是另外一种非常好的工具。纸面模型需要把纸面模型都只做出来，然后把所有的弹出窗口、下拉菜单等控件也制作出来。然后设计师充当wizard of oz来辅助用户完成任务。即用户对着纸面模型来操作，然后设计师实时反馈用户的操作。这样子要求设计师非常熟悉测试的应用，同时，测试的时间也会大大增长。同时，动效作为设计的一环在这里无法表现出来，所以结果可能会不如高保真Demo来的好。总之各有利弊，根据实际情况来考虑。
测试环境是指测试的时候需要使用的记录设备，通过把测试过程记录下来可以更好地分析用户的行为，特别是用户自己都没有觉察出来的一些东西。
首先，最最重要的一点是录音，录音一方面是在整理访谈记录的时候可以帮助设计师回忆访问的场景，然后填补一些缺失的笔记。另一方面，录音也可以作为一种存档的材料。同时，录音也存在简单、易操作、隐蔽等特点，使用录音笔或者现在随处可见的智能机即可完成录音。所以强烈推荐进行可用性测试的时候一定至少要录音。
录音之外就是录像，如果有录像的话，录音的步骤就可以省略。录像主要是记录用户的表情和动作。有时候，用户的表情和动作可以传达很多东西，通过把这些信息记录下来可以，设计师偶尔可以挖掘到一些闪光的设计点。
除此之外，用户的屏幕记录也是一种方式，通过用户的屏幕、加上用户操作的动作，表情，可以真实还原用户的使用场景，方便后期的分析。
录像和录屏的操作比较难进行，主要的设备可以参考如下【5】，具体可以查看相关的链接：
·摄像机：记录动作和部分表情
·眼动仪：可以追踪眼球的焦点轨迹，不适合移动端
·鼠标轨迹记录：记录鼠标轨迹，只适用于PC端
·QuickTime (iOS)：仅记录屏幕
·Mobizen (Android)：记录屏幕、手势
·Display Recorder (iOS)：手势、声音
·SCR (Android)：记录屏幕、手势、表情、声音
·Magitest (iOS)：记录屏幕、手势、表情、声音
·Mobizen +AirDroid (Android)：现场观察并记录手势、表情、声音
预测试是正式实施可用性测试前的一次模拟， 模拟有助于发现问题，这时候邀请同事即可。把正式测试的流程走一遍，包括设配的调试、访谈切入、问题的提问、记录者的记录等，然后把记录的录音、视频等放出来看看效果如何，效果不如意的时候再进行调整。
总之，预测试可以帮助发现问题，包括以下几个方面的问题：
·设备的问题。举个例子，录音设备放置的位置会影响录音的效果。
·测试脚本的问题。测试问题是否足够清晰。
·访谈的切入以及问题的提问。
·记录者的记录。
发现问题之后去解决问题，才能使正式测试的时候达到更好的效果。
测试前的接待工作是测试人员对公司的第一印象，给测试人员留下一个好印象、一个好心情有利于可用性测试的进行。所以在这里将一些注意点说一下。
首先，可以事先确认一下用户的行程。遇到刮风、下雨、下雪等恶劣天气的时候可以事先送上问候短信。
其次，遇上用户迟到的情况下，也要保持克制。在迟到五分钟到十分钟之后再给用户电话询问情况，如果用户因故取消测试，也要保持友好的态度。
在接到用户之后，送上一杯温水或者温热的饮料，然后让用户等待一下。最后可以有专门的人员先和用户聊聊天，可以打听一些事情。
正式开始之前有个暖场介绍。首先主持人做一下自我介绍，然后介绍一下测试的目的和时间，需要向用户强调测试的对象是系统，希望用户可以畅所欲言。如果有录音或者录像，需要向用户告知会有此类行为，但是结果完全保密。最后还需要签署保密协议。
正式提问分两个部分：个人信息的小问题和可用性测试任务问题。
小问题主要是为了让用户有个适应的过程，可以迅速进入状态。一般可以询问产品使用习惯、产品偏好、上网情况等，之后的测试问题就是主要的可用性测试的问题。这里需要把问题放入到场景中，让用户在场景中去完成任务。或者可以询问用户的使用习惯，然后引导到脚本中的问题。需要注意的是，不一定要按照脚本的顺序提问，可以随机应变，所以主持人要非常熟悉脚本的内容。除了询问，聆听之外，主持人还要观察用户的神情以及动作，遇上用户有疑问的表情的时候可以适当穿插新的问题，但是尽量不要提供帮助，也不要指出用户的错误或指责动作太慢，但是可以询问用户“为什么这么操作”，必要的时候可以选择停止任务。
测试过程中还需要有一个记录人员，记录人员需要记录：用户做了什么动作和步骤（重点）、用户说了什么、写下自己的疑问（适当时候可以进行提问或者让主持人提问）。
测试结束之后，主持人可以问一下用户的想法，同时让记录人员补充提问，所有问题结束之后，需要对用户表示感谢。送上礼品并接受用户的一些交通费报销票据等。最后要把用户送到公司门口。
测试结束之后，如果有时间可以立马进行整理，因为时间越短，整理出来的内容就越丰富。必要的时候，可以用录音或者录像来辅助。在撰写测试脚本的时候还有一份总结大纲，根据大纲来整理内容。大纲要具备灵活性，可以记录一下测试现场发现的新问题。
记得只是整理而已，每个测试结束都会有一份整理的资料。最后需要汇总多份可用性测试总结，最终出具一份可用性测试结果，根据这份结果进行相应的改进工作。
我们可以从如下几个维度去分析我们的可用性测试【8】（维度之间可能有交叉）：
a)任务完成度。每个测试任务都对应一个目标，只有当用户达到目标之后，我们才认为他们完成了任务。对于每个任务，用户完成的情况如何？有多少用户最终没能完成任务？多少用户需要在主持人提示下完成任务？多少人可以自行完成任务？这些都是很重要的指标
b)致命错误。严重错误指那些阻碍用户完成任务的错误，这些错误非常重要，每一个都要得到足够的重视。
c)非致命错误。非致命错误是指用户能完成任务，但是某些地方会有一些阻滞，会停顿或者思考的错误。这些错误相对来说没那么重要，不过如果发生的次数较多，该类错误也需要得到重视。
d)完成任务的时间。每个任务需要完成多少时间，决定了交互设计流程和界面的设计是否足够友好。
e)主观情绪。用户对于任务的主观感受，比如是否足够简单，是否容易找到信息，可以让用户衡量一下。
f)偏好和建议。可以让用户说出产品中哪些地方很喜欢？哪些地方不喜欢？或者让他们提一下建议。
【1】Adaptingyour usability testing practise for mobile http://www.userfocus.co.uk/articles/testing-for-mobile.html
【2】移动可用性测试(一):概述 – 腾讯ISUX–社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-one.html
【3】网易公司用户访谈活动招募问卷 http://survey.askform.cn/51194-79597.aspx
【4】用户访谈心得总结– 腾讯CDC http://cdc.tencent.com/?p=5690
【5】移动可用性测试（三）：现场测试– 腾讯ISUX– 社交用户体验设计 http://isux.tencent.com/mobile-usability-testing-three.html
【6】用户研究经验谈-采铜学心录-博客大巴 http://xuexinlu.blogbus.com/c4061443/
【7】简单快速的可用性测试|网易用户体验设计中心 http://uedc.163.com/4151.html
【8】Planninga Usability Test Usability.gov http://www.usability.gov/how-to-and-tools/methods/planning-usability-testing.html
8. 可用性测试的实用性
无论使用正式的或非正式的设备你都可以做可用性测试。使用任何类型的设备，你都可以采用各种正式或非正式的方法。 使用下述任何一种设置，你都可以进行有效的可用性测试：* 两室或三室的固定实验室，配备视听设备* 会议室，用户的家或工作室，配备便携式录音设备* 会议室，用户的家或工作室，没有录音设备也可以用人眼观察和笔记来代替* 当用户在不同地点可以远程控制因此，即使你没有或没法找到一个固定的实验室，你也应该进行可用性测试。不要说，“因为我们没有一个可用性实验室，所以我们没法做可用性测试。 只要去做！在任何空间你都可以完成。 看情况。一个典型的测试需要8至16个人（每用户组）。如果每个用户将花费一小时，就意味着每个用户组的测试需要一到两个工作日。 当你的项目处在： * 纸上原型或早期开发阶段 * 计划通过几轮测试整个开发 * 有相当一致的用户群 如果只要人帮忙找出严重问题，你可能只需要4到6人。 * 如果您有不同的潜在用户群组（例如医生、病人、研究人员），你需要所有这些群体的用户代表。如果你对用户的电脑操作或网络经验有要求，还需要包括经验较少的和经验较多的用户。 * 如果你要对你的产品或系统进行正式的定量测试，你将需要更多的人以获得统计上有意义的结果。对于诊断型的可用性测试，6至8个用户通常是不足以揭露产品的大部分问题的。 * 如果在网站开发过程中你一直在做迭代（重复）的可用性测试，就会有许多用户参加其中一个或另一个版本的网站测试。因此，尽管每个可用性测试只有少于10名的测试参予者，但在网站推出前你可能需要15到30人参加测试。做可用性测试需要多少费用？ 成本要看网站的大小，你的测试量，预期的用户类型数目，以及你期望这个测试正规到什么程度。 如果你已经有一个标准的测试程序和可用的材料设备，可用性测试将进行地很快很便宜。如果你或你的用户招聘公司拥有一个用户数据库，用于招募的时间就可以大量节约，因此，花费会更少。 应该考虑这些因素：* 计划所用的时间：确定测试的主要问题，需要测试的用户类型，招聘的用户的筛选问卷以及测试场景。* 招聘的花费：公司人员的时间，给招聘公司（通常是一个很好的选择）的花费，可用性专家需要花时间熟悉网站及其制作团队，设计相应的测试场景，如果你需要录制测试过程，还需要花费实验室或便携式摄录设备的租金。* 团队观察用户（进行测试）花费的时间* 付给测试参与者的报酬或礼物* 分析视听资料，查找存在的问题以及推荐解决办法所用的时间* 和开发人员讨论变动和修改方案，撰写调查结果和建议报告所用的时间。记住，预算分析要包含多个可用性测试。打造一个网站（或产品）的可用性是一个反复迭代的过程。你会发现，用在在开发过程中几个小测试的预算比起在项目末期只做一个大型测试要有价值的多。网站可用性测试是为了实现跨形式的视觉一致性，包括测试屏幕分辨率改变时的显示，边距和列布局，表单的颜色和大小，标签使用的字体，按钮的大小，所使用的热踺或快捷键，使用的动画/图形，按钮等控件的标签，同一字段的文本框的长度，日期和时间字段的格式。
最新文章
热门文章
推荐阅读