一、web团队讨论可用性是在浪费时间
1、在确定优先级时，不同职位的人对于产品有着不同的意见，他们相信“大部分web用户和我们一样”以及“相信大部分web用户是弹性的，可以随意变换”。他们的冲突常常会转化为寻找某种可用性测试的方式，来确定用户喜欢或不喜欢什么——找出所谓的普通用户。
2、所有web用户都是不一样的，所有的web使用都是不一样的，没有所谓的“普通用户”。
3、对于大部分web设计问题来说，没有简单的“正确答案”，良好的、一体化的设计能满足需要，也就是说，经过仔细考虑、实现和测试的设计就是好的。
4、不要问“大部分人喜欢下拉框吗”这样的问题，正确的问题是“在这个页面，这样的上下文中，这个下拉框以及下拉项目和措辞会让可能使用这个网站的人产生良好的体验吗”。而且，只有一种方法来回答这个问题：测试。创建一个版本，仔细观察人们对它的看法和使用的方法。
二、焦点小组不是可用性测试
1、焦点小组研究是一组人（一般是5-8人）围坐在桌子旁边，对展示给他们的想法和设计做出反应；而可用性测试是一次向一个用户展示一些内容（网站、原型或草图），并要求用户说出这是什么，并试着用它来完成一项典型的任务。
2、焦点小组在抽象地确定你的目标受众想要什么、需要什么、喜欢什么的时候会很有用；也可以测试出网站的理念是否有意义，价值主张是否吸引人；也可以测试你的网站功能命名、用户对竞争对手的看法等。
3、可用性测试能告诉你人们是否确实能使用你的网站，用来了解网站的运行情况，以及怎么改进网站。
4、你能从焦点小组了解到的一般都是你在设计网站之前就应该了解的。
三、关于测试的几个事实
1、如果想建立一个优秀的网站，一定要测试。
2、测试一个用户，比不做测试好一倍。
3、在项目中，早点测试一位用户好过最后测试50位用户。
4、人们对招募用户代表的重要性估计过高：更重要的是尽早和经常进行测试。
5、测试的关键不是要证明或者反驳什么，而是了解你的判断力：测试是为你提供做出用A代替B的判断的参考，本身做不到证明A比B好，因为受控条件无法达到。
6、测试是一个迭代的过程：并非做一次就可以了，而是要遵循开发—测试—修复—再度测试的过程。
7、没有什么比现场用户的反应更重要。
四、跳楼大减价的简易可用性测试
1、可用性测试：如果你想知道网站是否容易使用，在一些人试图使用的时候观察他们，记下他们在哪里遇到问题，然后修改这些问题，之后再度测试。可用性测试不需要大费周章，可以很简单。
2、每一轮测试最理想的用户数量应该是三个，最多四个。前三个用户很可能会遇到所有最明显的问题，只测试三个用户有助于保证很快进入下一轮测试。
3、宽松招募，曲线上升：测试对象是谁并不重要，利用你能寻找到的任何人（满足最低要求：会上网），然后曲线上升。不过也有一些例外，比如网站只针对女性用户，那么需要招募女性测试者；目标用户群体分为几个明显的阵营，则每个阵营至少选一个用户；使用网站需要专门领域的知识，至少需要招募一位具有该领域知识的用户。
4、招募时需注意：提供合理的激励；邀请要简单（简单描述我们的目的、你需要做什么、你将得到什么）；避免对网站（或网站背后的组织结构）进行预先讨论；别不好意思请朋友和邻居帮忙。
5、测试地点：在办公室进行简单测试即可，可以使用摄像机录制过程，也可以使用屏幕录像软件。
6、引导人员：引导人员的工作是鼓励测试用户去尝试，有耐心、冷静、有同理心、善于倾听、天生公正即可。
7、观察人员：鼓励任何相关的人对测试进行观察，尤其是管理层。
8、测试什么：关键是要在web开发的各个阶段及早进行测试，还有经常测试。甚至在你开始设计网站之前，就应该测试一下同类网站， 可以是竞争对手，或者和你脑海中的网站组织方式和功能上风格类似的网站。
9、怎么测试：可以进行两类测试：“理解”测试和关键人物测试。理解测试是让用户看到这个网站，看他们能否理解这个网站（目标、价值主张、组织方式、运行方法等）；关键任务测试是让用户完成一些任务，观察他们是怎么做的。
10、在平时设计一个新页面的时候，就可以让其他人帮你看看，这种非正式测试的效率很高，也能减少很多潜在的问题。
五、回顾测试结果
1、在每轮测试之后，应该尽快让开发团队回顾每个人的观察，决定接下来该如何处理。
2、建议在一个上午进行3-4次测试，然后在午餐时间进行简短的总结。
3、在总结会上，需要先对问题进行分类，回顾大家看到的问题，决定哪些问题需要修正；然后解决问题，找出修正这些问题的方法。
六、常见问题
1、用户不清楚概念。他们不知道页面说的是什么，或者他们以为自己知道，实际上理解有误。
2、用户找不到自己要找的字眼。这意味着你用来组织内容的分类不符合用户的习惯，或者符合习惯但是没有使用他们期望的名字。
3、内容太多了。有时候用户要找的内容就在页面上，但是他们就是看不到。在这种情况下，你需要减少页面上的整体干扰，或者把他们需要看到的内容从可视层次结构中更加突出。
七、决定修正/不修正什么问题
1、忽略“Kayak”（皮划艇）问题：用户暂时出现错误，然后又在不需要人任何帮助的情况下回到了正常的轨道，这就像皮划艇翻船时一样，只要皮划艇及时恢复正常，就只是一种乐趣而已。只要出问题的人马上意识到自己偏离了原来的主题；他们尽量回到原来的方向而不需要帮助；这种情况看起来没有扰乱他们的活动，那可以忽略这种问题。当然，如果有简单又明显的修复办法的话，修复也无妨。
2、抵制添加的冲动：当在测试时清楚看到人们没有理解某些内容时，大部分人的第一反应是增加一些内容（如注释或指导说明），而正确的解决方案往往是去除一些让人混淆的内容，而不是增加一些干扰。
3、不要太看重人们对新功能的要求：人们可能说“如果它能做××就好了”，这样的说法常常被认为要求增加新的功能，如果你仔细询问，会发现他们已经找到一个能实现的很好的网站，也不大可能会切换到这里来，他们只是在告诉你他们的喜好而已。
4、抓住够得着的果子：在每轮测试中，你的主要目标是寻找重要而不费力的收获。
5、有时候，真正的挑战不是修正你发现的问题，而是修正这些问题，同时不破坏已经正常运行的部分。
6、每个月花一个上午时间进行可用性测试。
7、可用性测试过程实例：
——著作权归原作者所有——
——图片来自网络——
