使用者體驗要素之互動設計與資訊架構——團隊角色和流程
今天為大家更新《使用者體驗要素》的第五章——結構層，互動設計與資訊架構——團隊角色和流程
本小結關鍵詞： 團隊角色和流程
主要觀點：否有專門的資訊結構設計師來解決結構問題並不重要，重要的是這些問題能由某個人來負責
團隊角色和流程
文件一定要描述清楚網站的結構——從命名原則和元資料的具體細 節，到資訊架構和互動設計的整體概況——根據專案複雜度的不同，可以有很大的不同。對於內容涉及很多層結構的專案，簡單的文字概述可能是紀錄結構的一個最有效的方式。在某些情況下，報表和資料庫這樣的工具會被用於幫助捕捉複雜結構的細微差異。
然而資訊架構或互動設計的主要文件是示意圖。視覺化地呈現結構，對我們而言，這是表述“分支、群組、元件之間的聯絡”的一種最高效的方式。網站結構總是很複雜的，用文字去表達這些複雜的概念，有 誰會真的去看呢？
在網際網路早期，這種示意圖稱為“網站地圖”，但是因為網站地圖的名稱同樣也被用於網站中特定的一種導航工具（你將在第6章讀到更多），所以現在架構圖（architecture diagram）成為我們內部用來描述這種網站結構工具的術語。
這種架構圖並不一定要寫明網站的每一頁的每一個連結。實際上， 詳細到這種程度的架構圖，在許多情況下只會造成混淆並且遮蔽了團隊 真正需要的資訊。架構圖最重要的是記錄概念關係：哪些類別需要放一 起，而哪些需要保持獨立？在互動過程中那些步驟要怎樣相互配合？
我剛做這行的時候，我發現我不得不在一個接一個的專案中一次又一次地重複相同的、基本的互動流程。隨著時間的推移，我逐漸地找到 一種規範化的方式來繪製我對網站的構思。我選擇了曾經用過的一組特殊的圖形，並給每一個圖形的含義做了明確的定義。
我創造的圖解網站結構的系統稱作“視覺辭典（visual vocabulary）”。從2000年我第一次在網際網路上公佈它開始，全世界的資訊架構師和互動設計師都接受了它。
視覺辭典是一個提供從非常簡單（上圖）到非常複雜（下圖）的示意結
很多企業都有一個負責做架構的全職使用者體驗設計師，而在另一些企業，架構設計通常都只是某個人職責的一部分，而並沒有當成一件有意識的工作來做。“倒底誰在負責資訊架構”最後通常取決於企業的文化或專案的本質。
對於內容量繁重，或那些起初將建立網站看作營銷活動的企業，決定網站架構的責任被放到了內容建設、編輯或是公共關係部門。如果企業習慣由技術人員主導，或企業文化是技術導向的，那麼架構的責任一般會落到技術專案負責人的身上。
招聘一名全職負責架構問題的專家可以使每個專案都得到好處。有時這個人的職位名稱被稱作“互動設計師”，但通常他們是指“資訊架構師”。不要讓名稱把你搞糊塗了，雖然一些資訊架構師確實主要負責創 建內容網站的組織和導航結構，但是大多數情況下，資訊架構師也具有某種程度上的互動設計經驗，反過來也是一樣的。資訊架構和互動設計非常相近且相關，因此“使用者體驗設計師”已經漸漸成為一種更普遍的職位名稱，用來稱呼具有這類技能的人。
你的企業正在進行中的工作的數量，也許還不足以招聘一名全職的資訊架構師作為團隊的長期成員。如果你的網站開發主要是內容的更新，而且你不需要定期對整個網站進行重新設計和新的開發，那麼招聘一名全職的資訊架構師可能就不太合適。但如果你的網站將穩定而持續地增加新內容和新功能，那麼一名全職的資訊架構師，能幫助你確保整個新增內容的過程能夠最有效地滿足使用者需求與企業的戰略目標。
你是否有一位專家來解決結構問題並不重要，重要的是這些問題能由某個人來負責。不論你是不是做過這方面的規劃，你的網站都會有一個結構。一個建立在明確規劃上的網站，會減少頻繁檢查維護的工作量，也能為網站的所有者帶來可見的結果，同時還能滿足他們的使用者的需求。
以上我們就更新完了第五章結構層的內容，接下來將對本章進行復盤，敬請期待吧~