用户体验的要素
现在，我们可以把整个混乱的词汇集放到这个模型里了。把每一个层面分成各个组成部分，通过这个方法，我们就可以仔细地看看所有这些片段是如何组合在一起，从而形成整个用户体验的。
战略层
无论是在软件产品还是信息空间，战略层所关注的内容都是一样的。来自企业外部的用户需求（user need）是网站的目标─尤其是那些将要使用我们网站的用户。我们必须要了解这些观众想从我们这儿得到什么，还要知道他们想达到的这些目标将怎样满足他们所期待的其他目标。
与用户需求相对应的，是我们自己对网站的期望目标。这些网站目标（site objective）可以是商业目的（通过网站达到今年100万美元的销售收入）或者是其他类型的目标（让选民了解下一届候选人的情况）。在第3章，我们将了解更多这些要素的细节。
范围层
从战略层进入范围层以后，在软件方面它就转变成创建功能规格（functional specification）：对产品的“功能组合”的详细描述。而在信息空间方面，范围则是以内容需求（content requirement）的形式出现：对各种内容元素的要求的详细描述。第4章将讨论这些范围层的要素。
结构层
在软件方面，结构层将从范围转变成交互设计（interaction design），在这里我们可以定义系统如何响应用户的请求。在信息空间方面，结构层则是信息架构（information architecture）：在信息空间中内容元素的分布。关于这些你将在第5章了解更多细节。
 |
框架层
框架层被分成了三个部分。不管是软件界面还是信息空间，我们必须要完成信息设计（information design）：一种促进理解的信息表达方式。在软件产品那边，框架层还包括了界面设计（interface design），或者也可以说安排好能让用户与系统的功能产生互动的界面元素。对于信息空间方面来讲，这种界面就是导航设计（navigation design）：屏幕上的一些元素的组合，允许用户在信息架构中穿行。关于框架层的更多内容将在第6章描述。
表现层
最后，我们还有表现层。不管是软件产品还是信息空间，在这里，我们的关注点都是一样的：视觉设计（visual design），或者说最终产品的外观。它做起来比说起来要棘手得多。你可以在第7章发现与之相关的所有内容。
应用这些要素
很少有网站只属于这两部分的任何一个。在每一个层面中，这些要素必须相互作用才能完成该层面的目标。比如，信息设计、导航设计以及界面设计，它们共同定义了网站的框架层。你在某个要素上所做的决定对同一个层面的其他要素是不可能没有影响的。所有处在同一个层面中的要素都具有相同的功能─在这个例子里，就是“定义网站的框架”─即使它们是通过不同的方式。
这种把用户体验划分成各个方块和层面的模式，非常有利于我们去考虑用户在体验中有可能遇到的麻烦。但是在现实世界中，这些区域之间的界限并没有那么明确。最常见的情形是，你很难鉴定某个用户体验的问题是否可以通过重视这个要素或那个要素去解决。是在视觉设计上玩一些小把戏就可以呢，还是要改造最基本的导航设计？某些问题要求同时重视多个区域，而另一些好像就横跨在这个模型中各个要素的边界上。
这样的组织方式常常使“设计用户体验”这件事进一步复杂化了。在一些企业中，你会遇到一些被称为“信息架构师”或“交互设计师”的人。不要被这个现象搞糊涂了。这些人一般都具有很多种专业技能，这些技能包括大多数与用户体验的要素有关的领域，而不仅仅是他们的职位名称所表明的那些内容。你的团队里，不一定非要一个了解各个领域的专家；你只需要保证有专人在负责考虑每一个议题就行了。
还有两个额外的因素，它们将会对最终的用户体验产生影响，但是在这里无法详细描述。首先就是内（content）。古语说道（嗯，在网页刚出现的时候）：在网页里“内容至上”。这绝对是个真理─大多数网站能提供给他们的用户的最重要的一件东西，就是这些用户认为有价值的内容。
用户不会仅仅为了体验导航的乐趣而访问网站。你可以得到的内容（或你有资源去得到和管理的内容）将在你的网站中扮演一个非常重要的角色。在之前网上书店的例子中，也许我们决定让用户看到被出售的所有书籍的封面。如果能得到这些封面的话，我们有某种方法可以给它们分类吗？可以跟踪它们的变化，以及保持更新吗？如果某本书的封面我们根本就拿不到手，这种情况要怎么处理呢？这些内容问题，对用户在网站上的最终体验非常重要。
其次，技术也像内容一样，对于建立一个成功的用户体验很重要。在大多数案例中，你所能提供给用户的体验状态主要是由技术来决定的。在网页刚出现的时候，把网站和数据库连接起来的工具相当原始，而且非常有限。但不管怎样，随着技术的发展，数据库被更加广泛地用于网站的驱动和控制。这反过来又使得越来越精细的用户体验方法变得可能，例如动态的导航系统，就是一种根据用户在网站中的移动来改变导航的技术应用。技术总在变化，用户体验的领域必须要适应这些变化。虽然如此，用户体验的要素始终是不变的。
这本书以下的内容将分层面讨论这些要素，非常详细。我们将仔细了解一些用于处理每一个要素的工具和技术。我们将知道每个层面中哪些要素是共同的，是什么让它们各不相同，以及它们是如何相互影响，然后创建出一个总体的用户体验的。
第8章 要素的应用
不管你的网站有多大，用户体验的要素都是一样的。但是，将这些要素背后的想法付诸实施看起来像是一次自我挑战。这不仅仅是时间和资源的问题─它常常是一个心态的问题。
回过头来看这五个层面─战略、范围、结构、框架和表现─它们听上去都像是有一大堆工作要做。当然这种需要高度注意所有细节的工作，必须要费花几个月的开发时间和一小组经过专业培训的团队来完成，不是吗？
不一定的。当然，对一些项目和一些企业来说，专门成立一个由专家组成的小组是分配责任最有效的方法，它太复杂而很难采用其他任何方法来解决。此外，由于专家可以专注于完整的用户体验的某一个方面，他们通常对自己所承担的那部分工作有着更加深刻的理解。不过，大部分时间，在有限资源下的小团队也能达到相似的目标。有时只有几个人的小组实际上可以产生比一个大团队要好得多的结果。
 |
创建用户体验其实就是大量收集亟待解决的非常细微的问题。“成功的方法”和“注定会失败的方法”的差异归根结底就是以下两点：
了解你正在试着去解决的问题。你已经知道在主页的那个紫色的大按钮是个问题，是按钮太大还是紫色不合适？它们哪个需要改变（表现层）？是这个按钮在这个页面上放置的地方不对（框架层）？还是这个按钮所代表的功能并不是按照用户所期望的那样在工作（结构层）？
了解你的解决办法所造成的后果。要记住你所做出的每一个决定对其上、其下层面都有可能会产生“连锁反应”。在你的网站的某个部分运作得非常好的导航设计，可能完全不符合结构层的另一个部分。产品选择向导的交互设计也许是一种创新的方法，但它是否能满足“技术恐惧症用户”的需求呢？
创建你的网站的用户体验，这个任务看上去可能是一件显然很艰苦的工作。但你一定会惊讶于有多少组成用户设计开发过程的细微决定完全是不自觉而产生的。大部分时候，关于用户体验的决策总会体现在以下这些场景之中：
由现状决定的设计（design by default）。这发生在当用户体验的结构遵循其背后的技术，或你的企业的结构时。将客户的定单记录和消费信息分别保存在独立的数据库中，也许对于你现有的技术系统是合理的，但是这并不意味着把它们从用户体验中分开也同样是一个好主意。相似地，来自企业内部不同部门的内容，也只有在放到一起而不是保持独立的时候才会更好地服务于用户。
由模仿决定的设计（design by mimicry）。这发生在当用户体验依靠于来自其他网站、公共刊物或软件应用程序的相似情况时，不管这些情况对你的用户（或甚至对网站）来讲是否确实合适。最常见的例子是，在上个世纪90年代晚期，某个网站偶然把标签作为全局导航的一种设计，现在已经成为一个普遍的现象。
由领导决定的设计（design by fiat）。这发生在当用户体验由个人喜好来决定而不是由用户需求或网站目标来驱动的时候。如果由于某个高级副总裁很喜欢橙色，配色方案中橙色就占了主导地位，或者由于你的研发工程师的领导喜欢下拉菜单，结果导航元素就变成了下拉菜单的话，你就已经忽略了应该用于驱动你所做出的决策的战略目标。
