1. 前期测试准备
海外产品的目标用户是local当地的人群，即便国内用户特征也可以说明一些问题，但是要想真正了解到local市场用户的使用习惯，就必须要进行local实地的测试。山高路远，时空阻隔，每次测试的成本和难度比在国内大很多，所以做足前期的准备显得尤为重要。
前期准备包括以下几个方面：
1.1 平衡目标
通常可用性测试就只针对用户的使用体验问题，成本相对可控。而海外可用性测试的特殊性在于在于测试成本可能是倍数级的提高，所以除了做可用性测试主任务外，通常会同步安排一些辅助任务。
以本次VOOV泰国用户可用性测试为例，主要目标为根据可用性测试，验证VOOV2.0设计效果，发现关键问题，改进和优化设计。次要目标为了解泰国用户对于短视频的认知、用户使用行为、用户画像和潜在需求挖掘。
需要注意的是辅助任务并非面面俱到，时间宝贵，资源有限。所以我们一般采取的方法是聚焦主要目标，兼顾次要目标。任务不能太多，保证核心任务能够深入的完成，避免造成只是泛泛的了解各个任务。
1.2 语言问题
相比于国内而言，海外可用性测试最大的困难点在于无法直接的通过语言进行双向的沟通。在英语国家我们或许可以通过英语直接进行沟通，但对于泰国、越南等小语种国家我们面临两个最大的挑战：一方面要打破语言障碍把想法精准的传达给用户；另一方面要获得用户最真实的想法。
针对以上问题从不同干系人的角度提供3个解决方法：
测试员自身：作为测试员，即使自身英语口语能力不错，相关语料的准备也必不可少。测试过程中涉及到的相关术语要提前查找翻译好，避免因表达错误造成翻译人员或者用户误解。测试任务表一般要制作成双语版，并提前E-mail给local同事review，根据反馈及时进行修正。
翻译人员：有条件的情况下优先选择local产品设计相关同事，他们对产品的逻辑和操作流程熟悉，专业术语表达准确。如果没有产品同事也可在选择其他职位同事或者找第三方翻译人员，但前提是一定要提前做好沟通，确保任务翻译的准确传达。
测试用户：在满足其他招募条件的前提下，优先选择有英语表达能力的用户。避免因二次翻译造成的“词不达意”。（用户招募具体条件请查看下文）
1.3 用户招募
合适的用户是保证测试结果准确有效的前提，而相对国内我们对于海外用户的情况不够了解，更希望能找到典型用户进行测试，方能事半功倍。
用户招募相关注意点总结如下：
（1）通过查阅网络资料，先对当地的情况有初步的了解，划定目标用户人群范围：年龄、文化水平、职业等；
（2）出行前优先选择第三方公司帮忙招募，其次让当地的同事联系；
（3）用户类型选取：可以从用户招募的类型出发，根据具体用研目标来确定招募人群，比如：
本产品可用性测试：本产品的用户
了解某行业用户行为：行业的典型用户，但不一定是本产品的
用户挖掘用户痛点：行业相关的深度用户
另外需要特别注意的几点：
用户的多样性：性别、年龄层次、职业类型尽量均衡，避免以偏概全。
用户的表达意愿：目标用户应当是有意愿表达自己想法的的人群。
避开特殊用户：例如产品经理、设计师和相关产品的开发人员。因为这些人的思维很容易局限在专业的角度，不具有普遍性。
借助网络渠道：例如在本次调研之前我们已经完成了线上用户的问卷调研，部分用户有留下自己的联系方式，这就是一部分潜在的有意愿用户，所以首先我们先对这部分用户发出了测试邀请。
区别于线上定量的问卷调研，定性的可用性测试用户数量并非越多越好。如图Nielson研究表明，测试4人足以发现75%可用性问题。但这里的4人是完全符合招募条件的、典型的有效用户，所以考虑到结果有效性通常情况下我们会选择6-8名。如果在时间和条件允许的情况下，为了发现更多可用性问题可以适当增加被试者数量。
以本次泰国VOOV可用性测试为例，我们总共进行了9场可用性测试，每场1-3人不等，其中选择一个作为主测试反映主要问题，其他作为辅助。筛选的原则是根据用户类型和前期几分钟沟通情况进行的。
比如：三个用户中有一个对于同类产品比较熟悉，明显善于表达，就可以重点测试该用户。这样对用户进行二次筛选有利于暴露更多典型问题，提高测结果的有效性。
1.4 任务设计
由于可用性测试是特定的人、在特定的时间、特定的地点完成特定的任务，整个过程环环相扣的，很像一场演出。所以需要有一个任务设计脚本把测试的模块列出，用路径串联各个模块，然后转化成任务的形式。这样方便用户理解整个测试过程的逻辑，减少疑惑和挫败感。
任务设计是整个可用性测试最重要的部分。任务设计的质量直接决定测试结果的有效程度在任务的设计方面总结了3个原则：
（1）任务情景化：把任务融入到合理的情境中，让用户在特定的任务场景下去发现我们预先设置好的操作路径，而不是直接告知用户。
正确示例：朋友分享了VOOV上的一段视频给你，你觉得视频很酷，你想看这个作者的更多作品。
错误示例：请搜索视频水印上的ID号并进入用户主页查看作品。
（2）操作目标化：告知用户目标，而不是操作步骤。任务描述不要有引导性，达到目标的路径可能不止一个，大多数用户倾向使用的就是我们需要重点关注和优化的。
正确示例：给昵称为shawn的用户发一条信息“hello”。
错误示例：搜索框输入shawn并点击搜索，点击头像进入用户主页，找到发信息按钮点击发送消息。
（3）流程逻辑化：任务设置顺序符合产品使用流程。同一任务的操作先后顺序要复合逻辑，上一个任务和下一个任务之间要要复合使用流程。
正确示例：请用你喜欢的音乐拍摄一段慢动作效果的视频，设置话题为 “#cool” 发布。
错误示例：拍摄一段慢动作效果的视频，设置话题为 “#cool” 配上你喜欢的音乐发布。
任务数量不宜过多，6-8个为宜，整体时间控制30分钟左右。任务太多时间太长容易使用户产生疲劳感从而影响测试效果。同一操作路径上简单的测试任务可以适当进行合并，反之如果任务难度太大要进行拆分。
1.5 测试演练
为了保证任务设置在难度、逻辑顺序上的合理性，确保测试任务能顺利进行，需要进行测试演练。测试演练要避免选择业务相关人员，建议可邀请人事、秘书、翻译等同事参加。
测试过程尽量模拟真实情况，按照预设的流程和节奏进行。测试中如出现在理解上有歧义或者偏差的任务项目，要及时对任务进行修正。太复杂的任务导致流程过长的要进行适当的拆解。
2.中期测试执行
在前期做好了充足准备后就要来到local当地准备进行实地的调研，在访谈正式进行之前要提前熟悉场地，包括访谈室的位置，电源情况，座位的位置等等。
测试流程分为如下过程：
2.1 暖场亲和，避免压力
海外用户对“外国人”的陌生感加上语言障碍，可能对我们会有陌生感和心理防卫。暖场的目的是让用户了解测试的目的，畅所欲言。
在暖场过程中要传达给用户以下几点：
（1）让用户明白测试的对象不是自己，而是产品。
（2）操作没有正确答案，按照平时的使用习惯就可以。
（3）过程中会录像仅仅为了后续分析，不会泄漏隐私。
另外为了减少压力感要注意：
测试中跟用户尽量平起平坐，尽量避免站在用户身后；
参与角色比较多（包括翻译、用研人员、产品、设计等），在保证正常进度下尽量控制人数；
在访谈暖场的同时，可以让用户填写预先打印好的《用户基本信息表格》，目的是对用户有个大致的了解，形成粗略的用户画像。基本信息表格设计包含但不限于年龄、职业、兴趣爱好、生活工作状态、手机和系统型号、网络流量包情况等。Tips：提前做好双语翻译有利于效率提升。
2.2 自由操作，观察询问
在开始正式的任务之前，一般会先让用户自由操作软件3-5分钟，一方面让用户熟悉一下APP，另一方面是测试人员观察用户使用习惯的时间。
要充分利用这个时间交流产品相关的使用经验和习惯，通用的方法是“5W1H”（什么时间和谁在哪里做了什么？怎么做的？为什么这么做？），这里的一个小技巧是提前和翻译人员沟通好想问的问题，让翻译人员直接询问被试者以节省时间，调高效率。
2.3 任务脚本及时调整
在测试进行了几轮之后，有可能会发现用户对于比较宽泛的问题存在疑惑、不解。或者发现了用户之间的一些共同趋势并希望了解这种趋势。这时，我们应该及时调整脚本，增加或删减一些内容。毕竟用户尤其是海外用户的一些想法和行为适合我们预想的有一定偏差的。
定性研究是探索性的，随着测试和访谈的进行会产生一些新的想法，这时就需要对原来的脚本进行细化使得所构建的理论框架越来越清晰。最理想的情况是每做完一次可用性测试都相应的调整一次脚本，但是具体实施的话不太现实，所以建议采取每天下来一起综合做总结调整。这种方式会相对不那么累，也可以给我们带来更多信息。
2.4 尽量让用户使用“发声思维”，做到“三不”
在用户操作的同时要时刻进行观察，最好把每一步操作的原因和想法讲出来，以便我们能清楚地了解到操作的原因，挖掘背后优化的点。做到“三不”，即不打断、不引导、不影响。
通常的做法有两种：
边测边访（优点：及时了解用户当前的想法；缺点：干扰操作过程）
先测后访（优点：不干扰操作过程；缺点：用户事后会忘记为什么这么做）
在条件允许的情况下优先采用A方法，但由于海外调研的特殊性，即便翻译资源到位的情况下逐句翻译对操作过程的干扰很大，所以一般B形式进行。测试过程中不要去打扰用户，也不要给用户任何提示。
记录问题并在测试完成后和用户进行沟通，询问用户当时在这里出现障碍是遇到了什么问题，当时自己是怎么想的。另外一种情况是测试过程中用户遇到问题时主动问测试人员，可以直接回答用户：按照你想的去做。
当然有一种极端的情况是用户实在无法继续操作了，这时可以看情况决定是否结束本项任务。
2.5 完成任务体验评分，补充访谈深挖原因
通常测试完成后会有补充访谈，一般情况下是根据用户在操作中遇到的问题进行深度调研。为了避免全开放问题导致的冷场，我们增加了体验打分的形式，让用户对操作过程打分再根据分数进行讨论，进而引导到使用建议等开放性问题上面。
满意度评价表是用户根据操作过程中的感受形成的对产品主观性的评价，一般是针对性能和整体操作流畅性问题进行的梯度打分。这些分值是用户主观性的反馈，也是我们进行优化和体验度提升的重要参考。
分值不重要，重要的是要挖掘背后的原因。比如：当用户对其中某项打分过低时，我们要询问是哪个具体的流程或者细节导致打分过低。
以本次调研为例：设置了不符合、一般、符合，共3个维度分别赋值1-3，增设“没注意到”赋值为0。综合分数即为该项整体满意度。
3.后期报告输出
根据测试结果，用研人员要对报告内容进行整理和输出。可用性报告的价值在于：记录评估过程，帮助组织内部了解测试过程和内容。传达信息，并说服干系人，可用性测试报告可以有理有据的告诉干系人，我们的结论并非凭空产生，便于资源的申请。
除此之外，还可以传递评估结果，树立用户体验意识等。可用性报告的内容一般包括：对产品的描述。
1.测试目标。
2.对参与者数量和画像的描述。
3.测试时所执行的任务。
4.测试的实验设计。
5.采用的评估方法。
6.数据结果，包括图形可视化的展现。
7.对问题的描述。
8.对产生问题原因的分析。
9.对问题的严重程度和影响范围的评估。
10.建议的解决方案。
3.1 问题描述要从问题发生的情景出发，方便各个团队的阅读者理解来龙去脉
通用格式是：用户想做XX事时，发生了XX事，导致了XX问题
举例：用户想查看发现页某tag下的全部视频时，点击了tag名称但没有进入tag详情页，导致查看失败。
3.2 根据问题流程主次&最终是否完成任务来区分优先级
核心流程：使用该产品的必经流程，或重点功能所在的流程（如：短视频添加背景音乐）
非核心流程：其他流程（如：发短视频添加描述）
根据以上两个维度可以把问题分成4类严重程度：灾难、严重、中等、轻微。如下图：
需要注意的是，可用性测试得到的问题优先级排列是用研人员基于用户的测试而给出的结果，这个优先级顺序并不是产品开发的实际优先级顺序。
首先，用户对产品的认知和产品相关人员对产品的认知肯定是存在一定差异的。其次，这些问题的解决还需要考虑设计周期，开发周期，业务成本等。所以，用研应该和产品团队一起从用户的角度来理解这些问题的重要程度，再由相关人员决定实际的优先级排次序。
3.3 引用用户原话，注意正向反馈
对于测试过程中出现的一些问题，在报告中呈现时可以引用用户的原话辅助说明，这样可以增加说服力。相关干系人也不会认为这是客观事实而非测试人员主观论断。
另一方面注意的是：可用性测试可以测出产品或性能的一些问题，但是如果一份可用性测试报告通篇都是在讲问题，产品、开发或其他local相关者在情感上肯定会很难受。在可用性测试中，当用户提到产品的某个或某些优点时，我们同样需要记下来，并在事后的报告中提及，特别是一些被多次提及的优点。
这样做有两点好处：
对于报告的接收者——产品、开发或其他local相关者，心理上不会那么受挫，感受到用研的一种中立态度（优点缺点都有），会利于用研后续的合作和沟通；
引起对这些多次被提及的优点的重视，以免在后续的迭代版本中丢失。
3.4 有明确的解决建议以及规划，并翻译成多语言版本同步各国Team
如果只是提出问题还不够，要针对每一个问题提出相对应具体的优化方案。方案陈述尽量简洁明了，且说明是交互问题、视觉问题还是技术问题，如果涉及复杂流程的整体优化改进，可以附上简洁流程说明图。比如针对以上问题的优化方案是：建议把more按钮的热区扩大为tag名称整行。
之后要把报告翻译成双语版本同步到各国team。
总结
前期测试准备：
1.平衡目标，聚焦任务兼顾其他
2.联合三方干系人，共同解决语言问题
3.综合各方资源招募有效用户
4.任务设计场景化、目标化、逻辑化
5.做好预先演练，提起暴露问题
中期测试执行：
1.暖场亲和，避免“外国人”压力
2.任务脚本及时修正，
3.让用户“发声思维”，先测后访，做到“三不”
4.完成任务体验评分，补充访谈深挖原因
后期报告输出：
1.问题描述情景出发，方便理解来龙去脉
2.问题区分优先级进行开发排期
3.引用用户原话，注意正向反馈
4.明确的解决建议及规划，翻译同步各国Team
总体来说，海外可用性测试中会碰到很多细节，需要在做测试的过程中不断积累和思考，以便下次做的更完美。可用性测试没有绝对标准绝对正确的方法，重要的是选择一种方式，及时了解用户最真实的情况，研究用户最真实的想法。把这些点传达给相关方，转化到产品的设计和体验度提升上，去提升产品价值，满足深层次的使用需求。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理
