交互设计的框架体系（也就是本书主题）是这个三位一体中的最新成员。如果说设计模式是某个常见问题的通用解决方案，那么交互设计的框架体系则是一系列设计模式再加上其他元素和信息，用以指导完整的系统或站点上下文的设计。
和人体一样，每一个Web 应用都由一系列相互合作的子系统所组成。每一个子系统都包含许多独立的单元，每个单元都具有各自的功能和用途。如果对这些成功的（和不成功的）网站及应用进行详细的解剖和分析，我们不仅能够标识出那些在不同环境下满足用户需求的常用元素，而且能够更加深刻地理解人类行为，从而改善这些标准，同时在不牺牲可用性的前提下将我们的设计提升到新的高度。
图1-3 为一个框架体系。
 |
| （点击查看大图）图1-3一个框架体系的存档文件 |
换句话说，如果仔细观察那些已然运作良好的案例，并且分析其背后的原因，我们就能同时解决两个问题：其一是明确设计的切入点；其二是了解如何才能创建出更好、更强、更快而且和那些老牌经典一样易于使用的交互设计。
比如，在第4 章中我们将描述一个注册框架，包含了数个常用于鼓励用户注册的设计元素。其中每一个元素都可以被看作是一个独立的设计模式。例如“电梯陈述”（关于应用程序本身价值的一段简要声明），它可以让人们快速、高效地了解这个网站或应用能提供什么。然而，尽管“电梯陈述”消除了用户脑海中的疑点，解决了问题，但它本身其实并没有多大意义。事实上它隶属于另一个更大的问题——如何劝服人们在崭新的Web 应用中注册。
框架体系不去为“狭隘的”问题提供“狭隘的”解决方案，它处理的是较为复杂的问题。它从产品的整体背景出发，为设计确定指导方针。
当一位用户到达某个新网站，犹豫是否注册的时候，注册框架为他做出清楚的介绍、解答疑问、指明起点，并提供注册的方法。没有哪一个单独的设计模式能处理所有这一切。实际上，真正解决问题的是这些元素的组合。进一步说，任何独立的设计模式都不能告诉我们如何满足用户的所有需求，也不能告诉我们为什么需要首先处理这些需求。
为了弥补这一点，框架体系为包含该模式的整个子系统进行了描述。一个注册子系统需要有输入用户ID 和密码的模式。但它也需要有重新获得密码的模式、建立用户档案的模式、创建新ID 的模式，以及修改密码的模式。
开发团队通过观察其他设计并提取共性的方式来标识、记录自己的框架体系。这些元素变成了一个清单，列出了一个完整的系统所需要的一切，从而帮助团队确保拥有所有正确的模式，以便开展设计工作。
框架体系是一种高度的抽象。它不涉及具体的品牌化或视觉设计需求——那是组件来完成的事情。相应地，组件又以独立的设计模式为基础。确切地说，框架体系是某种范围更广的结构化系统，从一开始就能帮助设计师对模式进行选择。我们相信，这种和模式、组件相配合的结构化系统，就是Rolf 所说的“界面模块”。
