用户体验设计中的可用性测试-理论实践篇

一前言
在产品设计最初“以技术为中心”的时代，需求主要以功能为主，更新迭代也往往是功能的堆叠，测试是质量保障的最后把关程序。随着互联网的发展，产品设计逐步转向“以用户为中心”的设计，需求上越来越注重用户体验，可用性测试作为完整用户体验设计流程之一，对设计方案进行评估，其作用同测试一样，对产品整体的质量进行保驾护航。本文首先大致介绍可用性测试，接着笔者以工作中一个B端产品的可用性测试实践作为案例，分享一下产品用户体验设计中的可用性测试方法。

二、可用性测试的定义
可用性测试（Usability Testing）是用户体验研究中常用的一种方法，侧重于观察用户使用产品的行为过程，关注用户与产品的交互，发现产品中存在的效率与满意度相关问题的方法。它是更偏重于行为观察的研究。
通俗地理解，可用性测试与测试一样是为保障产品质量的，但区别于我们所知的“测试”，可用性测试，是邀请产品的典型代表用户来对原型或成品进行典型任务操作，测试者是用户本身，产品设计方仅作为任务设计者与旁观者，观察记录用户的言行表情、遇到的问题等，发现其中可用性方面的问题，从而进行设计优化。
人机交互专家 Jakob Nielsen 将可用性框架的定义为,如图：

·可学习性：初次接触这个设计时，用户完成基本任务的难易程度？

·效率：用户了解了设计之后，能多快地完成任务？

·可记忆性：当用户一段时间没有使用产品后，是否能轻松地恢复到之前的熟练程度？

·错误：用户犯了多少错误，错误严重程度如何？用户能否从错误中轻易地复原？

·满意度：用户对产品的主观满意度如何？

三、可用性测试的介入点
可用性测试在原型阶段、产品发布前或发布后都可以进行。通常来说，在开发投入前，也就是原型阶段，是最佳的介入点，可以避免很多无效的开发，节约成本。在产品发布前使用，可以在产品推出前修复潜在的问题，保障上线后留住新用户；对已发布的产品进行可用性测试，可以对产品进行用户体验优化，以更好地服务用户。当然，可用性测试越早介入越好。
B端产品的可用性测试，受业务复杂性、用户专业性强等因素限制，在原型阶段很难获取大的成果，因此我们的可用性测试放在了产品发布前。但在原型阶段，我们会通过会议形式进行设计方案同步、沟通、评估、调整，以尽可能减少开发的返工。
Tips：可用性测试在原型产出后的任何阶段都可以做，有什么样的资源就做到什么样的程度。越早越好！

四、可用性测试的意义
1、减少开发返工，提升开发效率。产品在生命周期内，是不断迭代更新的过程。可用性测试越早介入，就越能在前期发现问题，优化方案，从而使得方案更为接近用户的心理模型，减少开发中的返工现象，提升开发效率。
2、提升用户工作效率。可用性测试的目的就在于通过观察代表性用户的操作行为、情感表现，挖掘产品在可用性方面的问题。一切都是为了让产品更符合用户预期，减少用户思考的时间，从而提升工作效率。
3、减少客户服务工作量。正如大家所知，B端的产品因为业务专业性、复杂性，生产方一般都会准备一份厚厚的用户操作手册，并且在售前售后都有一个专业团队，持续进行客户服务支持。通过可用性测试，产品在可学习性、可记忆性方面获得改善后，可使用户更快地学习使用产品，记住如何使用，从而减轻客户服务压力。
4、获取更多场景化信息。可用性测试中提倡的发声思维及访谈，能帮助测试人员获取更多真实的场景化信息，如用户在什么样的情况，采用什么方法，解决什么问题。通过与用户沟通，有助于产品人员挖掘新的需求或得到解决问题的思路，为后续产品更新迭代，版本规划提供依据。
五、可用性测试的流程
可用性测试标准流程包括五个步骤：

1、资源准备
准备好测试所需的资源。

专业的可用性测试资源包括测试人员、测试环境（如办公室、观察间、网络）、测试工具（如测试手机、电脑等设备、麦克风、录屏软件、屏幕共享软件、摄像机、眼动仪等）。测试的人员需要对产品业务有较深的理解，能够随时知道用户说的是什么，并及时回答用户的疑问。
我们本次实践的测试人员，除了UED成员，还有PM、测试甚至客服的参与，大家站在各自专业角度，能挖掘更多潜在问题，同时能更顺畅地与用户进行沟通，解答用户提问；测试设备为1920×1080分辨率的显示器；测试记录除了纸笔，主要为手机录像。
2、任务设计
可用性测试的任务设计要以用户目标为导向，设计典型场景下的典型任务。

所谓典型，即是最重要、最常用、最耗时的那些场景任务。如果能在这些场景中帮助用户提升工作效率，带来良好用户体验的话，那么产品的整体满意度将会有一个很大的提升。
任务设计前，首先需要明确典型场景有哪些？其次需要明确这些场景中又有哪些典型任务？任务编写时需要注意：一、要站在真实的用户场景来描述，否则就会变成随便点点，不知所谓。二、任务描述中要避免采用直接“指导操作式”的语言，否则就会按照设计师的意志走，达不到测试效果。
在任务设计阶段，需要根据实际业务场景，明确任务范围编写典型的测试任务。我们最后设计了9个任务。测试人员模拟投资者，按照实际交互前置场景，填写好申请单，并输送到测试环境。正式测试时，用户打开电脑进入首页，就可以开始一天的工作了，如图3。

3、用户招募
明确目标用户定义，招募典型代表人物。根据研究显示，可用性测试中，5个用户能发现85%的问题，一场6-8人的可用性测试可以发现90%左右的问题，如图4。

图4：可用性测试的用户数量（图片来自互联网）
招募对象的选择，首选是产品的典型目标用户，也就是真实的用户；被招募的用户应具备使用产品执行任务的能力；在实际招募过程中，会遇到各种原因的困难，那么可以考虑邀请产品其他相关方参与，比如对业务有所了解的测试人员、PM等。
B端产品可用性测试中的用户招募是我们认为相对困难的。产品具有非常强的业务特点，最终服务于特定的人群，这类人群无疑是最佳的招募对象。普通的非专业用户操作起来难免一头雾水，而若将任务设计得过于精细又不利于发现真实存在的问题。所幸，我们本次的可用性测试，邀请到了真实的客户操作人员。

Tips：灵活进行可用性测试，时间紧急的话，哪怕只有一个测试用户，也能发现大约30%的问题哦！
4、执行测试
指导并观察用户完成任务，做好测试记录。该环节主要就是让用户完成预先设计好的一系列任务，测试人员需要对用户的行为进行观察、记录、访谈。测试正式操作前，向用户简短介绍本次测试任务，请用户尽量“发声思维”，即一边操作一遍表达所有内心活动，告知用户会录像，用户隐私将受保护；测试过程中应避免过强的引导，需要更多关注“用户行为”，可通过视频拍摄对用户测试过程中说的相关语言和任务完成过程做视听记录，在过程中或任务结束时与客户探讨需要深入了解的问题；测试任务结束后，对用户的测试感受进行详细的询问与沟通，并做记录，并询问用户针对系统整体的评价，获得整体满意度。

图：可用性测试视听记录资料

5、测试报告
将问题进行归类，分析原因，给出设计方案，落地跟进。产品可用性测试结束后，我们通过对视听资料的回放观察、分析，记录，得到本次可用性测试的任务完成率，以及当前方案存在的问题。这些问题分布于各个任务中，需要将这些问题进行归类，并根据问题所涉及的任务的重要性、用户操作频度以及产生的后果严重程度，对问题进行优先级分类，并设计优化方案。
一切没有落地的可用性测试都是形式主义。我们在对可用性测试中挖掘的问题进行归类，优先级确定，优化方案设计评估后，将这些问题都以缺陷或需求的形式录入到jira缺陷系统中，责任落实到各个小组，以最后缺陷或需求完成修复或实现为终点，实现闭环，如下图：

六、总结
可用性测试可以专业到使用精细的测试仪器和设备，也可以简化到使用一个手机进行。对测试人员具有较高的专业性要求，以设计更为典型的任务、招募更为典型的用户、分析获得更为根源性的问题，从而获取真实的效果，给出切实有效的优化方案。在真正的可用性测试中，会碰到很多的细节，需要不断积累和思考，以便下次做的更完美。资源有限的条件下，也建议大家邀请设计师、产品经理、开发、测试等人员，来一场简单快速的可用性测试，一起为产品质量保驾护航。