在互联网上可能存在着数百万个设计模式，它们每天都在被人使用其中一些模式很流行。就此而言，它们似乎就是所谓的界面模块的理想“后备”，但其实模式仍然存在着一些无法摆脱的局限。

设计模式能够解决那些范围较小的具体问题（这也正是我们期待的结果），但是我们无法从中得知这些问题之间是否有联系、是否会顾此失彼。尽管在一般的模式描述文档中有一个上下文情境项，但它也只是讨论了模式能在何处适用，其中既没有提到该模式会如何影响整个应用程序，也没有提到它和系统其余部分的联系。而在必备条件项中，也只是列出了与该模式密切相关的其他模 式，并没有揭示其表面下的深层原因。

我们希望创造出成功的设计，然而设计模式缺乏足够的上下文信息，为我们留下了许多悬而未决的问题。每个页面应该显示多少条搜索结果？应该如何处理错误（例如用户输入错误或者零结果搜索）？用户怎样才能开始新搜索？每条结果应该提供多少信息？哪些信息更为重要？单凭模式是无法回答这些问题的。

比如，分页界面能让用户从一个页面前往另一个页面，然后还能再回来。这的确解决了一个问题，为一个操作提供了支持。然而要想追求可用的设计，还有很多其他问题需要考虑。

要想回答这些问题，我们不能只着眼于分页界面，而必须考虑整个搜索系统。换言之，我们不能只依赖于设计模式，而必须了解模式是如何构成系统，而系统又是如何构成整个应用的。

那么组件呢？从本质上来说，它们也只是某个公司（或组织）定义的模式的代码完成版本而已，因此也同样爱莫能助。

要想回答这些问题，我们需要审视可重用铁三角中凌驾于设计模式之上的更高层次：交互设计的框架体系。