域名频道资讯站可用性测试是通过观察有代表性的用户，完成产品的典型任务，发现产品的可用性问题，达到改善产品的目的。本文将按照测试前准备、测试执行、结果整理三大模块进行展开，总结其中需要注意的地方。
一、测试准备
这部分包括资料收集、相关材料准备、用户招募等
1. 资料收集
可用性测试本质上也是一种研究类型的工作，作为研究类的工作，那么做一些前期的资料收集也是有必要的，这有助于帮助我们界定需要研究的主要问题，好比我们在写论文的过程中，需要先阅读相关的文献。
在资料的收集方式上，主要有以下几种方式：
（1）定性访谈
前期可以找一些用户，尤其是产品使用经验比较久的用户进行访谈，这个访谈可以尽量发散，不局限于某一功能和某一方面，这样能够比较全面的了解产品的相关功能信息。
（2）焦点小组
组织一次小范围的讨论，了解大家对于产品的使用情况和反馈。
（3）研究竞品
如果产品有相应的竞品，也可以进行竞品分析，对比彼此在功能上的差异性。
（4）其他包括参考相关的研究报告、相关的可用性测试案例等
在本次研究中，我们找了5名有产品使用经验（都在三年以上）的用户进行了访谈，并且也对竞品进行了研究，然后我们将得到的结果进行初步的整理归纳。前期的资料收集可以根据项目的整体进度安排时间，建议访谈一定要做，其他可选。
2. 材料准备
需要准备的材料主要包括：可用性测试脚本、任务条、相关评估量表、礼物签收表、测试的产品及版本号、相关记录（录音、录像、计时器等）工具
（1）可用性测试脚本
测试脚本是指导测试进行的工具，内容包括：基本信息、测试指导语、场景任务、任务评分题、事后访谈问题。
1）基本信息
一般包括被试的姓名、性别、产品使用经验、测试开始/结束时间、主持人、记录员等。
2）测试指导语
向被试介绍测试的目的，需要注意的事项等，测试前也可以做一个简短的访谈，了解用户对产品的使用情况，帮助用户将注意力转移到产品上，为测试做准备。
3）场景任务
根据测试的目的，选取需要测试的功能，在此基础上，将任务场景化，这样更符合用户平时的使用习惯，也避免生硬的表达，这里需要注意两点：
a. 在任务场景化的过程中，避免提及与测试功能有关的词汇，以免对用户造成暗示。
- 错误示例：请搜索联系人XXX，并给他发送消息
- 正确示例：在系统中找到联系人XXX，并告知他下午要开会
b. 任务应该涉及详细的操作，而不是笼统的描述
- 错误示例：请发送一次会议邀请
- 正确示例：请发送一次会议邀请，时间为XXXX，参会人员为XXXX，会议地点为XXXX，会议主题是XXXX
4）任务评分题
在每一次任务完成后，可以让用户对任务进行评分，注意评分要有相同的维度，否则无法进行统计。比如可以从产品功能的满意度、操作的便捷性满意度进行评分，评分可以采取5分制或者7分制。
最后统计的时候可以分别计算产品的功能满意度和操作满意度总平均分，将单一任务的平均分与总平均分进行参照对比，了解用户对功能的评价情况。
5）事后访谈
在完成每一次的操作任务后，可以对用户进行访谈，访谈的逻辑可以参考“基于过去和现状，你的期望是什么”，因此提问的方式可以参考：
- “在平时使用的过程中，您有遇到什么问题吗？您是怎么处理的？”
- “目前的功能能否满足您的使用需要，您认为还需要哪些功能？”
（2）任务条
1）将任务条裁剪成相同大小，消除挑选时外观的误差影响
测试的任务条尽量做成相同大小，进行裁剪，这样在挑选单条任务给用户进行操作时，不容易受外观不同这一误差的影响，保证能够随机挑选。鉴于大部分用研都不是专业的设计师，任务卡片可以直接在Word中插入一行表格的形式，空行保证相同，这样裁剪的时候大小就一致了。
2）任务随机进行，消除顺序效应的影响
每次测试的时候将顺序进行打乱，消除顺序效应的影响，避免前面的操作对后面产生影响。
（3）其他的材料包括评估量表（一般可以采用SUS量表进行评分）、礼物签收表等
3. 用户招募
用户招募的关键之处在于所招募的用户要具有代表性，数量一般在10名左右即可。可以根据产品后台的使用数据，了解用户的群体特征是怎样的，比如设备类型、性别比例、年龄分布等，这些即构成招募的条件，然后我们可以对招募的用户信息进行整理。
二、测试执行
这一部分是整个测试的关键环节，操作执行的好坏直接影响到整个可用性测试的结果。在操作执行中，最重要的就是观察和记录用户的行为。这里需要注意几点：
（1）在用户操作的时候尽量不要打扰用户，观察和记录疑问的地方，事后再进行访谈
比如：用户可能操作的时候出现迟疑，做思考状，事后可询问原因是什么。
（2）用户所说的固然重要，但用户所做的更加重要
不管用户如何说，坚持让他完整操作一遍任务
在测试中，我们发现，有用户认为这一任务很简单，因此只是大致向我们示意了一下，实际并没有完整的执行这个任务，当我们要求他完整执行整个任务流程时，依然发现了一些问题，因此一定要让用户执行任务操作，而不是简单示意，或者说“这个任务很简单，我知道怎么做，就不用演示了”等之类的话语。
当提问用户关于某一功能模块的问题时，可让用户边看边回答
对于很多的产品功能模块，或许我们平时已经使用较为成熟，已经习以为常，但如果是在不看着产品的情况下，我们并一定能够进行完整回忆。比如我们日常使用的微信，其聊天对话框里面的功能，我相信很少有人能够在不看着的情况下完整说出来。因此，当提问用户具体某一模块的功能相关问题时，可以提示用户边看边进行回答。
鼓励用户进行操作时进行“发声思维”
所谓“发声思维”，就是让用户边操作时，边口述自己的想法。
不仅要记录显性的回答话语，也要记录隐性的行为和表情等
用户的回答揭示了其个人的感受和体验，这是我们需要关注和记录的，但用户在操作中的行为和表现出来的情绪，也是值得关注的，更何况在某些情况下人的言语与行为存在不一致的情况。
因此在记录时，既要记录用户的言语回答，也可以括号备注用户的行为和表情中隐性的信息，这样事后看记录结果时，也能够联想起当时的场景，当然这对用研人员的观察力提出了一定的要求。
三、结果整理
1. 原始结果的整理记录
这一部分的整理记录，应尽可能详细，方便后续核对和查阅，形式可以整理如下：
2. 结果分析整理
结果分析整理可以从定量和定性结果两方面进行，定量的结果可以分析任务的完成情况、任务的满意度等，并借助可视化的图表进行展现，比如：
（1）统计任务的满意度评分情况，并与总均值进行比较，对于评分比较低的功能则需要引起注意
（2）统计任务的完成情况
任务完成一般可以分为一次完成、多次尝试完成、经提示完成、任务失败四种情况，不同的完成情况用不同的色块表示，然后统计完成率情况，整理结果可以参考如下：
（3）定性结果的整理
根据用户回答的情况，进行概括总结，归纳问题点集中表现在哪些方面，可以整理为：
功能三，操作交互体验不佳：
①长按提示功能没有整合
②滑动跳转不符合正常操作习惯
……
（4）撰写测试研究报告
将得到的结果进行凝练总结，形式上按照“总-分-总”的格式进行，内容上按照“提出问题-给予建议-后续研究”的线索进行撰写。报告要具有一定的结构性和提炼总结，做到条理清晰，有总结和挖掘，同时能够提供的意见和建议以及后续的研究进展和方向等前瞻性的内容。
本文素材来自互联网
