产品工作总结：关于可用性测试的二三事.docVIP

　　产品工作总结：关于可用性测试的二三事 先行动再思考未尝不是一件好事；同时，凡事预则立。 我们进行的是端产品的可用性测试。 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.加强自我保护，学会判断。 不与受邀用户产生工作外的联系（前提是目的不是联系用户），或者注意与用户保持距离。 测试过程中排除干扰 依照预先准备好的测试环境与安