人们认为设计师是表面工作——设计师拿着盒子说‘它看起来好！’这不是我认为好的设计。设计可不只是看起来或者摸起来的样子，设计考虑的是用它的感觉。 ——Steve Jobs 2003年11月30日《纽约时报》

在日常的 B 端产品调研支持过程中，我们研究员经常会遇到这样的场景：

“你们帮我看看，产品方案满不满足用户需求？功能符不符合用户预期？”

“（研发问）功能上线的 ROI 是多少？用户对这类功能是否有需求？解决了用户什么问题？”

“你们多找一些用户验证一下 demo 方案行不行…”

无论是产品同学，还是设计同学，相信大家或多或少都会在需求文档、设计文档评审时被业务方、研发问到方案可行性和落地价值等方面的“灵魂拷问”，而这些疑惑同时也在拷问我们研究员。那么作为研究员，我们是如何从用户的角度去辅助产品同学和设计同学进行敏捷的方案验证呢？

首先，我们先来了解什么是产品可用性测试？

可用性（Usability），被定义为一种用来衡量界面好用程度的属性。好用程度的高低一般取决于以下五个要素：

1. 可学习性（Learnability）：初次接触这个设计时，用户完成基本任务的难易程度。
2. 效率（Efficiency）：用户能多快完成任务。
3. 可记忆性（Memorability）：当用户一段时间没有使用产品后，是否能马上回到以前的熟练程度。
4. 出错（Errors）：用户能否从错误中恢复。
5. 满意度（Satisfaction）：用户对产品的主观满意度。

可用性测试主要用于验证产品的可用性，该方法能够帮助产品同学和设计同学了解在实际使用情境中该设计方案（概念或创意）的质量（评估是否可用/是否有效/用户是否满意），并在测试结果的基础上进行改进。

换句话说，可用性测试是观察有代表性的用户，让用户完成产品中的各项任务，了解用户如何使用产品，界定出可用性问题并解决这些问题，让业务、产品、设计、研发等上下游角色尽快对产品方案达成共识并积极优化产品体验。

通过可用性测试，我们可以：

1. 了解用户如何与产品进行交互；
2. 了解用户是否能够完成指定任务；
3. 了解用户需要多久才能完成指定任务；
4. 了解用户对本品和竞品的满意度；
5. 明确产品存在哪些需要优化的可用性问题；
6. 明确产品可用性情况及是否符合上线目标；
7. 让产设研团队在开发上线前发现问题并解决。

那么，什么情况下可以做可用性测试？

在实际项目执行中，我们通常会在几个特定阶段去进行产品可用性测试，不同阶段采取的调研方式也有所不同，所关注的内容亦随之变化。

（1）设计初始阶段，我们通常会进行前期用户需求挖掘或相似产品使用情况分析，并基于需求概念设计出来的草图方案进行探索性可用性测试，来确定方案内容和功能的范围是否符合用户预期方向和使用需求，以此初步评估草图方案的有效性和可用性。因此，在该阶段，我们常以纸张原型测试+定性深访为主，先从认知上与用户保持一致，理解了用户，做出来的产品方案更能贴近用户诉求。

（2）灰度上线前，我们一般对 demo 终稿进行评估性可用性测试，向目标用户介绍新设计，同时尽可能保证 demo 稿是用户能够直观测试使用的，以此来确定 demo 在功能满足、信息布局、流程交互，甚至是视觉样式上是否能够提供良好的用户体验。所以，在该阶段我们更多会进行面对面测试+可用性测试量表（SUS 量表），一般在会议室等固定安静的环境中进行，并要求用户按既定任务测试操作，任务测试过程中不打断用户并观察记录用户在关键流程环节使用中遇到的问题，测试完成后向用户提出问题或进一步探究原因。

（3）灰度上线或全量上线后，我们通常会对上线后的新方案进行对比性可用性测试，通过灰度方式在同一时间维度下比较新方案和原方案的可用性反馈和用户满意度，确保方案在全量上线之前修复任何潜在问题。因此，在该阶段我们以 A/B 测试+场景化调研问卷（如下图所示）为主，通过用户体验数据和业务数据来评估出最优版本。

实际执行中，我们怎么做可用性测试？主要实施步骤有：

STEP1：设计任务

可用性测试的基础是任务，任务测试内容的好坏是能够对测试结果的准确性有直接影响的。因此在招募用户之前，需要对测试的产品方案进行任务设计。比如，测试商家在 B 端营销系统报名营销活动流程方案的任务可以是：报名一场双 11 大促活动。

在设计比较合适的测试任务时需要注意以下几点：

1. 选择最核心的功能或操作流程作为任务。产品最核心的功能和操作流往往是最频繁被用户使用的地方，假设最常用最核心的地方还存在可用性问题，那么就算优化了其他边缘部分的可用性问题，依旧是对产品整体体验于事无补。比如在商家报名大促活动流程中，最核心的环节是查找活动→选择商品报名→跟踪报名进度，那么就需要重点将这部分作为测试任务。
2. 任务应符合常规操作流程。在实际业务中，产品线的职责分工会比较细化，比如 A 产品会负责 A 模块，B 产品负责 B 模块…单一功能模块的测试任务较多的情况下，如果各任务之间操作流无法串联甚至是存在冲突的话，用户测试的操作流就是不合常规的，也容易给参与测试的用户带来困扰。因此，我们研究员需要根据用户操作习惯来进行评估测试任务并设计串联流程。
3. 为任务创建一个应用场景。简单的场景描述会对用户执行任务有帮助。比如：任务是“报名一场双 11 大促活动”，我们可以创建这样一个场景：你关注的双 11 大促活动报名时间开始了，你想上商家后台去报名双 11 大促，请登录商家后台来完成大促活动报名。
4. 明确任务的起点和终点。用户是否完成了任务的评估依据是：用户是否从起点（页面 A）到达了终点（页面 B）。因此要明确起点和终点的定义，哪个页面是起点？哪个是终点？比如：任务是“报名一场双 11 大促活动”，起点页面就是商家后台首页，终点页面就是提交报名素材成功的页面。另外在评估是否到达终点页面之外，还需要关注用户在任务过程中的操作动线、是否有效填答信息，若没有，我们需要搞清楚背后原因是什么。
5. 任务不应过于简单。若想测试用户是否能够找到某功能，不要用类似“找到 XX 功能按钮”这类表述，我们应该给用户提供一个要处理的实际场景任务，比如不是“找到换品功能按钮”而是“报名完成后想要重新换品”。
6. 避免提供线索和描述操作步骤。任务只需要给出具体目标即可，不需要给到测试用户具体的操作步骤，不然会容易错过用户在执行任务过程中到某一环节可能存在的“意外问题”，而这些“意外”恰恰是我们需要关注的。

STEP2：招募用户

在招募用户环节，最重要的是样本数量的确定。在实际的可用性测试中，我们常常被产品同学或设计同学问到：

“6 个用户提出的问题能代表全部么？”

“几个用户是不是太少了？他们提出的问题是可靠么？”

诸如此类的样本数量“挑战”，不胜枚举。人机交互博士 Jakob Nielsen 曾提出：“有 5 个人参加的用户测试，即可发现大多数（85%）的产品可用性问题。” Nielsen 这张经典图表（如下图）告诉我们答案：一般最严重的问题都是前几名用户发现的，随着用户数量增多，发现问题逐渐减少。

当然在实际执行中也会存在一些局限性，比如只能发现问题数量，但无法确定发现问题的严重程度，因此还是需要从实际情况比如测试任务的复杂程度、人力资源的投入程度等等来确定招募样本数量。

STEP3：前期准备

1. 测试地点与工具准备。比如安静的会议室、电脑、录音笔、录屏软件（录制操作全程，便于后续回顾分析）等。
2. 任务相关资料准备。如①数据收集表，如收集任务是否完成、完成时间、关键事件中遇到的体验问题、满意度；②访谈提纲，包含任务步骤、需要注意深挖的环节问题等。比如，任务是“报名一场双11大促活动”，访谈验证sop示例：

STEP4：试点测试

试点前测的目的是针对整个测试流程和提纲进行测试，便于前置发现流程和提纲中存在的问题，及时优化，避免造成真实测试用户的资源浪费。试点前测需要注意：

1. 访谈提纲的话术表达和任务流程的设计，是否能够准确让用户理解？
2. 提纲内容是否透露了操作步骤，用户是否很快完成任务？
3. 时间安排是否合理，用户是否可以在规定时间内完成任务？
4. 任务流程安排是否合理，用户是否感到疑惑？

STEP5：观察访谈

在观察测试中，需要检查用户任务目标和心理认知是否可以顺利执行下一步操作，以此来发现可用性问题，因此我们要对以下问题做到心中有数：

在事后访谈中，有以下几点小小访谈 tips：

1. 认知习惯层面：首先了解用户对方案功能的基本理解，比如是否能够理解？理解的意思是什么？为什么会有这些理解等等，之前在这些环节中用户的操作习惯是什么样的？
2. 需求关注层面：用户在这些环节关注哪些方面？然后再给用户解释每个功能方案的定位作用是什么，方案解决什么问题。同时追问用户，就目前方案是否解决实际中的问题，哪些问题？以及还有哪些优化的建议等等。尽管大多数人认为不该直接问用户产品的优化建议，用户给到的结论也只是基于自身经验的主观想法，但是若根据用户给到的答案继续深挖“为什么”，可能会知道用户真正想要达到的效果和预期是什么。
3. 切记不要上来就一通讲解方案后就单纯问用户你觉得好不好，应该还要继续往下追问。因为这样通过对用户现有的行为习惯和需求关注的了解，才能够判断评估用户说的话是否逻辑自洽，才能够验证方案是否能够真正满足用户的需求，而不是伪需求。

STEP6：分析报告

一般情况下，可用性报告的内容主要包含以下三方面：

1. 研究概述：测试目标、样本描述、研究方法等。
2. 问题解读：问题描述、原因解读、严重程度及影响范围评估、数据结果等。
3. 解决应对：建议的解决方案。

最后的话

好的产品设计应当满足以下特征：可用性、易用性、好用性且具有吸引力。每个特征都是为了能让产品站稳脚跟而存在的，倘若想要让产品功能最终具备这些特征属性，就离不开产品可用性测试的过程。

而且一个产品设计方案在没有经过用户验证的情况下，容易在实际上线使用后出现一些隐性风险。而前置的设计验证，在一定程度上可以辅助我们产品功能在上线前发现问题，改进设计。

以上，共勉~希望能对大家有所启发。

转载：优设

兰亭妙微（蓝蓝设计）www.lanlanwork.com 是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的大数据可视化界面设计、B端界面设计、桌面端界面设计、APP界面设计、图标定制、用户体验设计、交互设计、UI咨询、高端网站设计、平面设计，以及相关的软件开发服务，咨询电话：01063334945。