先行动再思考未尝不是一件好事；同时，凡事预则立。
我们进行的是手机端产品的可用性测试。
6月开始，匆匆忙忙用大约一周时间完成了从电话邀约到可用性测试访谈结果反馈。
一开始我突然被拉过去说要做可用性测试，并且脚本同事已经完成（我并不知道这个脚本准备了多久）。我要做的第一件事是电话邀约参加测试的用户。于是发现了电话单筛选的问题以及电话邀约的一些技巧。经过了预测试准备（其实并不严谨，是我以及另一位交互人做测试），之后高高兴兴得迎接辛苦招募来的测试用户，接着根据已有脚本顺理成章地完成测试过程，之后来做可用性测试分析。
我是第一次使用并参与可用性测试，在一开始对整个过程没有相关的知识储备，基本是都在跟着其他人走。测试完成后，痛心疾首，赶紧买回来《洞察用户体验》充电。现在回头看着一周的工作，还是有颇多收获。以下是反思学习，希望一起交流进步。
前期准备阶段要充分
1.测试脚本准备
1）测试功能&任务
先确定要测试哪些功能，并对这些功能进行优先级排序，可以参考重要性与满意度。之后用一句话总结团队最想知道这个功能的哪些内容。
接着设计任务，精心设计的任务应当是典型合理的，可行的。任务的语言设计要避免出现界面中已有的字眼，造成干扰。完成任务所需的时间要进行预估，避免过长。测试任务之间的顺序合理安排。
2）测试评价指标预设
完成任务的速度、他们犯了多少错误、有多少次能从错误中恢复、多少人成功完成了任务；
统计结果并不使用具体时长等，而是使用相对数值。如完成任务的速度：
0失败
1用迂回的方法缓慢完成
2稍慢完成
3很快完成
2.招募用户准备
1）筛选标准
与你的测试目的相关联，尽量缩小到符合任务目标受众的代表者 。网上资料给出的是 A是否使用过产品 B手机设备使用安卓or iOS。
每个简单测试确保最少招募到5名评估人员（有研究指出5名用户可以发现大概85%的问题，具体为什么你可以找度娘问问看，有解释），招募时招6～10名用户，以防止有用户临时来不了。
2）招募时间
这个也是看具体安排情况，如果脚本等事宜安排妥当，只剩下招募用户，那就妥妥的快点进行。值得注意的是对邀请到的用户测试时间的安排，这个提前需要有估算，防止出现用户到场后上一场测试没有完成的尴尬。
3.测试全流程提前安排周详
测试前：
测试场地（尽量还原用户使用产品的场景，且保证测试不受周围环境因素干扰）
用户接待（准备水）
测试时：
参与人员（不要过多或频繁更换，给用户造成不舒适感）
测试形式（随测随问，还是测试完成后再统一提问。这个与任务设计相关）
视频拍摄器材&角度（调试好，使用手机对用户手部操作录制视频时，避免内容录反向）
测试后：
分析需要的内容（不同测试指标对最后分析结果有什么关系）
预计输出成果（可用性测试报告的内容）
电话邀约的一些技巧
接到一份根据“近期注册且未使用过产品”的标准筛选后的电话单，简单拟定电话内容后，就开始了这场被动的“电话海选”。我们需要在电话中确定用户是否为符合要求的测试用户，对符合的用户再进行邀请。
这意味着我们电话一开始，就要询问对方一些有关财务方面的私人性问题，最后的结果是打到100个电话时，我们都还没有成功邀请到一名用户（周四周五电话邀约，测试时间为下周一至周三）。
一同参与电话邀约的同事，在致电时采用了各种挽留用户的方式，包括“参与测试的名额有限，我们特地诚意邀请您来参加”“测试时间短，我们会有XX元的答谢”等等。好在最后用这种办法成功邀请到3名用户（还有一些有意愿来参加但行程尚不确定的用户）。
这次电话邀约中，学到了不少东西。
1.同步邀约对象的状态，放慢语速，给对方反应、提问的时间。
我在一开始时，觉得邀约用户前奏过长，所以语速很快，后来发现这样更加不利于电话另一端的用户理解明白我的意思。后来，打电话过程中，在进行完自我身份介绍时，会停顿一下，给对方反应时间；接下来的询问放慢语速，保证对方能明白我的意思。
2.邀约的话术。
组织好邀约用户的语言很重要。把握沟通过程中不侵犯受邀用户的安全防卫线，并让对方不觉得不舒服，能觉得舒服或没感觉最好。同时兼顾达到获得需要信息、确定是否为目标用户的目的。最后是想办法邀请到目标用户。
3.当断则断，对于肯定了不是目标人群的人，不说废话，尽快结束电话，同时注意言辞婉转。
4.角色认识，电话的这边，我代表着公司的形象。
当电话打出去时，我不单纯是一个邀请人，我还代表着公司的形象，只是我与客服提供的服务不同。所以，当受邀用户询问不在服务范围内的问题时，我也应当尽可能提供帮助，或者帮助提供解决问题的路径。或者在找到问题解决办法的时候，再次致电用户。
5.加强自我保护，学会判断。
不与受邀用户产生工作外的联系（前提是电话目的不是联系用户），或者注意与用户保持距离。
测试过程中排除干扰
我在查看录制的用户手部操作视频发现了一些问题：
视频录制不完整或中间存在断层，即部分用户反馈没有收集完整；
手机中途有电话打进，存在干扰。
另外说明一点，在可用性测试过程中，demo可以发生小部分改变。【至于这个度，我也在学习过程中，欢迎交流】
测试后及时输出报告
我根据录制的用户手部操作视频进行测试分析与问题总结，由于可用性测试分析知之甚少，搜集到的资料也没有详细说明，所以感觉颓废。最后再《洞察用户体验》一书中，学到以下技能：
整理报告的技巧：
不要呈现完全负面的报告；
关注真实的人群；
提出建设性意见；
可用性测试报告中要包含以下信息：
项目概要：研究结果呈现
过程 的简要描述：揭开流程的神秘面纱并为报告的收件人提供有助于理解结果的重要背景
测试环境和招募标准：清楚解释招募了哪些人以及如何操作
关键发现：总结重要主题。截取引用用户的原话
评估者档案：让报告阅读者对测试者有直观的感受
最后，先行动再思考未尝不是一件好事。
同时，凡事预则立。
