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

这样的目的也是为了更加真实的还原使用场景，以取得更严谨科学的有效信息来赋能设计，这也是为什么大多数产品需要上前线测试的原因，就像药品诞生于实验室，上架于临床一样，例如出行、运动相关产品，如果依旧停留在写字楼里测试实验，那就是闭门造车。

文章插图
三、任务与指标定制化设计产品的本质是为用户提供服务，用户会为了达成自己的某个目标或需求而花费时间使用产品，而我们需要用户测试一系列功能来评测是否能够协助完成目标任务。
所以我们在设定不同任务的时候应该以某个用户需求或目标为导向来驱动用户使用产品功能，而不是系统的指出完成那些操作任务，那样没办法深入挖掘真实有效的信息。
所以在向用户颁布测试任务的时候，我们应该为用户建立一些任务背景，并且尽可能看起来真实可靠，容易接受和共情，甚至你可以在测试前的暖场环节，根据此次的功能作用推导一些使用场景和需求，并与用户进行简单交涉，看看那些需求很有可能发生在用户身上，并以此需求目标来调整任务的话术来驱动用户完成测试。
值得注意的是如果测试的部分比较明确，那么你的任务目标也应该尽可能的聚焦或明确下来。
好了，为了方便理解我要说人话了。

文章插图
（1）重点补充
因为在整个测试的过程中，参与测试的用户不止一个，所以在了解用户情况后，可以综合一下共同的特征再去提炼优化任务目标，以保证在多个参与者中维持评估的一致性。
并且任务目标应该尽可能的准确有效，我们是要测试新的拍摄识别功能，那我们就应该要求出来，而不是说看完书后使用APP的笔记并尝试各种功能支持，产品或功能所没有的就不要提。不保证有效性，最后也只能让用户感到困惑而已。
通常完成测试任务的过程中，会涉及到多个功能之间的交互，所以任务目标涉及的多个阶段应该贴合实际的操作顺序或流程规范，另外尽可能的避免专业术语的出现，务必考虑“适老化”一下。
（2）关于指标定制化
通常在可用性测试中，是否可用的指标被划分成了三大面：有效性、任务效率、满意度，对于这三方面我们可以继续细化成若干个二级指标用于界定产品可用性。
至于你家的产品是什么行业、什么阶段、什么用途、有何特性，应该满足哪些指标为可用，我就不深入了，相信大家心里都有数。
简言之核心就是考虑产品的特性与阶段，灵活的配置可用性的指标，这里整理了些常见的指标与说明用于参考。

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