設計指南第五章：資訊架構（上）
👉 原文連結：The Guide to Design — The Architecture of Information
本章目標：了解設計數位產品時，組織、優先性，以及清晰度三個元素的重要性。
在我們的日常生活中，有形和無形的架構處處皆是 —從網站的選單到找到正確資訊的過程。身為設計師，我們想讓使用者能夠輕鬆地找到他們想要的，而非埋沒在各種產品深不見底的資訊海中，而資訊架構師就是將其重整、合理化的專業。
我們知道並非每個產品團隊都有專職的資訊架構師，但思考架構這件事對設計師來說是當前之重，包含使用者怎麼找到各項資訊、怎麼清楚地命名目錄。
每個元素分開看時會有簡單跟複雜之差，但放在一個整體去思考時，沒有任何事物是簡單的。（Some things are simple. Some things are complicated. Every single thing in the universe is complex.） — Abby Covert
設計師所做的資訊架構決策會深遠地影響我們的工作組織，甚至社會等層級。例如，新的內容架構隱含的是新的組織結構、新的角色、新的流程，尤其在我們的社交互動在邁向數位化的過程中，牽一髮動全身。我們怎麼幫助人們在數位世界不迷失？怎麼決定人與人之間，又或與社群間的互動？當資訊架構變得如此重要時，無論是策略性或是直觀的設計，都能對人們的生活造成莫大影響。
在本章節，我們會帶到資訊架構的基本定義、認識其怎麼影響了我們使用的產品，並學習如何將其策略性地應用在我們設計的產品。
閱讀清單
資訊架構初學者手冊
資訊架構常是個由設計師、工程師、內容策略師共擔的任務。但無論由誰負責，資訊架構是一個獨立的專業，有自己的影響力、工具與資源，值得被投資。這篇文章將會討論資訊架構到底是什麼，以及它對於使用者經驗的價值。
資訊架構是什麼？
資訊架構學院這樣解釋資訊架構：「資訊架構是為了幫助人們了解周遭，並找到想找的，不論在線上或線下。」
換句話說，資訊架構是網站、應用程式或專案的結構，讓使用者知道自己在哪，以及想要資訊所在的相對位置。資訊架構可以是網站地圖、階層、目次、導覽列、元資料（metadata）。當內容策略師將內容分類並歸入不同的類別底下時，她就是在實踐資訊架構。當設計師畫導覽列，幫助使用者了解自己在網站的哪裡時，他也在實踐資訊架構。
我們在做資訊架構時，會問這些問題：
- 使用者在我們網站上的使用流程是什麼？
- 這個應用程式如何幫助使用者分類他們的資訊？
- 這個資訊怎麼呈現給使用者？
- 這個資訊能幫助到客戶，並引導決定嗎？
為了回答這些問題，資訊架構應該聚焦在幾件事上：目標受眾、網站相關的技術、我們要透過這個網站呈現的數據。
基礎理論
資訊架構在 1970 年代就開始了，那時網路、手機 app 和使用者經驗設計尚未崛起。其與 UX 實踐相關的理論包含：圖書管理學、認知心理學和建築學。
圖書管理學
圖書管理學可說是在發展「知識整理系統」，其中兩個特別有價值的學科為「編目」與「檔案學」。前者是建立元資料，將之歸納至內容，以利未來查找的過程；後者則是建立與整理充滿內容的檔案，以便未來持續編輯或移除，維護檔案的完整性的過程。上述兩者都能直接應用於使用者經驗上。我們利用易於使用的元資料，以及維護良好的檔案資料，來建立資訊架構。
認知心理學
認知心理學影響我們架構資訊的方式。
- 認知負荷：是指一個人在一段時間內可處理的資訊量。幫助我們避免在不經意間給使用者超出負荷的資訊量。
- 心智模型：是指人們在與一個網站或應用程式互動前的心理假設。當資訊所處的位置與使用者的心智模型相契合時，會讓使用者更容易發現這個資訊。
- 決策：決策是人們決定或選擇一個選項的認知過程。資訊架構可以透過在關鍵時刻提供資訊來幫助人們做出選擇。
建築學
現代資訊架構學的創始者 Richard Saul Wurman 是位視覺設計師與建築師，他認為資訊應該像建築一樣被架構起來，尤其是要有個堅實的地基。資訊架構應該建築在一個精確的、有意為之的架構上，以及以堅實的概念為地基。
任務與文件
常見的任務包含研究、創建導覽列、畫框線圖、設置標籤以及數據建模。
使用者研究與分析
資訊架構通常會透過易用性測試、卡片分類法、利害關係人訪談和使用者訪談來解專案的受眾。訪談與卡片分類是最常被使用的方式，以了解此用者如何分類眾多的資訊。我們可從中了解人們如何操作這些應用程式，人們會如何利用這個應用程式所給予的資訊，以及使用者在使用這個應用程式時的心理模型。
分析這些研究結果後，報告形式可以是試算表、推薦列表，甚至是使用者人物誌。
創建導覽列與階層
資訊架構師決定一個網站或應用程式的資訊如何呈現與被取得。要創建這樣的階層，資訊架構必須考量到使用者預期看到的，以及這個組織想要被看見哪些資訊。
舉例而言，如果一間公司想要將他們的「常見問題」與「幫助」頁面連結在一起，他們應該會將兩者置於「支援」類別。然而，研究卻發現使用者預期「常見問題」應該在「產品」類別。他們各有各的好處，資訊架構也可以考慮替代方案，像是把「常見問題」和「幫助」頁面都放在「產品」類別之下，這類型的決策說明了整個網站的層次結構，最常見的交付事項為網站內容網站地圖。
框線圖框線圖是呈現不同畫面間的關聯，以及網站在特定方面如何運作的最佳方式之一。它表現出使用者如何和這些資訊互動。擅長於視覺化思考的設計師使用框線圖來表現資訊階層也是很合理的。
設置標籤
當資訊架構決定資訊歸屬的類項，他們也要決定這些類項的命名。標籤設置能夠保證導覽列與階層能被很好的命名，讓使用者可以找到這些資訊。
知識分類與元資料
分類法是將所有事物分門別類成組的集合。對資訊結構師而言，分類法也記錄了我們如何將相似內容與資訊片段進行分組。大多數的資訊結構師會根據目標用戶的心理模型選擇一種或多種合適的分類法。他們會用元資料「標記」內容，這樣人們就可以根據假定的知識分類搜尋資料。舉例而言，服飾公司會考慮多種分類法，如：用材質、服飾類型或顏色。資訊架構會給一件襯衫標籤上棉或尼龍，或是襯衫、上裝或紅色。如此，心裡想著「我想要買件新襯衫」的買家就能輕易找到紅色的棉質襯衫。
資料模型
資料模型決定內容的型態，它展現使用者需求、商業邏輯與內部編輯方式。舉網站設計為例，新的資料模型常常需要與現存結構相配合，才能確保內容順暢轉移。
資訊架構與導覽列的差異
翻譯小補充：本文發表於 2014 年，雖然內文均以「網站」為主體出發，但對於資訊架構及導覽列的設計思考，一樣通用於今日我們每天都會接觸的 app 產品。儘管網站的資訊架構 (Information Architecture，簡稱 IA) 及導覽列 (Navigation) 兩者息息相關，但本質並不相同。引用〈Framing the Practice of Information Architecture〉文章所述：「導覽列僅僅是整體網站資訊架構內的冰山一角。」
網站資訊架構是什麼？
「網站資訊架構」即全站的訊息骨架，它由兩大要件組成：
- 內容和功能的識別與定義
- 根據上述，定義它們彼此關聯的層級組織、結構與命名用詞
資訊架構無法透過視覺介面呈現，但它確實影響進站訪客的使用體驗。透過以下要點，能幫助我們定義資訊架構：
- 清單：列出網站的內容以及所在頁面
- 評估：檢查文本精確性，例如措辭口吻、出現時機
- 整合：建立資訊的關聯性時，別忘了以閱讀者的角度整合
- 標準化：建立全站通用的專有文字表（詞彙檢索？）
- 關聯性：建立關聯性列表，以幫助建立網頁內部「補充說明」、「類似網頁」或是導覽列有更好的可發現性。
網站導覽列是什麼？
「網站導覽列」指的是在介面上讓使用者可點擊連結到網站資訊的元件。這些元件包含了資訊與功能的引導、麵包屑、篩選條件、相關連結等等，它的首要目標是協助使用者找到資訊及功能，引導他們走下一步。
因此，規劃每個導覽元件時都須思考以下決定：
- 使用性優先：使用者會多依賴這項導覽元件？
- 放置位置：該放在哪些頁面？放在頁面的哪個位置？
- 視覺呈現：哪一種樣式最能讓其被察覺，是切換頁籤、輪播、折疊選單或其他？
設計導覽列前，先定義好資訊架構吧
啟動新專案時，深入檢視並重新建構網站的資訊架構相當重要，藉由充分掌握內容的質量與其複雜度，妥善規劃導覽列與動線引導，讓開發流程變得精準又有效率。謹記，只憑「好看」所設計出的導覽列，終究無法滿足使用者需求的。
總覽資訊架構
註：原文提供豐富的案例圖片供讀者參考對使用者來說，好的資訊架構能減少認知負擔、幫助他們更快找到資訊、協助他們不被其他資訊干擾而專注在任務上、降低使用上的挫折以及需要客服支援的次數。很多設計能達到以上目的，例如 Wizard、導覽列、適時的 FAQ 連結，還有提供充足資訊的按鈕。另一方面，從商業的角度來看，好的資訊架構能增加客戶的瀏覽時長、增加客戶轉換率、增加黏著度、保持網站內容的簡潔、降低客服支援的成本。
為了達到上述目的，身為設計師我們需要經常自問：「設計用的語言是否能引起使用者共鳴、階層是否和使用者流程（User flow）相似」，並且使用者能否容易地返回上一步？」
資訊架構的設計中，搜尋及導覽列的設計選擇經常被討論，但兩者其實有不同的使用情境。如果一個商品名稱有多種別稱，例如洗手液、洗手乳、殺菌洗手乳等等，而難以提供簡易的導覽時，這時候就適合用搜尋，並且確保這些關鍵字有同個元標籤（metatag），如此以來使用者搜尋不同的關鍵字，都會出現最符合的結果。如果是新聞網站等內容龐大的產品，則適合用導覽列讓整體網站更容易瀏覽，適時的使用下拉選單去展開子類別，會讓資訊更簡潔、更容易消化。
評估資訊架構好壞很直接：看整體設計是否善用余白（white space）來提供適當數量的資訊。常見的測試方法有卡片分類（Card Sorting）、情境任務測試（Scenario Testing），執行時的線上工具則可參考 Treejack、answerthepublic.com 等。
最後，資訊時代（Information Age）讓我們正視設計處理資訊的必要，伴隨資訊爆炸成長，我們可以看到 90% 的數位資料是在過去兩年產生的、數位資料每年成長兩倍、33％ 的主管職認為資訊過載（information overload）影響其健康。而除了資訊過載的問題，資訊時代也帶來資料濫用、假資訊、資訊安全等議題。這些都是身為設計師需要思考、正視的議題。
如何建立任務流程（Task Flow）
選出使用者想完成的任務，並且是分拆之後可獨立的最小單位（例如：「繳稅」不是最小單位，「加入個人資訊」才是），之後才能將多個任務流程拼組在一起。
以「將一首歌加入歌單」為範例：
開始與結束
用圓點表示，開始是使用者表示其意圖，結束是此任務成功或因某原因而終止。
是與否的決策點
用鑽石形表示，將它當作系統在問自己問題：「你叫我將這首歌加入歌單，但這歌單存在嗎？」若是，直接加入歌單，若否，則創造一個新的。
複雜的獨立流程
不用畫出複雜如「創建新歌單」的任務，它本身就具有邊角案例（edge case）、錯誤狀態（error state）以及失敗案例（failure case），並非簡單幾個步驟的流程。
所以我們不會在這裡畫出該流程，如果囊括太多子流程，任務流程將變得過於複雜而難以讀清，只需要標示它有一套獨立而完整的流程即可。
另外，我們可能會想要在其他地方創建歌單，如果一個功能會在許多地方被呼叫，你應該要將它拉出來自行創建一個模組，發現哪裡不對勁時，你可以只改一個模組就好。
確保零死路
相信大家在產品中也都有過以下經驗：你想做 A，它叫你做 B，結果 B 做完之後它就完全忘記 A 這件事情了，這是非常糟糕的使用者體驗，所以要記得將所有死路都帶回流程圖之中。
當然，這是超簡略的任務流程，還有很多其他可以納入考慮的決策點，當提供更多條支線時，都會讓技術執行（implementation）更加複雜，這就是設計師需要進行抉擇的地方。
針對任務流程，細節非常重要，如果不思慮周全的話，你將會在設計後期面臨更多死路以及未被處理的錯誤情境。
最後，為什麼任務流程很重要？
理解
- 任務流程可以幫助我們理解將使用者從意圖到完成之間的複雜度
- 任務流程也可以幫我們發現潛在的死路，幫助發現被忽略的介面
- 由於任務流程是獨立於 UI 的，我們可以利用它去理解事物如何運作，而不是煩惱視覺上應該如何處理
溝通
- 與工程師溝通，讓他們知道你已經全盤思考過各種可能性
由於任務流程是幫助理解與溝通的內部文件，請根據你的團隊調整圖表方式，並沒有正確或錯誤的畫圖方式，重點是有效率地傳遞訊息。
觀看清單
如何讓選擇更容易
這份指南得以中文的姿態出現在設計師社群中，都要歸功於自告奮勇的轉譯團團員：Irene Chuang、吳健群、Lily Pai、Chi-Yu Tsai、QMO、Irene Kuo、Chunyi、Erin Huang 感謝你們！（此翻譯已經過原作者同意授權）👉 原文連結：The Guide to Design — The Architecture of Information
