在B端产品的设计生命周期中，设计方案从草图到demo再到上线，每个阶段都需要接受用户的检验。然而，许多团队往往等到产品上线后才通过用户反馈发现问题，此时修改成本高昂，甚至可能错失市场机会。如何在不同阶段采用合适的验证方法，让设计验证贯穿产品全生命周期？北京兰亭妙微设计团队在长期服务B端企业客户的过程中，构建了一套涵盖草图阶段、demo阶段、上线阶段的全阶段可用性测试体系。本文从可用性测试的核心概念出发，系统解析不同阶段的设计验证方法、适用场景与执行要点，为B端产品设计验证提供完整的体系化指引。 无论是产品同学，还是设计同学，相信大家或多或少都会在需求文档、设计文档评审时被业务方、研发问到方案可行性和落地价值等方面的“灵魂拷问”，而这些疑惑同时也在拷问我们研究员。那么作为研究员，我们是如何从用户的角度去辅助产品同学和设计同学进行敏捷的方案验证呢？
首先，我们先来了解什么是产品可用性测试？
可用性（Usability），被定义为一种用来衡量界面好用程度的属性。好用程度的高低一般取决于以下五个要素：
- 可学习性（Learnability）：初次接触这个设计时，用户完成基本任务的难易程度。
- 效率（Efficiency）：用户能多快完成任务。
- 可记忆性（Memorability）：当用户一段时间没有使用产品后，是否能马上回到以前的熟练程度。
- 出错（Errors）：用户能否从错误中恢复。
- 满意度（Satisfaction）：用户对产品的主观满意度。
可用性测试主要用于验证产品的可用性，该方法能够帮助产品同学和设计同学了解在实际使用情境中该设计方案（概念或创意）的质量（评估是否可用/是否有效/用户是否满意），并在测试结果的基础上进行改进。
换句话说，可用性测试是观察有代表性的用户，让用户完成产品中的各项任务，了解用户如何使用产品，界定出可用性问题并解决这些问题，让业务、产品、设计、研发等上下游角色尽快对产品方案达成共识并积极优化产品体验。
通过可用性测试，我们可以：
- 了解用户如何与产品进行交互；
- 了解用户是否能够完成指定任务；
- 了解用户需要多久才能完成指定任务；
- 了解用户对本品和竞品的满意度；
- 明确产品存在哪些需要优化的可用性问题；
- 明确产品可用性情况及是否符合上线目标；
- 让产设研团队在开发上线前发现问题并解决。
那么，什么情况下可以做可用性测试？
在实际项目执行中，我们通常会在几个特定阶段去进行产品可用性测试，不同阶段采取的调研方式也有所不同，所关注的内容亦随之变化。
（1）设计初始阶段，我们通常会进行前期用户需求挖掘或相似产品使用情况分析，并基于需求概念设计出来的草图方案进行探索性可用性测试，来确定方案内容和功能的范围是否符合用户预期方向和使用需求，以此初步评估草图方案的有效性和可用性。因此，在该阶段，我们常以纸张原型测试+定性深访为主，先从认知上与用户保持一致，理解了用户，做出来的产品方案更能贴近用户诉求。
（2）灰度上线前，我们一般对 demo 终稿进行评估性可用性测试，向目标用户介绍新设计，同时尽可能保证 demo 稿是用户能够直观测试使用的，以此来确定 demo 在功能满足、信息布局、流程交互，甚至是视觉样式上是否能够提供良好的用户体验。所以，在该阶段我们更多会进行面对面测试+可用性测试量表（SUS 量表），一般在会议室等固定安静的环境中进行，并要求用户按既定任务测试操作，任务测试过程中不打断用户并观察记录用户在关键流程环节使用中遇到的问题，测试完成后向用户提出问题或进一步探究原因。
（3）灰度上线或全量上线后，我们通常会对上线后的新方案进行对比性可用性测试，通过灰度方式在同一时间维度下比较新方案和原方案的可用性反馈和用户满意度，确保方案在全量上线之前修复任何潜在问题。因此，在该阶段我们以 A/B 测试+场景化调研问卷（如下图所示）为主，通过用户体验数据和业务数据来评估出最优版本。
实际执行中，我们怎么做可用性测试？主要实施步骤有：
STEP1：设计任务
可用性测试的基础是任务，任务测试内容的好坏是能够对测试结果的准确性有直接影响的。因此在招募用户之前，需要对测试的产品方案进行任务设计。比如，测试商家在 B 端营销系统报名营销活动流程方案的任务可以是：报名一场双 11 大促活动。
在设计比较合适的测试任务时需要注意以下几点：
- 选择最核心的功能或操作流程作为任务。产品最核心的功能和操作流往往是最频繁被用户使用的地方，假设最常用最核心的地方还存在可用性问题，那么就算优化了其他边缘部分的可用性问题，依旧是对产品整体体验于事无补。比如在商家报名大促活动流程中，最核心的环节是查找活动→选择商品报名→跟踪报名进度，那么就需要重点将这部分作为测试任务。
- 任务应符合常规操作流程。在实际业务中，产品线的职责分工会比较细化，比如 A 产品会负责 A 模块，B 产品负责 B 模块…单一功能模块的测试任务较多的情况下，如果各任务之间操作流无法串联甚至是存在冲突的话，用户测试的操作流就是不合常规的，也容易给参与测试的用户带来困扰。因此，我们研究员需要根据用户操作习惯来进行评估测试任务并设计串联流程。
- 为任务创建一个应用场景。简单的场景描述会对用户执行任务有帮助。比如：任务是“报名一场双 11 大促活动”，我们可以创建这样一个场景：你关注的双 11 大促活动报名时间开始了，你想上商家后台去报名双 11 大促，请登录商家后台来完成大促活动报名。
- 明确任务的起点和终点。用户是否完成了任务的评估依据是：用户是否从起点（页面 A）到达了终点（页面 B）。因此要明确起点和终点的定义，哪个页面是起点？哪个是终点？比如：任务是“报名一场双 11 大促活动”，起点页面就是商家后台首页，终点页面就是提交报名素材成功的页面。另外在评估是否到达终点页面之外，还需要关注用户在任务过程中的操作动线、是否有效填答信息，若没有，我们需要搞清楚背后原因是什么。
- 任务不应过于简单。若想测试用户是否能够找到某功能，不要用类似“找到 XX 功能按钮”这类表述，我们应该给用户提供一个要处理的实际场景任务，比如不是“找到换品功能按钮”而是“报名完成后想要重新换品”。
- 避免提供线索和描述操作步骤。任务只需要给出具体目标即可，不需要给到测试用户具体的操作步骤，不然会容易错过用户在执行任务过程中到某一环节可能存在的“意外问题”，而这些“意外”恰恰是我们需要关注的。
STEP2：招募用户
在招募用户环节，最重要的是样本数量的确定。在实际的可用性测试中，我们常常被产品同学或设计同学问到：
“6 个用户提出的问题能代表全部么？”
“几个用户是不是太少了？他们提出的问题是可靠么？”
诸如此类的样本数量“挑战”，不胜枚举。人机交互博士 Jakob Nielsen 曾提出：“有 5 个人参加的用户测试，即可发现大多数（85%）的产品可用性问题。” Nielsen 这张经典图表（如下图）告诉我们答案：一般最严重的问题都是前几名用户发现的，随着用户数量增多，发现问题逐渐减少。
当然在实际执行中也会存在一些局限性，比如只能发现问题数量，但无法确定发现问题的严重程度，因此还是需要从实际情况比如测试任务的复杂程度、人力资源的投入程度等等来确定招募样本数量。
STEP3：前期准备
- 测试地点与工具准备。比如安静的会议室、电脑、录音笔、录屏软件（录制操作全程，便于后续回顾分析）等。
- 任务相关资料准备。如①数据收集表，如收集任务是否完成、完成时间、关键事件中遇到的体验问题、满意度；②访谈提纲，包含任务步骤、需要注意深挖的环节问题等。比如，任务是“报名一场双11大促活动”，访谈验证sop示例：
STEP4：试点测试
试点前测的目的是针对整个测试流程和提纲进行测试，便于前置发现流程和提纲中存在的问题，及时优化，避免造成真实测试用户的资源浪费。试点前测需要注意：
- 访谈提纲的话术表达和任务流程的设计，是否能够准确让用户理解？
- 提纲内容是否透露了操作步骤，用户是否很快完成任务？
- 时间安排是否合理，用户是否可以在规定时间内完成任务？
- 任务流程安排是否合理，用户是否感到疑惑？
STEP5：观察访谈
在观察测试中，需要检查用户任务目标和心理认知是否可以顺利执行下一步操作，以此来发现可用性问题，因此我们要对以下问题做到心中有数：
在事后访谈中，有以下几点小小访谈 tips：
- 认知习惯层面：首先了解用户对方案功能的基本理解，比如是否能够理解？理解的意思是什么？为什么会有这些理解等等，之前在这些环节中用户的操作习惯是什么样的？
- 需求关注层面：用户在这些环节关注哪些方面？然后再给用户解释每个功能方案的定位作用是什么，方案解决什么问题。同时追问用户，就目前方案是否解决实际中的问题，哪些问题？以及还有哪些优化的建议等等。尽管大多数人认为不该直接问用户产品的优化建议，用户给到的结论也只是基于自身经验的主观想法，但是若根据用户给到的答案继续深挖“为什么”，可能会知道用户真正想要达到的效果和预期是什么。
- 切记不要上来就一通讲解方案后就单纯问用户你觉得好不好，应该还要继续往下追问。因为这样通过对用户现有的行为习惯和需求关注的了解，才能够判断评估用户说的话是否逻辑自洽，才能够验证方案是否能够真正满足用户的需求，而不是伪需求。
STEP6：分析报告
一般情况下，可用性报告的内容主要包含以下三方面：
- 研究概述：测试目标、样本描述、研究方法等。
- 问题解读：问题描述、原因解读、严重程度及影响范围评估、数据结果等。
- 解决应对：建议的解决方案。
设计验证不是一次性的工作，而是贯穿产品设计全生命周期的持续过程。从草图阶段的探索性测试与定性深访，到demo阶段的面对面测试与SUS量表评估，再到上线阶段的A/B测试与场景化问卷对比——每一阶段的验证都在为产品体验的优化提供依据。北京兰亭妙微始终相信，只有让设计验证贯穿产品全生命周期，才能让设计方案真正贴合用户需求。希望本文的体系化方法能够为设计从业者提供参考，北京兰亭妙微也将继续深耕B端产品设计领域，与行业同仁共同探索设计验证的更多可能性。北京兰亭妙微，与你一起共成长！
