上一篇 我们讲到了情感化设计，这次，我们来探讨一下可用性测试的开展方法。

设计师的划分升级从早期的网页美工-UI设计师-UX设计师再到现在的全链路设计师/产品设计师...一大波新概念的设计职称和相关行业向我们“袭来”。虽然可能还是和老板在照面的时候被来一句：那个美工，下午帮我修张图的“恶魔”要求。但是确实设计是越来越往“T”字形出发了，即首先保证自己有最擅长的“一竖”R技能，到纵深发展其他关联领域的“一横”的QWE技能。

设计越来越被全世界的公司所关注和利用，设计驱动创新与商业价值这句话愈发的被更多公司所认同，全球最大名宿品牌爱彼迎（Airbnb）的三位创始人都是设计师出身，而阿里达摩院18罗汉里面也有设计师的身影，根据麦肯锡（Mikinsey）的新研究分析（样本为200位资深设计领袖和100位CEO），由设计引导的公司比其他公司的收入多了32%...

扯远了，拉回正题，总之一步一步保持学习，开始进入正题。

国际定义：

根据UX国际标准 ISO 9241 标注定义，“可用性”指的是产品在特定的情境下被tending用户使用时，它所具备的有效性（Effcctivess），很大程度对应的是User goal：效率（Efficiency）和满意度（Satisaction）。

概述含义：

通过观察典型用户，在使用产品过程中制定的任务，得出可用性问题从而优化产品。

简单来说：

观察用户使用产品，并作出优化。

可用性测试能帮助团队

可用性测试在产品的研发设计阶段，到后期上线的迭代阶段，都是全程跟随整个项目持续进行 ，越早的进行可用性测试，越能够发现并避免很多问题，及时纠正优化项目结构，且优化设计产出和开发的精准利用。在一个项目中，这套测试方法是十分重要的，它能让你确信它是符合产品目标和用户需要。

可用性测试能帮助设计师

在前面我说到，现在的设计师，都是往更全面的方向拓展自己的专业能力的，你设计方案做的很漂亮，但是切勿过度基于设计理念而去设计，为设计而设计会让你困入被质疑的困境，设计本身的评判标准就略带有设计主观性。我们的设计方案最好是结合用户真实测试的数据（产品出发）来配合推导去设计，这样你的方案就有一个度量标准。很多团队都没配备用户研究员，所以身为设计师的你应该要学会主动出击测试，利用测试结果，为你的设计方案提供可量化的依据，是时候拿起科学的方法去设计让你的boss改口叫你“设计师”了！

可用性测试分为两种测试范围

1.DIY可用性测试

2.大范围总结性测试

我们在这里主要讲的是小版本的diy可用性测试

DIY可用性测试（ Guerrilla Test）在国外被广泛认同并使用的测试方法，它属于小样本定性测试，仅需5～9名用户单独利用半小时之内即可完成。由于它的方便快捷性（且低成本），大家都可以在自己公司快速进行对产品的测试。

而大范围总结性测试由于需要参与的测试人员过多（通常是上百名）而对于资源有限的小型团队不太友好，所以暂不考虑。

这里以蓝湖App的可用性测试来做范本，我们来开展实践可用性测试。

测试目的：

以蓝湖App的设计师群体为用户画像，从视觉设计、交互、再到产品功能来挖掘问题，随后提出新的优化方案。

大概流程：

招募用户测试产品流程 ，观察用户并交流得到用户反馈，随后分析数据优化产品。

详细的可用性测试的“六步开展法”

明确目标是指我们测试前期计划是对整个产品（或某些功能板块）的测试方向确定，需要注意以下三个点：

1.对产品信息内容进行穷举

2.确定功能分类纬度，并对其排序形成测试目标

3.分析内容较多的功能板块，决定是否继续拆分

我们用蓝湖App首页来为测试目标的话，就需要划分目标如下：

经梳理首页的部分功能如下

当我们了解了我们想测的目标的时候，我们就可以编写交互脚本（作为对话），对其产品or某个功能模块进行基准测试，随后绘制用户测试路径任务并挖掘目标。

测试任务创建 其实就是指设定你要测试产品功能的具体操作流程任务，这样做是为了分开来观察每一步用户在实际操作过程中发生的情况。

由于每个公司的产品的体量有大有小，可以全局进行与部分板块进行路径测试，在这里主要是阐述测试方法。

以蓝湖App首页为测试板块，我们制定了对应的操作行为目标路径。（在这只展示部分参考测试路径）

而在制定目标操作指令的时候，我们需要制定精确但不繁杂的测试路径。利用简单而善于理解的语言来让用户无压力的测试。

（切忌 语言不连贯/ 文案过于冗长/操作行为断联/无关相关测试内容）

而下面我们将会分析每个功能的具体操作行为和场景， 概括为类似“剧本”一样的一段段的动作戏，让我们请的“临时演员”（真实用户）来进行操作，确保每一项任务都表达清晰。

1：浏览首页所有项目，进入"蓝湖 APP"项目并找到名为"首页"的设计图，然后回到首页

2.切换首页的项目查看模式

3. 切换项目排序方式

4.切换到另外一个团队

5. 找到反馈 并反馈一条建议

....

通过功能的关键词阐述出完整的测试体验流程，这里要注意的是，我们给每个任务创建流程，要明确创建的目的，不是为了测试而测试，而是为了得出测试任务的目标是什么。

这里是指我们在规划好前两个步骤后，公司内部进行对剧本的预演习，这里的每一步要模仿真实的用户测试情况，目的是为了规避排查一些我们意想不到的方面（如话术出现问题/流程不太严谨/测试时间过长等），从而在真正的面向用户时，做到很大的纰漏。

这里其实一方面是避免测试软件流程上的疏漏，还可以在硬件上也能提前感知，例如，测试的房间是否安静，光线问题，录音设备等测试工具是否完备无误...

人数要求：

根据国际标准的DIY可用性测试（ Guerrilla Test），一般标准的测试人员为5～9名，5名用户就能在测试过程中发现85%的问题。”不过，当任务设置数量过多，且任务的精细程度和难度多种多样时，这个前提可能就会不成立。如果在招募用户时，注重用户的代表性，那么5人就已经足够了，如果代表性不是很强的，就需要超过5个了，原则上一次测试最多不会超过12个用户。

测试者要求：

招募用户这里的话，一般我们前期确定了主要用户人群，例如蓝湖的主要用户是设计师，我们就确定了测试的受邀用户为设计师，然后会在各种用户渠道里招募，如产品QQ群/官网社区/或者是产品上的浮层入口（这里依照自身产品来定）或者是去公司附近邀请符合标准的测试对象（最快方法），另外确认招募该用户前，最好是先与用户说清楚缘由，以及测试时长和测试地址（一般在公司），让用户充分了解测试的具体情况，避免用户来到测试场合产生厌烦情绪、中途离开的一些行为。所以也需要大致排除一些用户，从对话语气上最少筛选一下愿意积极配合的用户。

招募完成

我们邀请了8名测试人员在每天的不同时间段分别单独测试，注意事项：切勿几名一起测试/不超过半小时的测试时间。

1.测试脚本PPT：

这里的PPT指的是任务目标的PPT，我们以现场投屏的方式，每页展示单独的测试任务，配合讲解员同时讲解任务，做到双重保障用户理解。

2.录音/录像设备：

全程对测试过程的录音/录像（录像没有也行），方便后期研究反馈。

3.统计表格：

问题统计表+用户测试记录表+任务统计表 表格是记录数据的重要途径，后期配合录音音频来分析用户使用产品的需求与痛点。

4.配合人员：

共两名 一个讲解员 一个观察员

讲解员主要是讲述开场白和全程引导用户进行每一个测试路径，而观察员主要是记录用户在进行中发生的一些问题。

5.相关的测试账号设备：

这里需要高度还原用户的账号使用场景，我们会填充一些较为真实的假数据来让用户体验测试产品。并准备好测试手机/电脑等。

如上图 有三类表格，我们将基本的记录员和被测试信息记录完毕后，依据问题分级标准来进行问题的大小等级来区分，统计任务操作时犯的错误，和任务完成的情况记录，为后续的产品优化提供数据支撑。

01:用户测试记录表

这张表单记录的是我们每条测试任务的成功和失败，1.1～1.5是记录单个任务发生的最大可能性的多种情况.

(如操作时间过长/找不到对应的功能或入口/多次点击/无效操作/直接放弃或求助等。)

02:问题统计表

这是记录所有测试用户每条任务发生问题的评级统计表，依照分类标准和评级标准来填写上去，就能得知问题发生率和问题对应分类。

03:任务统计表

这张表是综合统计所有任务单个用户的测试成功率，来分析出每条任务的完成率。

启发式评估法10个评判标准：

1. 系统状状态可见

2. 系统与用户现实世界的匹配

3. 用户控制与自由

4. 一致性与标准化

5. 错误预防

6. 认知而不是记忆

7. 使用的灵活性与效率

8. 美观而精炼的设计

9. 帮助用户识别、诊断和修正错误

10. 帮助和文档

（依照对于发生的情况进行评判加标签）

问题发生率参考标准可以用（发生问题的人数/总人数）*4计算，其中4是指4个等级。

（参考Jeff Rubin的 Handbook of usability testing）

Jeff Rubin 可用性评级如下：

4级：无法使用产品的某一部分

3级：难以完整使用产品的某一部分

2级：大部分情况下能够使用，但需要付出较大努力

1级：偶尔发生且容易解决，或者问题并不在产品的主要功能上

0级：我不同意这是一个可用性问题

另外可以通过其他分类方法去判断，目前的可用性评估方法超过20种，

方法不限，重点是突出收集数据的准确反馈。

1.讲述测试目的与时间

2.讲述相关的保密协议

3.测试任务须知

从现在开始将会依次让用户测试制定的所有任务，记录员全程记录（禁止发声法）用户所遇到的各种问题 

4.任务开始

开始每条测试任务的播放和表达，记录员就需要全程记录测试用户的操作找到可用性问题

5.任务完成，开始体验后感受访谈

这里注意到是，我们做完了产品的测试任务，但是还需要进行测试用户的访谈，可以让用户反馈问题，我们全盘通过录音/录像设备+表格记录下来 ，后期去分辨功能的有效性和可用性以及新增的一些潜在需求。

6.填写小份的背景调查问卷

为了让在呈现数据的时候越发更有说服力，这里会收集用户的一些背景资料，然后做一个统计来放在结果页面里。

采用的是线上形式的腾讯问卷调查方便后期随时查看

（包含性别/学历/职业/对产品的看法/是否使用过/使用的几率）

7.送上小礼品

可以准备一些礼品给测试产品的热心小伙伴，也会让用户更加积极的参与到产品进来。

测试完所有用户后，需要把记录在实体表单里的数据写入电子表格，并逐个进行优化。

我们需要将整个测试每个环节提取出来的优化方向做一个汇总。依然是按照页面自上而下的顺序进行罗列，将那些严重的问题标红作为高优先级进行处理。在redesign的时候尽量通过微调的方式去解决，而不是推翻重来。

依旧采用0-4级来判断问题严重程度 从而判定优先处理那些可用性功能

（ 下图只供参考 ）

通过反馈数据以及分析，我们得知了一些问题 如下：

最后说一下，这个测试虽然只是对产品功能的可用性进行测试，但是自身可以通过实践数据总结出其他可以预见的优化方向，如开发问题/ 运营的一些需求点等。另外设计师也可以通过这个测试延展出对于视觉和交互的可优化之处，灵活运用方法才能更好的对工作起到帮助。

Powered by Froala Editor