公司内部没有专门的用户研究员之前，检验产品设计效果和功能测试，都是由产品经理主导进行的。包括下面所说的可用性测试，A/B测试，用户反馈，产品数据等。但是几次和产品经理一起进行的线下可用性测试时，我就发现了一些可用性测试实施不规范的问题。比如，样本选择不够，没有筛选代表性用户，问题有很强的引导性，测试原型本身有很强的误导性……当时我心理就对这种用户测试和访谈之后得出的结论，非常惶恐。
本章关于可用性测试实施的内容，非常实用~
检验设计效果的方法
正式上线前
- 可用性测试+A/B 测试
正式上线后
- 收集用户反馈+分析产品数据
设计师的问题
- 没有意识
- 有这个意识，但是并未在工作中很好的执行
可用性测试
- 可用性测试是改善产品的最佳方法。
实际问题
- 任何产品都有问题，而我们不是真正的用户，即使我们声称在为用户考虑
- 人们在讨论方案的时候，总是会说：“我觉得”“用户认为”“用户觉得”，即使我们声称为用户考虑，从用户角度出发。这些意见严格意义上都是个人的主观想法。在进行用户测试前，没有人真正知道用户在实际使用产品时会怎么样
- 交互设计师可能凭借一些经验排除掉一些缺陷较为明显掉方案，但仍然无法预测到所有到情况
进行可用性测试
简而言之，就是通过用户使用产品，从而发现产品的问题
基本流程：招募5名左右的用户。给予他们几个核心操作的任务，仔细观察具有代表性的用户对于典型任务的操作情况。记录下发现的问题，在测试完成之后，对发现的问题进行分析，并找出最严重的问题
-
Before 测试的注意事项
1.给出用户使用目标，而不是直接操作
比如，测试一个收藏文章是不是易于使用。如果把问题设计成“请找到您喜欢的文字，点击收藏按钮”，会使得任务变成考验用户的眼神好不好，是不是能发现那个收藏按钮。如果将任务改成“有一篇文章，您很喜欢，想以后再找的到它，你会怎么做？”会更加合适一些
2.选择核心的测试任务进行测试，过多的话，疲劳因素会影响测试效果
3.总体的测试任务必需复合整体的操作流程，比如，先测试登出功能，再测试登录功能就不太合适
-
选择用户
1.研究表明：测试5名左右的用户，可以发现85%的问题
2.前提是这些用户具有代表性
3.所以，小功能测试一般测试35名即可，新产品或者较大的改版，可以测试510名
-
测试中的注意事项
1.切忌引导性过强
默默的观察和记录，尽量不要提供帮助，可以适当的鼓励。比如，您再尝试一下，通过其他方法完成这个任务。也不要问一些明显是个人喜好性的问题。比如，你是不是喜欢这个按钮的颜色？这个框加大一点你会不会更容易发现？
2.操作行为永远是重点
用户会有意无意的撒谎或者给出讨好测试员的答案，但是真实的行为不会说谎。
鼓励用户使用“发声思维”，即要求在操作的时候，将进行任务时的思考，行为，感受都描述出来
3.不要忽视用户现场的反应
比如，发出“咦？”“哦”的声音。或者，眉头紧缩，挠头等行为
4.考虑使用场景
比如，测试移动端的产品，让用户在测试的大屋子里测试，就会有问题
-
问题的分析
1.如果进行了录音或者摄像，重看录音和录像也许可以发现更多问题
2.按照问题的频数，严重等级，优先级，违反可用性原则这四个维度进行整理
3.最终形成一个问题的量化表格
4.灵活的运用可用性测试
误区：说到可用性测试，很多设计师会说：“我们没有用户研究员”“比较花时间”“写报告很麻烦”“我们没有专业的设备”……
但事实上，进行可用性测试的门槛很低。不一定要产品完全开发完毕，不一定要专业的用户研究人员来做，不一定要专业的设备，也不一定要循规蹈矩的遵循标准的测试流程。而是建议在设计过程中，多次使用简易的可用性测试的方法。
“修改草稿只需要橡皮，修改实际的产品需要铁锤”。尽可能早的展开简易的可用性测试，可以及时发现问题，留出充足的时间的去解决和改进。
可以采用不同保真度的原型进行测试。但是，必需考虑到因为测试原型比较简陋，用户没有办法真正完成整个操作，测试的精准度会下降。因此，在设计初期进行可用性测试，更加偏向于发现操作流程上的问题
A/B 测试
- 这是一种定量的方法；此方法的样本量较大，比较客观，但是很难直接通过数据了解到背后的原因。一般是采用定性和定量的方法相结合的方式
- 测试前设定好衡量标准
- 对同一个用户呈现相同的页面
- 保证两个版本同时测试
- 单一变量
定性的用户反馈和定量的产品数据
- 分析和整理用户反馈，聆听用户的声音，但要保持理智
- 既定的产品数据，似乎和设计师没有什么关系。但是商业价值和用户需求的平衡的确是设计师要考虑的问题。所以这些数据也是检验设计成果的一方面
