第三章

设计师针对用户快速浏览页面这一特性所需注意的5个方面：

一． 建立清楚地视觉层次。

让页面瞬间明白易懂的一个好办法是确保页面上所有内容的外观清楚，而且能清楚表述页面内容之间的关系。

层次清楚的三个特点：

1. 越重要的部分越突出（醒目）。
2. 逻辑上相关的部分在视觉上也相关。
3. 逻辑上包含的部分在视觉上有嵌套。

生活习惯教会了我们对视觉层次进行快速分解，通常这种分解在一瞬间就已完成。除非当那些可视信息迫使我们需要停下来思考时，我们才能隐约地感觉到它的存在。好的视觉层次能够帮助用户对页面内容进行快速分辨，提高访问效率。

二．尽量使用习惯用法。

每一种出版媒体都有在发展自己的习惯用法，并不断改进这些用法，以形成新的习惯用法。在WEB上，当一种使用方法有足够多的人在足够多的地方看到使用它，那么它就会使成为一种习惯用法。

关于习惯用法的两个特点：

1. 该用法非常有用。
   习惯用法因为有用才会成为习惯用法，它保证了用户有一种熟悉感，适当应用习惯用法会使用户对网站的访问更容易，不需要花费额外的精力就能获得预期的访问成果。
2. 设计师通常不愿使用习惯用法。
   创新对设计师而言有很大的诱惑，如果打算使用一种新的方法替代已有的习惯用法，那么至少必须确认1.对用户来说新的方法是同样清楚简洁、不言而喻，无须花费很多额外精力来重新学习的。2.新的方法有很大的回报价值，因此值得用户花一点努力来学习。

在确信找到一个能让大多数人都接受的新想法前，尽量使用已有的习惯用法。

三．把页面划分成明确定义的区域。

后备箱测试

第八章

人的天性有一种把自己的喜好投射到全部web用户身上的倾向，认为绝大多数用户喜欢自己所喜欢的，我们通常认为大部分web用户和我们一样。

由于职位的不同，web团队的成员对于好的网站设计如何组成有着非常不同的看法。

“大部分web用户和我们一样”这样信仰背后还有另一个隐藏得更深的信仰：相信大部分web用户是弹性的，可以随意变化。

不要问这样的问题“大部分人喜欢下拉框吗？”正确的问题应该是“在这个页面，这样的上下文中，这个下拉框及这些下拉项目和措词会让可能适用这个网站的大部份人产生一种良好的体验吗？”回答这个问题的方法只有一个“测试”。
争辩人们喜欢什么既浪费时间又消耗团队精力，而通过测试将讨论对错转移到什么有效、什么无效上更容易缓和争论，打破僵局。而且，测试会让我们看到用户的动机、理解、反应的不同，从而让我们不会再坚持“用户的想法和我们的想法一样”。

第九章

焦点小组与可用性测试的区别：

焦点小组是一小组人（通常5~8人）围坐在桌子旁边，对展示给他们的想法和设计做出反应。这是一个小组过程，主要价值来自参与人员彼此的反应。焦点小组是快速得到用户意见和感觉的一种不错的方法。

可用性测试是一次一个用户展示一些内容（不管是网站、网站原型、或是一些单个页面的草图），并且要求用户说出：1.这是什么？2.试着用它来完成一些典型的任务。

焦点小组在抽象地确定你的目标受众想要什么，需要什么，喜欢什么的时候会很有用。它们也可以测试出网站的理念是否有意义，价值主张是否吸引人。同时，它们在测试你的网站功能命名，发现用户对你的竞争对手看法等方面也是很好的办法，但这种方法并不适合用来了解你的网站运行情况，以及怎样改进网站。

你能从焦点小组了解到的是你在设计网站之前就应该了解得。焦点小组是用在这个过程早期阶段的方法。

可用性测试的几个事实：

• 如果想建立一个优秀的网站，一定要测试。
• 测试一个用户比不做测试好一倍。
• 在项目中，早点测试仪为用户好过最后测试50位用户。
• 人们对招募用户代表的重要性估计过高。
• 测试的关键不是要证明什么或者反驳什么，而是了解你的判断力。
• 测试是一个迭代的过程。
• 没有什么比现场用户的反应更重要。

5个不进行可用性测试的错误辩解：

1. 我们没有时间
2. 我们没有钱
3. 我们没有专业知识
4. 我们没有可用性实验室
5. 我们不知道怎样解释这些结果。

可用性测试对参与的对象不敏感。
招募测试对象可以利用你能够寻找到的普通任何人，然后曲线上升。

测试用户和目标群体之间可以存在差别，理由如下：

• 实际上，我们都是初学者。
• 设计出的网站只有你的目标群里会使用，这通常不是个好主意。
• 专家通常不会介意对初学者来说很直观的界面。

一些例外：

• 如果你的网站几乎只由某一类用户使用，而且招募这一类测试用户并不困难。
• 如果你的目标用户群体可以分成几个明显的阵营，而且这些阵营有着完全不同的兴趣和需要。
• 如果使用你的网站需要专门领域的知识。

招募测试对象应注意的几个问题：

• 提供合理的激励。
• 邀请要简单。
• 避免对网站（或网站背后的组织结构）进行预先讨论。
• 别不好意思请朋友和邻居帮忙。

可用性测试分两种：“理解”测试和关键任务的测试。

• “理解”测试就是让用户看到网站，然后看他们能否理解这个网站，理解网站的目标，价值主张，组织方法，运行方式等。
• 关键任务测试就是让用户完成一些任务，然后观察他们是怎么做的。

建立网站时，越早把设计思想展示给用户约好，设计师通常不愿意展示尚未完成的作品，但用户更愿意评论一些看起来还没有完成的东西，因为他们知道你还没有投入太多，还有机会进行修改，而且，由于这还不是一个精雕细琢的设计，用户不会被实现细节所吸引，从而可以把注意力集中在要点和措辞上。

总结测试结果要做的两件事：给问题分类，解决问题。
从其他人的角度看你的作品，这样的体验常常能为问题提供全新的解决方案，或者让你用一种崭新的眼光看待原有问题。

测试过程中最有可能碰到的问题：

• 用户不清楚概念
• 他们找不到自己要找的字眼
• 内容太多

问题内类指南：

忽略皮划艇问题：
可能会遇到这种情况：用户暂时出现错误，然后再不需要任何帮助的情况下回到原来的轨道，只要，1.出现问题的人马上发现自己偏离了原来的主体。2.他们尽量回到原来的方向而不需要帮助。3.这种情况看起来并没有扰乱他们的活动，你就可以忽略这些。总的来说，如果用户关于在哪里找到他们需要的内容的第二次猜测总是对的，那就不是什么问题。

抵制添加的冲动：
当在测试时清楚地看到人们没有理解某些内容时，大部分人的第一反应是增加一些内容，如注释或一些指导说明。然而正确的解决方案往往是去掉某个或某些让人混淆的内容，而不是增加另一些干扰。
不要太看重人们对新功能的要求。

抓住够得着的果子：
每轮测试中，你的主要目标是寻找重要而不费力的收获，一般有两个类别：恍然大悟型和便宜型。

注意整体性：当你把某些部分调整得更为突出时，想想看是不是把其他内容的重要性降低了。

第十章

Web 可用性除了不要让用户思考，还有另外一个重要的组成部分：做正确的事，为用户考虑周到。除了“我的网站清除吗？”之外，还要问“我的网站值得尊敬吗？”

降低好感的几种方式：

• 隐藏我想要的信息
• 因为没有按照你们的方式行事而惩罚我
• 向我询问不必要的信息
• 敷衍我、欺骗我
• 给我设置障碍
• 你的网站看上去不专业

提高好感的几种方式：

• 知道人们在你网站上想做什么，并让它们明白简易
• 告诉我我想知道的
• 尽量减少步骤
• 花点心思
• 知道我可能会有哪些疑问，并且给予解答
• 为我提供协助，例如打印友好页面
• 容易从错误中恢复
• 如果不确定，记得道歉

第十一章，第十二章
略