一开始我突然被拉过去说要做可用性测试，并且脚本同事已经完成（我并不知道这个脚本准备了多久）。我要做的第一件事是电话邀约参加测试的用户。于是发现了电话单筛选的问题以及电话邀约的一些技巧。经过了预测试准备（其实并不严谨，是我以及另一位交互人做测试），之后高高兴兴得迎接辛苦招募来的测试用户，接着根据已有脚本顺理成章地完成测试过程，之后来做可用性测试分析。
我是第一次使用并参与可用性测试，在一开始对整个过程没有相关的知识储备，基本是都在跟着其他人走。测试完成后，疾首，赶紧买回来《洞察用户体验》充电。现在回头看着一周的工作，还是有颇多收获。以下是反思学习，希望一起交流进步。
先确定要测试哪些功能，并对这些功能进行优先级排序，可以参考重要性与满意度。之后用一句话总结团队最想知道这个功能的哪些内容。
接着设计任务，精心设计的任务应当是典型合理的，可行的。任务的语言设计要避免出现界面中已有的字眼，造成干扰。完成任务所需的时间要进行预估，避免过长。测试任务之间的顺序合理安排。
与你的测试目的相关联，尽量缩小到符合任务目标受众的代表者 。网上资料给出的是 A是否使用过产品 B手机设备使用or iOS。
每个简单测试确保最少招募到5名评估人员（有研究指出5名用户可以发现大概85%的问题，具体为什么你可以找度娘问问看，有解释），招募时招6～10名用户，以防止有用户临时来不了。
这个也是看具体安排情况，如果脚本等事宜安排妥当，只剩下招募用户，那就妥妥的快点进行。值得注意的是对邀请到的用户测试时间的安排，这个提前需要有估算，防止出现用户到场后上一场测试没有完成的尴尬。
接到一份根据“近期注册且未使用过产品”的标准筛选后的电话单，简单拟定电话内容后，就开始了这场被动的“电话海选”。我们需要在电话中确定用户是否为符合要求的测试用户，对符合的用户再进行邀请。
这意味着我们电话一开始，就要询问对方一些有关财务方面的私人性问题，最后的结果是打到100个电话时，我们都还没有成功邀请到一名用户（周四周五电话邀约，测试时间为下周一至周三）。
一同参与电话邀约的同事，在致电时采用了各种挽留用户的方式，包括“参与测试的名额有限，我们特地诚意邀请您来参加”“测试时间短，我们会有元的答谢”等等。好在最后用这种办法成功邀请到3名用户（还有一些有意愿来参加但行程尚不确定的用户）。
我在一开始时，觉得邀约用户前奏过长，所以语速很快，后来发现这样更加不利于电话另一端的用户理解明白我的意思。后来，打电话过程中，在进行完身份介绍时，会停顿一下，给对方反应时间；接下来的询问放慢语速，对方能明白我的意思。
组织好邀约用户的语言很重要。把握沟通过程中不受邀用户的安全防卫线，并让对方不觉得不舒服，能觉得舒服或没感觉最好。同时兼顾达到获得需要信息、确定是否为目标用户的目的。最后是想办法邀请到目标用户。
当电话打出去时，我不单纯是一个邀请人，我还代表着公司的形象，只是我与客服提供的服务不同。所以，当受邀用户询问不在服务范围内的问题时，我也应当尽可能提供帮助，或者帮助提供解决问题的径。或者在找到问题解决办法的时候，再次致电用户。
另外说明一点，在可用性测试过程中，demo可以发生小部分改变。【至于这个度，我也在学习过程中，欢迎交流】
我根据的用户手部操作视频进行测试分析与问题总结，由于可用性测试分析知之甚少，搜集到的资料也没有详细说明，所以感觉颓废。最后再《洞察用户体验》一书中，学到以下技能：
推荐：