在产品的日常工作中有一块是在对接用研，在工作中对可用性测试、A/B测试、主观体验的一些想法零零散散记录在印象笔记里，这次稍微整理下对可用性测试的零散记录，算是给自己做个阶段性的备份。
可用性测试是什么
就个人理解，可用性测试就是把最小成本制作出来的原型，给目标用户在模拟的真实场景中去完成测试任务，然后通过观察发现目标用户在使用场景中遇到的问题，或者验证预期的假设问题。
可用性测试的优点
可用性测试操作便捷、成本低，不用进入产品的开发测试阶段，通过简单的原型就可以验证产品设计。如果产品都开发成型，那明显是灰度上线、A/B测试、数据分析等方法更符合要求。（摔~~~(╯°Д°)╯︵ ┻━┻ 这特么明明是所有用研方法的优点嘛！）
什么时候用可用性测试
可用性测试一定是在产品功能上线前所用的测试方法，一般而言可用性测试主要应用在以下三种情况中：
- 某功能设计之前没有经验，交互与产品都拿不准，并且也没有现成的相似产品做参考，不清楚真实使用中会有什么深坑；
- 功能的几种设计方案均有明显的弊端，无法评判哪种更优；
- 团队出现歧义，用所谓客观的测试结果说服团队成员接受该设计；
前两点是可用性测试的主力场景，如果设计囿于前两种情况，那还有什么可犹豫的？
第三点看起来明显是最扯淡的，但在很多团队中却恰恰是出现最多的。现在可用性测试越来越被重视，也可以说是越来越被滥用。就是因为可用性测试、A/B 测试、数据分析……这类所谓客观的方法论是最好的说服工具，团队成员更愿意相信这些，而不是某个人的言辞。
而在我看来，产品及交互最重要的价值体现就是利用自己的经验去做需求及设计方案的决断。所以在个人对这个设计权衡利弊考虑的非常清楚的时候，一定要主动应战，PK掉这些来自团队的质疑。个人的说服能力与在团队的影响力本身就是很重要的一项能力，有这种机会一定要通过言辞的解释让大家信服。
若团队中有成员勉强接受你的设计，在上线后一定要将该设计的数据表现及时同步给大家，无论你的设计是否达到最初的预期，这都是对彼此的尊重，后续的协作会得到更多的信任。
可用性测试注意事项
1. 测试任务的目标唯一性
每次可用性测试任务确保有且只有一个目标，千万不能因为甲测试任务流程中可以再顺带添加乙任务，而在设计甲任务的时候把乙任务参杂在中。如果二者均有需要，一定要拆分成两个任务去测试，而不要期望一个任务流程去达成两个目标。
因为就经验而言，如果测试任务的目标不唯一，经常会受到其他因素的干扰而影响到测试的结果。并且对于测试人员来说，记录掌握用户的反馈也不方便。
2. 测试任务的描述要委婉
测试任务的描述尽量婉转、场景化，也就是要让用户对你的任务描述有自己大脑的转意过程，而不是依照字面所述去机械操作。
比如测试输入法的颜文字表情自定义功能，测试任务描述不能描述成“复制对话框的颜文字表情，找到颜文字自定义按钮进行粘贴添加”，而是应该尽量描述成“和闺密聊天，她发来一个萌死的颜文字，你非常非常喜欢，但是发现你的输入法中还没有这个颜文字，你该如何添加到你的输入法颜文字表情中呢？”
3. 用户及场地的选择
用户选择上贵在精而不在于多。情愿找少量的真正目标用户，而不必追求用户数量。如果仅仅只是追求数量，反而给测试带来大量不真实的信息，影响最后的结论输出。
而测试场地的选择一定要与产品使用的真实场景相同，比如测试输入法的单手模式功能，一定不能仅仅是在办公室里强迫自己单手使用大屏手机进行测试，而是需要进到真实场景中，比如：站在拥挤的公交车上，一手扶着把手，一手拿着手机完成测试任务。
4. 注意测试中的沟通细节
用户在进行测试的过程中，一定会和测试人员进行沟通。在测试开始前，测试人员可以与测试者闲扯，调和下测试气氛，便于测试者卸下防御机制，更利于其进入真实使用状态。
而在测试过程中，测试人员应该尽量扮演NPC的角色，按部就班推进测试过程，默默的在旁边观察、记录用户的使用细节，少谈论一些引导性的偏好问题。
比如诸如此类的言辞“你为什么不点击这个按钮，是因为颜色不显眼吗？”、“如果这个功能入口放在前面，你是不是就容易找到了”……在测试过程中是一定不要出现的。如果有必要问，一定要在测试任务完成后，一并向用户咨询或者通过事先准备的问卷去了解。
同时用户在任务测试过程中，若遇到了操作困难，可以多安慰鼓励用户，而不要直接给予用户指向性的引导。这些举动会干扰到测试的真实结果。
5. 多注意用户的操作反馈
在测试过程中，多注意留意用户真实的操作反馈，而不是听用户在说什么。由于用户心理保护机制作祟，造成他说的话是不可靠的。而他的操作行为与操作时的下意识反馈，是无法掩饰作假的。在测试过程中主要就是观察用户的操作反馈，而不要被他言语所迷惑。
如果有条件，测试的整个过程可以进行多机位的视频录制。比如手机端的app测试就可以有两个机位，一个机位记录用户手部操作屏幕，一个机位记录用户正面的肢体及表情反馈，这样更便于后期分析。
6. 不要拘于形式
可用性测试没必要每次都那么正式，拘于形式流程。有时候在没有指定目标用户时候，顺手拿竞品与自身产品某一项设计上有差别的小功能，在公交上问下邻座哥们、在聚会上问下朋友，这样也可以达到测试目的。
可用性测试的形式是灵活的，而结果的导向性也是明确的。无非也就是让产品与交互人员不要纠结于自己固有的思维圈子中，更多的要关注真实用户的使用反馈。
所以经常经过可用性测试发现团队成员纠结来纠结去的地方，真实用户是根本不在意，或者根本没留意到。这算不算是种讽刺，23333333
