网站建设中，关于用户体验分析的文档一定耍描述清楚网站的结构——从命名原则和元数据的具体细节，到信息架构和交互设计的整体概况——根据项目复杂度的不同，可以有很大的不同。对于内容涉及到很多层结构的项目，简单的文字概述可能是纪录结构的一个最有效的方式。在某些情况下，报表和数据库这样的工具会被用于帮助捕捉复杂结构的细微差异。

    然而信息架构或交互设计的主要文档是示意图。视觉化地呈现结构，对我们而言，这是表述“分支、群组、组件之间的联系”的一种最高效的方式。网站结构总是很复杂的，用文字去表达这些复杂的概念，有谁会真的去看呢?

    在互联网早期，这种图称为“网站地图”，但是因为网站地图的名称同样也被用于网站中特定的一种导航工具(你将在第6章读到更多)，所以现在架构图(al’chitecture diagram)成为我们内部用来描述这种网站结构工具的术语。

    这种架构图并不一定要写明网站每一页的每一个链接。实际上，详细到这种程度的架构图，在许多情况下只会造成混淆并且屏蔽了团队真正需要的信息。架构图最重要的是记录概念关系：哪些类别需要放一起，而哪些需要保持独立?在交互过程中那些步骤要怎样相互配合?

由于交互设计和信息架构的概念在用户体验的领域里相对来说比较新颖，所以在网站开发团队内，没有人明确地为这些区域负责的现象仍旧非常普遍。因此，当你知道其实很少有网站可以证明它的结构是经过事先规划的时候，你也不会感到惊讶了。

    负责结构的任务常常是顺便交给了某个人而不是通过明确地规划。“倒底谁在负责这件事”最后通常取决于企业的文化或项目的本质。在早期的互联网历史中，网站通常由企业已有的技术人员创建和管理，而这是企业内部变动发生较慢(或资源非常有限)的地方，这可能仍然是今天的实际情形。

    对于内容量繁重，或那些起初将创建网站看作营销活动的企业，决定网站结构的责任被放到了内容建设、编辑或是公共关系部门。如果企业习惯由技术人员主导，或企业文化是技术导向的，那么结构的责任一般会落到技术项目负责人的身上。