时隔一年，重新做了一次可用性测试，也重新审视测试的整个过程，觉得有些问题还是要重新明确阿一。

1. 任务设置应该具体一下吗?

可用性测试是让一群有代表性的用户尝试对产品进行典型操作，所以任务要满足场景化和路径化两个条件，要不用户不理解任务，或感到迷茫，会产生时间耗费;

场景化：比如“最近玄幻类的书很火，你也想看一下有没有自己喜欢的作品，想在这个网站上找一下，请操作”。实验室环境无法真实再现用户真实使用场景，所以要创建用户常遇到的场景，让用户能更加好的理解任务，联想平常遇到这样的情况会怎么办，这样才能呈现用户特定场景下的行为，不是为了任务而任务;

路径化： 设定任务之前要想清楚任务的关注点是什么，怎样能让用户尽可能自然的使用这个功能，而不是“请你找一本书”这样的模糊路径，因为用户会随便找一本书，而不会用到你希望考察的功能。

　2. 针对单个任务的满意度评分应该什么时候评呢?

这个跟同事也产生了一些争议。同事认为应该访谈之后，让用户明白的知道网站的问题，明确自己遇到的问题，才能客观的打出满意度发分数。

个人认为满意度应该在任务做完以后就评，这才是用户自己认为的满意程度。如果等访谈完成，用户会在主持人的提问下意识到一些自己之前没有注意到的困难，影响到自己真实的满意度打分。

用户遇到的问题在研究人员中可能会很大，但是在用户眼中或许并不能称之为问题，应该客观的测量用户自身需求被满足的程度。

从另一个方面讲，用户打完分以后会顺便问一下为什么打这个分数，问题是什么，这个流程也会更加合理一些。

　强化测试用户的身份意识

被试有身份识别的时候，为了防止用户在测试过程中混淆自己的深度，要在测试过程中不断强化。比如测试某网站时，被试可能同时会有读者和作者两种身份，有些用户在访谈中会不知不觉的忘掉自己作者的身份，会说你们网站的内容可以吸引人一点，等等，这样得到的意见并不是作为一个作者的真实意见，所以在访谈中要不断的说“你作为一个作者，会。。。”引导用户使用正确的身份。

　追问

用户觉得有问题的地方要问清楚为什么，比如有用户表示“这个页面上的信息有点多，只要显示作品的上传的时间以及浏览量就可以了”，当时习惯性的问了一个为什么这样觉得，他说读者不需要知道那么多信息啊。啊!原来她以为这个页面上是读者也可以看到的~~~。其实这个页面是只有作者自己才能看到的，所以被试不清楚机制，就会觉得有问题等理解性的错误。

继续追问才发现原来她是想要一个类似个人主页的功能，希望能显示自己作品的列表等信息，以及更新的状态就ok。

　5. 测试前要记得评估哦

测试研究人员在测试之前一定要进行认知走查，了解产品的功能、后台机制和流程等、遇到的问题，这样在测试的时候才会心中有数;

　6.不需要让用户知道是什么，为什么?

测试中用户会经常问“这个是不是需要审核的啊”“这个是不是这样啊”，这个时候只要问一下“你是怎么认为的呢”只要能了解用户的想法就可以，不用告诉用户我们的产品是这样这样的。

　7.不要希望用户来帮你设计

测试用可以问用户的意见和想法，但是不要把优化的远不希望都寄托在用户的意见身上，因为用户的修改意见也很不靠谱。比如有用户说我希望星级评分不用登录，但是从产品的角度上说，不登录的话重复投票怎么办呢?会产生更多的问题。所以不用太指望用户建议。

8. 有些问题用户没有遇到怎么办呢?

有些用户没有遇到我们所认为的重要问题，在后面的访谈中问一下用户的看法就好，不要让用户在测试任务中一定要操作。

　　9. 测试中记录人员不要发问

如果条件允许，记录人员应该在观察室，尽量不要在实验室中，避免给用户不必要的压力。记录人员在测试中不要发问，一般是在测试结束后，可以补充一些发现的问题，问一下用户的想法之类。