也许你已经注意到，我们在本章所举的例子都不是那种没有注册框架就不行的应用程序——它们都不是那种必须注册才能创建或使用数据的“围墙花园”。坦白地说，这是因为并不是每一个要求注册的应用程序都真正需要这样做。

注册表单要求用户提交他的姓名、E-mail地址以及其他信息，以创建一个唯一的数据库入口，从而将用户和他的操作以及内容相联系。但并不是必须这么做。

Drop.io另一个文件共享的应用，就摒弃了注册的要求，但仍然提供了各种功能以便用户管理文件。要想创建一个存储区域以便文件共享，只需在URL中选择一个关键词（drop.io/keyword)即可。不需要E-mail地址，如果共享文件需要保护，也可以创建一个密码，但不是必须如此。

而第一次使用Tripit时，你也只需要转发一封旅程确认的E-mail,就能 顺利收到Tripit生成的旅行线路样本。以此想法为基础，应用程序可以用这个E-mail地址自动创建一个账户（也许还包括一个密码），以便用户日后能再次登录。E-mail地址完全可以作为独立的数据库标识符，而要想保护账户，一个密码自然也就足够了。因此应用程序完全可以只要求这两样信息，日后再要求人们提供更多信息。这样的流程在一开始就降低了投入，同时还能逐步提升用户对于应用程序的承诺。（人们倾向于和自己的早期行为保持一致，因此在理论上，用户构建个人资料时执行的操作越多、留下的脚印越多，他们就越可能会对这个网站“忠心耿耿”。）

在探索应用程序的设计时，有一个很少涉及的方向：如何以非标准的方式将用户和他的操作联系起来。请自问，我们能否用表单之外的什么方式？我们是否真的需要那么多信息才能为用户创建数据库入口？将用户和他的数据相联系的过程是否真的必须独立在核心任务流程之外？我们能否更有机地组织这一过程？

如果可以在用户使用程序的过程中逐步向他们索要资料信息，而不是硬塞给他们一个单独的，与程序其实并无关联的流程（比如注册表单)，我们就能减少用户的初期投入。如果能够这样，用户就不再需要决定是否注册——当他们在网站上执行操作时，实际上就已经“注册”了。

对于那些必须注册的网站，本框架中的大部分元素都很重要。最起码应该包含的是价值声明、行动号召、注册表单，以及至少一个其他元素。

不过，如果系统被设计成不用明确的注册流程即可创建账户，那么不需要注册框架的最后一个元素（也就是注册表单）也能实现客户转化的目标。这样一来，注册也能变成一种自然、有机的过程，在用户使用时就能达到效果。

设想一下吧。没有注册表单的互联网。