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

然后，在第一次实地访问之前，他们会根据对受访者已有的了解来猜测这些问题的答案。即使只是猜测，他们也会老老实实地思考每一个答案，时不时还会在内部小小讨论一下。这个过程会在他们头脑中描绘出用户大概是个怎样的人，以及可能的上下文情境会是怎样。

当他们到实地访问用户时，用户的真实环境与他们头脑中的描绘之间的任何不同都会引起他们的注意。这样一来，在访问中收集数据变得非常容易。

为什么不能跳过访问，而只通过头脑风暴归纳出所有可能的上下文元素，然后确保设计满足每一种需求呢？首先，除非有极好的运气，否则你的团队不可能有足够的资源构建出一个万能的设计，以适应每一种可能的上下文因素的组合。其次，每一次实地研究都会发现团队从未预料到的事情，因为真实上下文情境背后的因素与团队自身的经验是不一样的。

通过观察你的潜在用户如何在自己的环境中进行互动，你会发现那些最常见的上下文元素，以及对设计的可用性影响最大的上下文元素。此外，你还可能会发现一些从未料到的情况。

设计就发生在用户、界面和使用的上下文情境这3者的交集处。对于界面设计师来说，关键是要理解各种可能的上下文情境，以确保设计能够一直保持较高的可用性，无论用户身边发生了什么。

只有通过这种对用户上下文的理解，我们才能理智地选择框架，以及在实现过程中应包含的设计模式。

在我们这个虚构的旅游网站案例中，用户可能存在着多种上下文情境。他们也许是在办公室筹备一次出差，也许是在家里考虑带孩子出去度假，也许是在酒吧和朋友们酒醉之后计划一个远离尘嚣的周末狂欢，或者其他各种情形。不过，用户在这里不需要得到什么批准，因为最后得到的旅行指南只会提供建议——不能提供任何房间预定或服务。在这种情况下，人们使用网站更可能只是为了在出发前顺便得到一些建议而已。因此从本质上来说，这是一个单一任务的网站。而在单一任务的网站上，主要任务流程的起始点最好放在页面中最为显著的位置。我们的目标是不在主流程提供辅助性的功能和信息，但仍提供对它们进行访问的途径，同时让用户能随时进人流程，完成主要的任务。

信息架构已经初见端倪。

除此之外，用户应该能了解是谁在经营网站，从而判断这些建议是否可信，或者值得关注。也就是关于我们框架。用户应该能在网站中设置自己的偏好，以便控制最后的旅行指南中出现的建议。如果那些经常去固定地点出差的用户，重复访问网站时，每次都被迫提供相同的答案，这会令他们很恼火，所以，网站应允许用户指定默认设置，也就是账户管理框架。用户还应该能找到某个特定的旅馆、景点、健身房的信息，也就是搜索框架。此外（当然了）首先需要说服他们使用我们的网站，也就是注册框架。

哪怕对网站的核心任务流程还一无所知，你就已经掌握了4个框架体系。有了它们，你就可以和客户讨论细节部分，比如用户定制的动态指南，等等。

就和写文章一样，选择框架就是把项目分解成几个部分，然后为这些部分填充细节，使其富有生命力。在这个部分，我们用A。另一个部分B。而那里是C。然后你再把它们拼合到一起，写上承前启后的连接段，做些调优工作，一切就完事大吉了。即时的网站。当然，要想承前启后得更加漂亮，你还需要确定网站每一个元素的展现形式。这就是设计模式和设计标准开始发挥作用的时候了。