?網站建設中，關于用戶體驗分析的文檔一定耍描述清楚網站的結構——從命名原則和元數據的具體細節，到信息架構和交互設計的整體概況——根據項目復雜度的不同，可以有很大的不同。對于內容涉及到很多層結構的項目，簡單的文字概述可能是紀錄結構的一個最有效的方式。在某些情況下，報表和數據庫這樣的工具會被用于幫助捕捉復雜結構的細微差異。

??? 然而信息架構或交互設計的主要文檔是示意圖。視覺化地呈現結構，對我們而言，這是表述“分支、群組、組件之間的聯系”的一種最高效的方式。網站結構總是很復雜的，用文字去表達這些復雜的概念，有誰會真的去看呢?

??? 在互聯網早期，這種圖稱為“網站地圖”，但是因為網站地圖的名稱同樣也被用于網站中特定的一種導航工具(你將在第6章讀到更多)，所以現在架構圖(al'chitecture diagram)成為我們內部用來描述這種網站結構工具的術語。

??? 這種架構圖并不一定要寫明網站每一頁的每一個鏈接。實際上，詳細到這種程度的架構圖，在許多情況下只會造成混淆并且屏蔽了團隊真正需要的信息。架構圖最重要的是記錄概念關系：哪些類別需要放一起，而哪些需要保持獨立?在交互過程中那些步驟要怎樣相互配合?

由于交互設計和信息架構的概念在用戶體驗的領域里相對來說比較新穎，所以在網站開發團隊內，沒有人明確地為這些區域負責的現象仍舊非常普遍。因此，當你知道其實很少有網站可以證明它的結構是經過事先規劃的時候，你也不會感到驚訝了。

?

負責結構的任務常常是順便交給了某個人而不是通過明確地規劃。“倒底誰在負責這件事”最后通常取決于企業的文化或項目的本質。在早期的互聯網歷史中，網站通常由企業已有的技術人員創建和管理，而這是企業內部變動發生較慢(或資源非常有限)的地方，這可能仍然是今天的實際情形。

?

對于內容量繁重，或那些起初將創建網站看作營銷活動的企業，決定網站結構的責任被放到了內容建設、編輯或是公共關系部門。如果企業習慣由技術人員主導，或企業文化是技術導向的，那么結構的責任一般會落到技術項目負責人的身上。