小鱼|可用性测试你不知道的Buff( 三 )

文章插图
四、用户测试中常见的问题尽管我们有测试脚本甚至测试排练，已经尽可能的保障了可用性测试的稳定可靠，但实际上在用户测试的阶段还是会出现各种问题，用户像一个熟睡的婴儿，何时醒来何时哭泣不可预见，所以这就要求测试的主持人能够灵活变通，同时在技巧上符合可用性测试的科学严谨。
可用性测试过程中的科学严谨一方面体现在方案的合理性、测试主持的技巧上、及评估分析量化的方法上，这些大多可用性测试的文章或教程中都会提到，这里就不展开啰嗦了。
常见问题举例：
1. 他似乎在想些什么但是没有说出来？
你在想什么可以分享一下吗？
2. 用户好像卡住了或遇到bug了。
这没事儿，是我们产品设计的问题，你可以考虑跳过这一步好了。
3. 就是这个，它怎么就那啥了？表述不清。
你刚刚打算做些什么，如果是你，你准备怎么去设计？有没有一些参考。
4. 然后我要怎么做呢？
对于用户提问说明遇到了障碍，尝试反问你平时会怎么做？
5. 用户反馈了一些趋势或点子，看起来很有价值。
尝试深挖，顺着点子或趋势向用户多问一点，但是不要直接问“为什么”，可以尝试问好在哪里或者哪里不好，让问题更有头绪一点。
以上不难看出，即使有了脚本，但是用户依旧是一个变量因素，所以脚本依旧需要不断调整，也只有去调整才能更好的保障测试结果的有效性，同时主持者也需要随时准备灵活的应对各种幺蛾子。
五、创新与颠覆性设计如何测试可用性测试被很多人视为评估体验的制胜法宝，但实际上很多产品在行业中已经逐步成熟，并有大企业花费大量资源进行研究摸索，让生态系统更进一步，所以说要是你的产品没有特殊的创新或瓶颈，而是传统的功能研发，其实并不一定要花费成本去做可用性测试，直接按照行业标杆也是没问题的。
那么你的产品就是有创新或颠覆性设计怎么办？
通常这个时候就会面临一个问题，打破传统或者颠覆用户的常识。类似这种颠覆式或创新技术其实非常多，例如按键手机一下到了触屏时代、智能驾驶、语言助手的诞生、刷脸支付等，这对企业是机会也是风险，所以在进行可用性测试的时候也会有些不大一样的地方。

文章插图
我们悉知在可用性测试的三大指标中就有一项是“效率”，对此也会有一些完成任务的时间作为指标，这些指标通常是根据内部人士或专家完成任务的时间乘上2倍或者更多倍做为一个评测指标。
但是对于颠覆性的变化，我们需要给用户首次测试留出更多的时间去学习去适应，在此之后，可以让用户再进行1～2次的测试，并且比较多次任务完成的时间变化，如果时间能够大幅度缩减且完成任务，那就表示可用，而这样做也是为了保障测试的科学严谨性，以避免学习门槛对创新性的评测影响。
六、多版本Battle你需要小型可用性测试可用性测试需要招募用户进行测试，预算时间精力可谓一项都不能少，但是大多公司的窘境却是公司小资源又有限，又不给预算招募，可用性测试做不起来？内部产出版本过多，不知何去何从？别担心，小型可用性测试了解一下！
1. 什么是小型可用性测试(Small Usability Test)？
小型可用性测试就是在标准的可用性测试的基础上减少了一些流程与要求，这就像是大公司与小公司之间会有各自的研发流程一样，两者各有千秋，对应公司规模与背景对症下药。