也许你已经再清楚不过，确定一个项目的需求往往并不只是问问客户那么简单。你的客户有明确的目标，但除此之外她没有更多的想法。你要靠自己来判断需要哪些元素、它们各自的位置、工作方式以及背后的理由。不过幸运的是，你正好可以借此机会试着利用框架来启动一个设计项目。

拿商务网站举个例子，尽管在你真正投人到开发中（而且有更好的客户和 用户反馈）之前，似乎很难确定产品的重点和功能，但其实几乎每一个商务系统都由一些已知的子系统构成。

*目录结构
*搜索系统
*购物车
*支付流程
*订单管理框架
*关于我们

就算不知道这个商务网站会卖哪些产品，你也完全可以动手设计它的架构，以及大概的通用页面布局。在此之后，随着需求的逐步明确，你可以对最初的粗略设计进行调整，直到完全满足项目的需要。没有必要等所有问题都有了答案才开始动手。你了解了要创建的网站类型以后，就可以进行粗略的布局等工作，至于站点的最终目的是什么其实无关紧要。

有人认为既然框架对于项目启动这么有效，如果设计真有这么简单，那么互联网就不会再有什么可用性问题了。显然，这与事实不符。我们开始选择框架和设计模板以后，关注到细节问题，真正艰难的选择才开始。因为在这个时候，上下文情境成为了项目中最为关键的考虑因素。

要想理解上下文情境，首先得理解使界面得以运作的以下3个基本元素。

*用户：如果你用一个用户替代了另一个用户，你会得到不同的结果。

*界面：如果你替换成另一个界面，也会得到不一样的结果。

*上下文：这一特性不受特定用户或工具的影响。

如果设计中出现了可用性问题，通常是因为团队成员没有掌握用户可能的上下文情境（而这本应是他们的分内之事)。对这方面意识很强的团队更容易做出让用户自始至终都感到高兴的设计。

试想当同一个用户和同一个界面处于两种不同的上下文情境中时，会发生些什么。在这里，虚构的用户Janice需要用某个类似PowerPoint的工具来制作—篇演讲稿。
在第一种上下文情境中，Janice正在创建一份复杂的业务图表，用于为董事会所做的一次报告。这次报告将在6周之后进行。她之前从没用过这个工具。

为了成功进行报告，她需要确保图表能够有效地传达出其中的内容，因此她会花些时间研究这个工具的图形编辑选项，以得到正确的布局和格式。同时因为距报告还有6周时间，她会密切关注各个细节，例如字体、颜色和间距，尽可能获得最好的印象。

在第二种上下文情境中，Janice正在创建一份复杂的业务图表，用于为董事会所做的一次报告。但这次报告将在45分钟之后进行。她之前从没用过这个工具。为了成功，Janice仍然需要确保图表能够尽可能有效地传达出信息，但由于时间极为有限，她打算依赖于已有的模板。她需要一个能立刻上手的模板，这样才能把剩余的大部分时间放在核实数据的准确性上面。至于布局什么的， 没时间多考虑了。