从三次可用性测试中我学到了什么

　　文章是作者在经过前后三次可用性测试后总结的一些经验，enjoy~
　　身在传统制造业外企，身边并没有像互联网公司的用户体验团队，因此担着＂用户体验设计师＂的title，常常需要肩负起各类的职责，这其中就包括用户研究。 虽然曾经在设计咨询公司有过focus group和家访的经历，但和可用性测试有很大的不同， 因此也只好摸着石头过河，一边做一边找资料一边积累经验啦。
　　本文是我在经过前后三次可用性测试后总结的一些经验，不对的地方希望大家指出啦。
　　简单介绍下三次可用性测试的基本情况：
　　第一次可用性测试——C端用户App v0.1，10个参与者；
　　第二次可用性测试——C端用户App v0.2，10个参与者；
　　第三次可用性测试——B端用户网站，5个参与者。
　　（说明：根据尼尔森的研究，5个可用性测试参与者就可以发现80%以上的问题，由于我司产品为前所未有的创新产品，因此在投入上做了一定的增加）
　　正文从招募用户、测试大纲的准备、测试现场、测试结果整理等四个方面来讲。
　　一、招募用户
　　1. 招募方式
　　由于我们的测试需要在一些特定的小区进行，我们在前期采用了在小区内张贴海报的形式来招募用户。在海报上会对活动的形式、时间地点、奖励等内容做出说明，同时附上活动群二维码，感兴趣的用户可以扫码加入微信群。
　　本以为会有很多人报名，因为测试地点就在楼下，并且有奖励，但海报招募的方式并不理想，因为很多人并不会关注海报。
　　因此我们又增加了一种招募方式——请物业帮忙在业主群里宣传，这种方式招到了很多用户，可见使用合适的招募方式是很重要的。
　　在招募时最好预留充足的时间，这样可以在招募效果不理想时及时切换招募方式。
　　2. 招募注意事项
　　招募用户时最多的问题发生在筛选用户的条件上，常规的年龄、性别等指标在这里就不再赘述了，我只列举一些大家经常忽略但极有可能发生的情况。
　　（1）考虑用户的方言问题
　　在第一次测试时由于客观原因的限制，测试的小区为北方某二线城市的一个小县城中高档小区。在微信群里招募到足够的用户后，测试当天傻了眼，10个用户里有7.8个都讲当地方言，不讲普通话，因此整个测试过程中全靠猜测才能勉强和用户沟通，产生了很大的障碍。因此在测试时最好可以电话和用户进行提前沟通，以避免方言问题。
　　（2）选择性格开朗、表达流利的用户
　　除去方言外，另一个沟通方面的障碍就是表达问题，有些用户由于害羞或不善言辞，在测试过程中会需要大量的引导。这类用户也可以在前期沟通时避免。
　　（3）拒绝不符合要求的用户时，措辞要注意
　　因为前期招募方式的不同，有的人无需注意该项，比如通过网络填写信息的方式，只要筛选出符合的参与者即可。我们采用的微信群招募的方式，需要进一步和进群的人进行沟通以了解他们的条件是否符合招募要求，这时的措辞就格外的重要。
　　在招募时，我们有一个条件是＂年龄45岁以下＂，当时有个60岁的大叔来报名，招募人员非常实在地告诉大叔年龄不符合需求，结果大叔情绪激动的说，＂周末砸了你们场子＂。
　　事后反思，对别人说需求不满足的话的确比较容易引起别人的反感，因此，可以不必那么实在，而是采用更加迂回的方式，比如：＂不好意思，我们这次招募是先到先得，下次有相同的活动我们会优先通知您。＂
　　二、测试大纲的准备
　　1. 测试大纲的内容
　　主持人首先需要对本次活动进行说明，例如目的、形式、时间等等，同时需要在开始时征得被试者对于录音录像的同意，签署NDA等。完成说明后就可以进入正式的测试环节了。
　　测试大纲基本结构
　　测试整体分为三个部分，Pretest、Test和Post-test。
　　Pretest中会涉及到被试者的基本信息，例如年龄段、相关产品使用经验等，这些内容和后面的测试环节是相关联的。如果我们发现一个人在操作上出现了问题，那么原因可能是设计的不到位，也有可能是他缺乏相关产品的使用经验，这个就是从pretest中得到的。
　　Test环节一般会根据测试的目的和内容分为几个任务，在每个任务中，参与者会根据主持人的指令完成一些操作，并对操作进行打分。例如：＂请在APP中完成登录操作＂是一个任务，主持人在参与者操作的过程中需要录像（经过允许后），记录其完成的时间、完成过程中的不寻常的操作，然后再询问被试者原因。
　　可参考如下形式：
　　Post-test时一般会问一些整体和综合性的问题，例如App整体的界面是否友好，对App的满意度，App最（不）吸引人的特征，想修改App的什么特征等等，方便得出整体的评价和打分情况。
　　2. 测试大纲注意事项
　　完成测试大纲的基本结构后，还有很多细节内容需要修改和润色，以下详细展开。
　　（1）增加发声思考练习
　　在第一次测试的过程中，我发现有些参与者想要表达但是不知道如何表达，有些参与者则比较害羞，参与者话少会导致用户反馈的质量降低。因此在第二次测试的过程中，我在Pre-test的环节中增加了发声思考的练习，测试的质量有了提升。发声思考的时候主持人可以先给参与者做个示范，然后再打开某个常用的App或网站引导参与者自己做一次尝试。
　　（2）在设计测试大纲时，要想清楚问题的目的
　　有的问题是没有答案的，或有了答案并不能做什么，这种问题就是无用的。例如：第一次测试的时候，工程师要求我在大纲中加入手机运营商的问题（移动、联通还是电信），目的是看他们是否能收到验证码短信，但是否能收到短信我们通过观察就可以看到，而不必要细分到是什么运营商，即使知道了结果也不能用于改进，这个问题就是无用的问题。
　　（3）任务划分要合适
　　对于测试环节中参与者要完成的任务，既不可太复杂，也不可太轻松。如果太复杂，参与者可能中途忘记自己要干嘛，如果太简单，结果可能是参与者直接跟着指令来操作。
　　因此，任务划分是一门艺术，对后面结果的分析非常重要。另外，若测试过程中有多个任务，那么各个任务的scope要接近，如果相差过大，比如有的任务10秒能完成，而有的任务要3分钟，很有可能造成每个任务分值悬殊的结果。
　　（4）明确是可用性测试还是市场测试
　　这个问题归根到底还是测试的目的。在测试之前，一定要了解清楚老板想要的是什么数据，是技术可靠性、是市场接受度、还是app的可用性？
　　不一样的目的需要的方法是完全不一样的，得到的结果也是完全不一样的。若几个数据老板都想要，那么就要分清楚哪个是主要数据，那么大纲就要围绕主要数据展开，穿插一些其他数据。
　　（5）事先要进行预演
　　在大纲完成后，一定一定要找不了解项目的人做真实的预演。
　　预演有几个目的：
　　校正大纲中预定的不合适的时间，起到时间控制的目的；
　　若在app使用过程中有使用场景/场地的变换，需要在大纲中做出明确标识，预演可以发现不到位的地方；
　　大纲在准备的过程中使用的是书面语言，而访谈使用的往往是口语，经过预演后，能够发现大纲在语言上可以修改润色的地方。
　　（6）采用更合适的问法
　　在设计大纲时，语言的表述是非常重要的，同一个问题采用不同的表述方式，得到的答案可能大相径庭。
　　举个例子：
　　＂您平时的主要工作是什么？＂
　　＂就是普通的文职啊＂
　　换个问法后：
　　＂您的日常工作主要会涉及到哪些？＂
　　＂管理门禁系统、巡视啊等等＂
　　所以不同的问题可能会得到完全不同的答案。在设计问题时，可以自己先预想一下会得到什么样的答案，对问题的设定是有帮助的。
　　（7）酌情增加启发性问题
　　启发性问题可以帮助我们发现真实用户的潜在需求，进一步提升产品。比如：＂您是否可以描述一下您的一个普通的工作日？您在一天的工作中会做什么？＂，发现了一些洞察点之后可以继续深挖。
　　再比如：＂平时是否会用到某软件？是否可以实际操作演示一下？＂这个问题可以帮助我们了解类似产品的使用情况，进而借鉴优秀的地方，规避有问题的地方。
　　三、测试现场
　　如果在前期经过了充分的准备，那么在测试现场不会发生大的问题，但这并不意味着万事大吉了，还有很多需要注意的地方呢。
　　（1）心中有大纲，现场就不慌
　　在真实测试之前，一定要做到对测试大纲很熟悉。大家都知道，在测试的时候需要主持人具有很强的洞察力，发现参与者不寻常的行为、语言并深入探究原因。如果主持人对测试大纲不熟悉，他就会拿出相当一部分精力，思考或寻找下一个问题是什么，这样可能会影响关键洞察的发现。
　　另外一方面，如果主持人频繁查看访谈大纲，也会给参与者留下不专业的印象，同时会使自己紧张，影响测试现场的发挥。对大纲越熟悉，就越胸有成竹，越有足够的精力发现关键洞察。
　　（2）认真体会参与者的心理，及时调整问题
　　在第三次测试时，针对的是B端网站的测试，有一个参与者是一个20多岁的年轻小姑娘，在物业做文职工作。在访谈她时，有一个问题是请她描述一个普通工作日会做哪些工作。
　　参与者起初说＂就是普通的文职＂，后来表现出了不愿意讲的情绪＂不知道怎么讲＂，最后直接说＂过吧＂。测试后整理时，我发现是我在现场没有及时发现参与者的情绪，反思后，猜测可能是她自身不满意年轻却安逸的工作现状，所以不愿意说出自己寥寥无几的工作内容。如果能及时体会到参与者的心理并调整问题，就会化解参与者的尴尬，调整氛围。
　　（3）维持好现场秩序
　　如果测试是在会议室等地进行，现场不需要太多的维持秩序工作。由于我们产品的特殊性，测试只能在小区进行，因此在测试时会有很多好奇的人前来询问和观察，这会大大影响参与者的发挥。因此，现场的秩序维持工作是非常重要的。
　　（4）提前和参与者double-check以防出现意外
　　请务必提前多次和参与者确认他是否能准时参加，如果不行，及时增加替补。
　　（5）保留多个录音备份
　　这个点很重要了，第一次测试时我们的录音笔发生了故障，导致丢失了多个录音文件，只好根据大纲笔录回忆用户说了什么。
　　四、测试结果整理
　　测试完成之后还有一个重要的部分，就是测试结果的整理。
　　（1）提前设计数据整理表格
　　这三次可用性测试之后，体会很深的一点是：不同的人需要的是不同的数据。例如：对于我们用户体验设计师来说，希望得到的是可用性数据；对于技术人员来说，希望得到的是技术可行性数据；对于市场人员来说，希望得到的是市场数据……
　　测试可以采集到的各种数据可以说非常的多，而我们要做到抓取不同的数据给不同的人。因此，提前设计数据整理表格非常的重要且必要，它可以帮助我们理清思维，明确测试要的是什么，也可以反过来完善大纲内容，避免遗漏必要的问题。此处的表格应尽量详细，做完后提前和相关人士进行沟通是否全面。
　　（2）做好表格中的分类项
　　统计数据时，我们使用的是excel，在excel的表格中做好分类项对我们非常的有用。例如：对于每一个用户体验相关的问题，可以把它分类到某个任务或产品模块，对于出现的bug，可以把它的操作系统是iOS或是安卓进行分类，这样分类后，可以在后期轻松的从更高的角度看到每个模块（操作系统）出现问题的多少，进而明确后期优化的重点。
　　（3）原始数据原样记录
　　在进行数据整理之前，我的习惯是先把原始数据完整记录下来，比如：半个小时的录音，就把主持人和参与者说了什么完整的写下来。这个过程切记不要翻译，原话是什么就写什么。虽然这个工作繁琐且没有什么技术含量，但可以大大提高后面数据整理时的工作效率，忘记时也可以回过头来查看。
　　以上就是我在三次可用性测试中得到的一些体会，大部分是比较零碎细小的点，欢迎大家补充。但我的收获绝不仅仅是学会了如何做可用性测试，而是掌握了用可用性测试的思维来反思自己设计的方法，能够站在一个新手的角度考虑设计，例如在我准备测试大纲的过程中，就提前发现了app在新手引导部分的不足。
　　最后，多实践才能做好可用性测试和访谈，也希望大家在设计时，能够脑补下可用性测试的过程，来发现自己设计中的改进点。