戰略層要解決的是“用戶的需求是什么”，范圍層告訴我們“什么樣的信息將滿足用戶需求”，而在結構層我們要面對的問題是：“具體識別出用戶心目中至關重要的信息 ”。

結構層的定義

在定義好用戶需求并排列好優先級別之后，這些需求并沒有說明如何將分散的片段組成一個整體，而結構層為產品的創建一個概念結構。在這個部分的決策本身仍然包括大部分的概念性內容。

在傳統的軟件開發行業，交互設計主要指的是一種“為用戶設計結構體驗”的方法。而信息架構是在內容建設方面構建用戶體驗。但是交互設計和信息架構都強調的一個重點是：確定各個將要呈現給用戶的元素的模式（patterns）和順序（sequences）。在這個重點中交互設計關注將影響用戶執行和完成任務的元素，信息架構則關注如何將信息表達給用戶的元素。并且我們還會接觸到產品成型過程中的重要概念概念模型（conceptual model）。

· 交互設計

交互設計關注與描述“可能的用戶行為”，同時定義“系統如何配合與相應”這些用戶行為。也就是我們經常會接觸到的“輸出與反饋”。

因為作者是程序員出身，他最關注軟件的兩個方面是“它做什么”和“它怎么做”，但是在重視技術效率時，往往忽略了什么才是對用戶來說最好的系統。

· 概念模型

概念模型（conceptual model）是用戶對于“交互組件將怎樣工作”，軟件是否把某個特性處理成用戶所熟悉的某個概念。這里我們需要將概念模型與心智模型（或心理模型，mental model）區分開，心智模型指的是由個人經驗及學習，在腦海中對某些事物發展的過程，進行預測寫下的劇本。

這里的心智模型指的是用戶的心智模型，而概念模型指的是我們最后把產品做成的樣子。當產品的概念模型和用戶的心智模型不相符，那么這個產品的學習成本是很高的，也很難被用戶接受。使用人們熟悉的概念模型，會使用戶很快適應一個不熟悉的網站。這也是為什么現在很多產品看起來很像的原因，在用戶已經熟悉了某類產品的通用做法，我們繼續采用這種做法，會加快用戶熟悉產品的速度。

如果你有足夠的把握勇于創新，那么要保證自己有一個好的理由說服用戶，并且準備好一個通用的備用方案。令用戶不太熟悉的概念模型只有在用戶能正確理解并詮釋它的時候才能起到作用。

在《About Face》中，將概念模型進一步細化為實現模型與呈現模型，其中實現模型指向的是程序員的工作，呈現模型指向設計師的工作。我們不需要把概念模型明確告訴用戶，相反我們需要隱藏代碼層面的實現模型，讓產品展現的內容符合用戶的心智模型，不需要告訴用戶產品是如何實現這個功能的，只要用戶簡單快速實現自己的目標即可。

當然也不能為了使二者匹配，將現實生活中的東西生搬硬套到產品的概念模型中。舉一個例子，見仁見智，這里謹以一個“雙重果粉”的身份說一下使用感受。我們都知道堅果自帶程序的擬物效果處理非常細致，從視覺感官上非常享受。但是有些擬物過度的設計會降低易用性，比如圖中的秒表就是一個完全擬物的例子。

雖然二者都包含了開始計數、停止、多次計數、清零等功能，但是從使用感受上，卻完全不同。第一次看到堅果的頁面，從未使用過體育秒表的我是懵的，“好膩害的樣紙，但是怎么用這東西…………啊這個居然可以按，666……”由于重視秒表的展現，上部分區域擠壓了多次計數結果的展示空間。

再看蘋果的頁面，頁面簡單直接，識字的傻子都會用，并且能清楚地知道哪里是可以點擊的，還并且能準確地點中想要的操作。當然我知道會買錘子的大家一定都是具有冒險探索精神和不怕累不怕苦的品質的，也知道秒表對大部分人并不是一個高頻使用的功能，但是就我個人而言，一旦要著急計個時什么的一定是會選擇用蘋果的秒表。

· 錯誤處理
當我們對用戶的心智模型猜測不準或者因為一些技術上的限制，我們需要考慮用戶犯錯時，系統應該怎么做：

1.最好的防止錯誤的方法，是在用戶操作前就將系統設計成不可能犯錯的那種。

2.在用戶操作時，避免錯誤的方法是使錯誤難以發生。系統應該幫助用戶找出錯誤并改正錯誤，當然也要小心一些令人反感的試圖善意修改用戶錯誤的提示。

3.錯誤發生之后，有效的錯誤信息和容易自我解釋的頁面幫助用戶糾正。系統應該為用戶提供從錯誤中恢復的方式，同意用戶“撤銷”操作。并且對于一些不可恢復的錯誤，提供準確的警告提示。

· 信息架構

信息架構主要體現在信息型產品的結構層，對于目前市面上的大部分產品，內容是躲不開的，因此信息架構也是我們需要重點理解的部分。在以內容為主的網站上，信息架構的主要工作是設計組織分類和導航的結構，讓用戶可以高效率、有效地瀏覽網站的內容，使呈現給用戶的信息合理并且具有意義。

信息架構與信息檢索的概念密切相關，都是為了設計出讓用戶容易找到信息的系統。下面將信息架構分為結構化內容、結構方法、組織原則、語言和元數據這四部分進行了解。

結構化內容
信息架構要求創建分類體系，涉及的領域包括向來都要考慮的組織管理、分類、順序排列。我們通過從上到下和從下到上兩種方式來建立分類體系。

從上到下（top-down approach）：從戰略層所考慮的內容入手，根據產品目標與用戶需求直接進行結構設計。先從最廣泛的、有可能滿足決策目標的內容與功能開始進行分類，然后再依據邏輯細分出次級分類。
缺點是可能導致內容的重要細節被忽略。

從下到上（bottom-up approach）：從范圍層所考慮的內容入手，根據內容和功能需求的分析而來。先從已有的資料開始，全部放入最低級別的分類中，再把它們分別歸屬到高一級的類別，從而逐漸建立出耿恭反映我們產品目標和用戶需求的結構。
缺點是可能導致架構過于精確地反映出現有內容，可拓展性不強。

結構質量最重要的標準：不是整個過程一共需要多少步驟，而是用戶是否認為每一個步驟都是合理的，以及當前的步驟是否自然地延續了上一個步驟中的任務。貌似很多產品經理都很喜歡把所有步驟放在同一個頁面上，在app端也希望在一個頁面把所有事情做完。這時候你就可以說理直氣壯地告訴TA“大量數據證明，用戶會喜歡一個被清晰定義的七步過程，而不是一個令人困惑的、被勉強壓縮的三步過程。”

另一個證明結構是否高效的標準是產品的“容納成長和適應變動”的能力，充分考慮產品的可拓展性，避免了設計師和研發人員每次迭代都是一次大手術，更方便頁面的統一性。

結構方法
信息架構的基本單位是節點（node）。節點可以對應任意的信息片段或組合，可以是一個數字，一個控件，一個組件，一個頁面，甚至一個功能。節點的抽象性使得我們能明確地設定對產品關注點的詳略程度。常見的結構類型有層級結構、矩陣結構、自然結構、線性結構。

層級結構（hierarchical structure）：又稱樹狀結構（tree structure）或中心輻射結構（hub-and spoke structure）。它的節點與其他相關節點之間存在父級/子級的關系。子節點代表著更狹義的概念，從屬于代表著更廣義類別的父節點。不是每一個節點都有子節點，但是每一個節點都有父節點。
這種類型的結構是最常見的，傾向于層級的工作方式。

矩陣結構（matrix structure）：允許用戶在節點與節點之間沿著兩個或更多的“維度”移動。
這種類型的結構通常用于“帶著不同需求的用戶”，因為它的每一個“軸”都可以與每一個用戶的需求聯系在一起。

自然結構（organic structure）：不會遵循任何一致的模式。節點是被逐一連接起來的，同時這種結構沒有太強烈的分類概念。
這種類型的結構適合于對探索一系列關系不明確或一直在演變的主題。

線性結構（sequential structure）：連貫的語言流程是最基本的信息結構類型。我們接受的九年義務教育也同屬于線性結構。
這種類型的結構常見用于小規模的結構，比如單篇文章或專題。大規模的結構則被用于那些內容順序對于用戶需求非常關鍵的應用程序，比如教學資料。

組織原則
節點在信息架構中是依據組織原則（organizing principle）來安置的，組織原則是我們決定節點分組或獨立的標準，不同的組織原則將被應用在不同的區域和層面。

一般來說，我們在產品最高層級使用的組織原則應該緊密地與“網站目標”和“用戶需求”相關，而在結構中較低的層級，內容與功能需求將對所采取的組織原則產品重大影響。任何一種信息收集都有一個固定的概念性結構。實際上，這種概念結構通常不止一個，那也是我們要解決的問題之一——創建一個能與產品目標和用戶需求相對應的、正確的結構。

書中還提到了一個知識點截面（facets），這是圖書館學的一個概念。產品的內容可以按照一定的屬性進行分類，而這些屬性就叫做截面。使用錯誤的截面可能比沒有使用截面更糟糕，解決的辦法是將每一個有可能的截面都當做組織原則呈現給用戶，讓用戶自己選擇最重要的那個。

語言與元數據
使用“統一規范的語言”、“用戶的語言”不論是在內部工作中，還是輸出給用戶都十分重要。因此，我們需要對命名原則（nomenclature）進行規定，包括描述、標簽，和網站使用的其他術語。

把用來強調一致性的工具稱為受控詞典（controlled vocabulary），是網站使用的一套標準語言。受控詞典提供了一個明確的資源以確保大家都能使用用戶語言，并且防止企業內部的專用術語侵入網站。如果詞匯隨意使用不統一的話，我們在工作中溝通的效率會大大降低。程序員也對文檔表示疑惑，這說的是一個功能還是三個功能？

除此之外，我們還會創造類詞詞典（thesaurus）提供常用的、但未納入該產品標準用語的詞匯以供選擇，也包括一些詞語更廣義、更狹義或相關詞匯的建議。這在電商類產品中非常重要，有產品但是搜不出來，或者搜出來結果不對就非常尷尬了。好的類詞詞典能做到高度精準的、并且推薦高度相關的搜索結果。

受控詞典與類詞詞典對建立包含元數據（metadata）的系統特別有用。元數據是“關于信息的信息”，即以一種結構化的方式來描述內容的信息。好的元數據可以幫助用戶在產品中更快速地找到信息，在元數據的幫助下，搜索引擎變得更加智能更加聰明。

· 團隊角色和流程

在這個層面的文檔一定要描述清楚產品的結構——從命名原則和元數據的具體細節，到信息架構和交互設計的整體概況。信息結構或交互設計的主要文檔是示意圖，也就是架構圖（architecture diagram），視覺化呈現結構對于我們來說是表述“分支、群組、組件之間的聯系”的一種最高效的方式。

架構圖最重要的是記錄概念關系：哪些類別需要放一起，而哪些需要保持獨立？在交互過程中那些步驟要怎么樣互相配合？作者創造的圖解結構，從非常簡單到非常復雜的示意結構系統，名為視覺詞典（visual vocabulary）。

小結

成功的用戶體驗，就是能事先預知用戶的期望并將其納入設計之中。在實際工作中，信息架構和交互設計的工作范疇非常相近且相關，這部分的內容開始由交互設計師主導完成。在完成過程中切記不要過早地糾結細節，先將主要功能和主要場景走通，并且與需求方實時溝通，摸透需求的本質，只有這樣框架層的內容才能繼續在結構層搭建起來的框架上繼續完成。

《用戶體驗要素》閱讀筆記

一、初識用戶體驗
二、網站的用戶體驗
三、用戶體驗五要素
四、戰略層：產品目標和用戶需求
五、范圍層：功能規格和內容需求
六、結構層：交互設計與信息架構
七、框架層：界面設計、導航設計和信息設計
九、表現層：感知設計
十、用戶體驗的應用