为什么不能跳过访问，而只通过头脑风暴归纳出所有可能的上下文元素，然后确保设计满足每一种需求呢？首先，除非有极好的运气，否则你的团队不可能有足够的资源构建出一个万能的设计，以适应每一种可能的上下文因素的组合。其次，每一次实地研究都会发现团队从未预料到的事情，因为真实上下文情境背后的因素与团队自身的经验是不一样的。
在团队出门做实地研究之前，他们喜欢先玩个游戏——把分类转化成一系列问题，就像有关要买房的Margaret的那些问题一样。比如，输入就变成了“用户在申请贷款时需要哪些个人信息”和“当用户开始申请流程时，是不是已经掌握了所有的信息”。

刚开始我们打算的是先为框架做一个简单的介绍，然后给出一整套常见的框架实例，并逐一进行深人的讨论。然而在之后的几个月时间内，我们在不停地谈论框架体系，最后意识到两件重要的事情。

第一，有一些关于框架的问题不停地有人问到，它们需要在书里提出并解决。第二，给你一整套完成后的框架，我们实际上只是授人以鱼，而非授人以渔。远比这重要的是学会以你自己的方式来思考、辨识和使用框架，以批判的眼光来琢磨，从剖析的角度来解构现有的网页，并把由此获得的洞见应用到实际中去。

为此，我们确定了几个目标。

我们都认为挫折感会导致收益的降低，而且往往都期望找出那些对销售产生影响的方面。然而，我们核算挫折成本时也需要兼顾那些盈利之外的方面。
为了计算出Amtrak的挫折成本，我们需要把可用性测试的结果、公司的财务活动以及网站的日志文件都结合起来。使用的资料来源越多，得出的数据就越令人信服。

我们都认为挫折感会导致收益的降低，而且往往都期望找出那些对销售产生影响的方面。然而，我们核算挫折成本时也需要兼顾那些盈利之外的方面。

*开支的增加

我们要看到因为该问题而招致的各种企业开支。这可能包括额外的电话客服、原材料的替换或者服务器负载的增加。

记得之前看过一句类似这样的文字描述：“好的设计是让用户体会不到设计的存在”。用户体验设计也应该类似，无论对用户或团队合作中，用户体验设计表现出的应该更多的是低调的概念传播特性。
放下对这个标题的疑惑，我们先来理解一下用户体验设计在团队中所表现出的一些“特性”。

潜性

记得之前看过一句类似这样的文字描述：“好的设计是让用户体会不到设计的存在”。用户体验设计也应该类似，无论对用户或团队合作中，用户体验设计表现出的应该更多的是低调的概念传播特性，也就是说：

*对于用户——用户体验设计帮助分析和挖掘用户潜意识的需求和习性，力求产品设计给用户带来本质上的满足，以及顺畅自然的使用体验；

你一定想培养一个健康且充满活力的社区。当你在设计界面时要考虑不同类别的参与者。当然你必须弄明白在你的在线社区里谁是有影响力的人（能帮助社区成长的人），并为他们提供露面的机会和工具来扩展他们的影响力。对于有影响力的人，可以授予特别的勋章以彰显其地位；要显示他的粉丝团数量和好友数量；让他们可以异步跟踪并拥有强大的共享工具以及特殊的发布通知的能力；他们有着与社区所有工作人员对话的特殊通道；要在社区管理、协调和社区治安方面扮演重要角色。对于局部有影响力的人（仅在群组内有号召力），对他们的内容要高亮显示。如果 你想让你的社区得到更多好评，就要突出高质量的内容并抵制质量低劣的内容。这样做的最终效果就是你收获的高质量内容要远远多于你重点强调的那些内容。当设计社交界面时，不要以为所有内容都是高质量的。在设计中，除了要突出好的内容外也要丢弃不好的内容。不要只钓大鱼，要寻找创作新颖有价值内容的新起之秀，特别是积极性高的用户。要把他们当做已成名的巨星一下让他们多露脸，多听取他们的反馈，多关注他们，并向他们提些建议和提供机会。即使你有一种自动的方法可以将用户创作的高质量内容呈现出来，也要确保你的算法不会削弱现有的“有影响力的用户”的实力。你的社区博客就是一个对积极进取的新秀给予关注的好地方。他们的故事将会鼓舞其他人，并会促使向他们学习的人加入社区成为会员。至少他们中有一些将会真正变成巨星，他们会心怀感激，自然会吸引更多的枳极人士进入你的社区。不要忽视那些潜水用户，他们这样的读者会占到你社区用户总数的百分之九十九。你可以以多种方式体现他们的存在，例如在博客文章中显示点击 量，列出最受欢迎的文章或最近点击过的条目等。在博客张贴或最近浏览量大或最流行的内容处显示的读者看法。有些用户从来都不发帖，但他们是很好的“中转站” 一一在你的社区中是否可以让用户添加到收藏夹或添加Tag标签？要制定一个 策略让观望的用户更容易地参与到社区中来。有许多手段都可以用，比如在文章的最后链接一个“推荐”或“顶”的按钮。开发一个提示系统，可以提醒用户有哪些 新的内容、其他成员的行为或需要完成的任务等。如果你有问答机制，那么就应该在用户注册或来访的时候让其对相关问题给出答复，并且要让用户很容易就能参与进来。考虑将现有的社交应用软件整合起来；如果潜水用户看到他们的朋友在你的网站上非常活跃，那他们也会很乐意就参与到社区活动中来

容量规划除了服务器和存储之外，还包含了它们所连接的网络。路由协议的实现细节和交换机的架构不在本书范围之内，但是你的网络其实和其他资源一样：容量是有限的，也很值得测量。

网络一般被视作是服务器的管道铺设，而且这个类比很恰当。当你的网络操作正常时，数据就是简单的传输。当它不正常时，一切都嘎然而止。这并不是想说，微妙而有挑战的问题不会突然出现于网络：只是离得很远。但是多数而言，网络设备是被设计用来良 好地完成一个任务，而它们的上限也应该清楚。

在托管环境的网络容量，往往是被测量的和被严格控制的资源，获得使用量的数据会是件困难的事，因为它依赖于你和你的网络供应商之间的合同。作为你流入和流出的网络使用量的健全检测，要聚集你外流服务器网络度量指标，同时将它们与你从托管供应商那里收到的清单相比较。

负载均衡器已经成为了网站运营领域一个快乐和痛苦的来源。它们的主要目的在于在机器池、或者机器的集群之间分发负载，其延伸范围可以是从数据中心里面最简单到最复杂的设备。负载均衡常常被应用到架构的前端，扮演负责响应来自用户浏览器的数据请求的Web服务器的交通警察。但是，负载均衡器也已经被用于在数据库、中间层应用服务器、跨地域的数据中心和邮件服务器之间来分散负载，这些应用领域的列表还在继续扩展。

负载均衡器基于一个相对简短的算法列表来建立负载分发，使得你能指定协议来达到跨越所有可用的服务器均衡地处理流量。《可扩展互联网架构》—书里，包含了一些在负载均衡器和它们在Web架构中的作用方面很出色的见解。

Web服务器容量是应用程序特定的。一般而言，Web服务器被看作网站服务器的前端机，它接收用户请求，调用后台资源（如数据库），然后使用调用结果产生响应。一些 应用程序做简单快速的数据库查询，其他的做少量但更复杂的数据库查询。一些网站大部分为静态页面服务，而另一些主要是动态内容。你需要根据系统和应用层的度量指标来长期观察使用量度量指标，该度量指标作为容量规划的基础。

Web服务器（静态或动态）的容量规划是峰值驱动的，因此是有弹性的，不像存储消耗量。服务器每天都消耗大量的硬件资源，在这些资源接近饱和时会有一个转换点。目标是发现周期性的峰值并利用它们驱动你的容量轨道。正如任何峰值驱动的资源，你需要找到什么时候是峰值，并深入进去发现在那段时间到底在发生什么。

有人说：“最好的产品设计就是没有帮助”，部分认同，但是那不一定是最好的产品，充其量可以算是简单有效的产品，就像我们不能说“最漂亮的衣服就是没有衣服”，有设计必然就会有问题，帮助的形式、特征、发展同样如此，我们慢慢来讨论。
最近在学习几个CG新软件，按常规先看看帮助文档，刚好UCD团队正在讨论这个问题，我也想说几句。有人说：“最好的产品设计就是没有帮助”，部分认同，但是那不一定是最好的产品，充其量可以算是简单有效的产品，就像我们不能说“最漂亮的衣服就是没有衣服”，有设计必然就会有问题，帮助的形式、特征、发展同样如此，我们慢慢来讨论。

在我们最初提出的那些可用性问题中，有八个在今天仍像我们初次发现它们时一样重要。尽管现在这些糟糕的设计方法中的一部分在Web上已经不太常见了，但其他一些实际上变得更加成为问题了，因为对它们持续的滥用已经使用户对它们更加敏感了。

仍然会引起主要问题的方面包括：

*被访问之后颜色不变的链接；

*破坏后退按钮的作用；

*打开新的浏览器窗口 ；

*弹出式窗口；

*看起来像是广告的设计元素；

*违反Web上的设计惯例；