互動設計師怎樣理解資訊架構？

 　　今天分享一篇互動設計進階教程，關於產品資訊架構的思考，這方面是互動設計師成長的一個關鍵點，也是互動設計大局觀的錘鍊基石，文章很有深度，值得用心學習。

　　這篇適合互動設計或者對互動設計感興趣的小夥伴們看。所以我就不解釋資訊架構是什麼了。今天寫一下產品資訊架構的思考。

　　任何產品都有資訊架構，或繁雜或簡單。在文中討論的時候，我大致把資訊架構分為兩種來例證。一種是比較簡單的資訊架構，例如大多ToC產品，微信、QQ音樂、騰訊視頻等;一種是比較複雜的資訊架構，例如大多ToB產品，營運類產品、客戶關係管理系統、業務支撐系統等。我把第一種稱為“輕架構”產品，第二種稱為“重架構”產品。

　　輕架構產品，需要提供給使用者一個簡單明了的資訊架構，讓使用者使用方便、體驗流暢。輕架構產品不能讓使用者迷路，不能帶來太多的學習成本，面對海量普通使用者要做到可用且效率高。輕架構產品可以通過做減法來聚焦。

　　重架構產品，需要提供功能完備、結構嚴謹的資訊架構，讓使用者能通過操作流程以使用各個功能。這樣的架構會帶來一定的學習成本，有些重架構產品甚至需要對使用人員進行培訓。重架構產品的使用者群體一般比較聚焦。重架構產品很難通過做減法來聚焦，而是需要對海量功能進行合理整合、靈活布局來聚焦核心使用者情境。所以對重架構產品，資訊架構更難，且更重要。

　　我在華為的設計工作包括輕架構產品和重架構產品。

　　設計輕架構產品的好處是輕鬆、愉快，使用者一般容易共感感知，甚至使用者就是你自己。痛點在於突破和創新。

　　設計重架構產品的好處是對互動設計師是一次磨練互動技能的好機會，資訊架構越複雜，對互動設計的要求就越高，鍛煉效果越好。痛點在於，重架構產品需要對業務的理解透徹，業務理解門檻高，海量功能不能做精簡，使用者是陌生群體， 需要使用者研究的支援才能理解使用者，資訊結構複雜導致互動設計難度高、錯誤率高、費力。設計重架構產品對全域觀的要求非常高。

　　下面我會根據Jesse James Garrett在“使用者體驗要素：以使用者為中心的產品設計”書中關於資訊結構的分類為維度，講述一下這些結構在使用者體驗設計的資訊架構設計中的作用，並會舉一些真實案例來討論如何使用這些結構以協助思考。

　　一、層級結構(hierarchical structure)

　　“在層級結構中，節點與其他相關節點之間存在父級/子級的關係。子節點代表著更狹義的概念，從屬於代表著更廣義類別的父節點。不是每個節點都有子節點，但是每個節點都有一個父節點，一直往上直到整個結構的父節點。層級關係的概念對於使用者來說非常容易理解，同時軟體也是傾向於層級的工作方式，因此這種類型的結構是最常見的。”

　　這是最常見的一種方式，樹狀圖、家族圖譜等，都是這個路線。這個路線蠻符合大自然的。這個結構相信大部分設計師都使用過，所以普通情境不做過多討論。這裡我想重點講的是層級結構的一種平衡式使用方式。

　　什麼是平衡式使用方式呢?

　　這個也是我最近想出來……首先我們知道，層級結構可以帶來兩種設計思路。

　　第一種，從上到下。從產品主要願景，一步一步細分到每個功能特性。

　　第二種，從下到上。從對使用者有價值的功能特性開始，一步一步往上反向推算到產品靈魂。

　　如果你讀了我上一篇關於設計流程的思考，這兩種方式就是戰略層、範圍層雙向的方式。

　　第一種很容易理解，戰略定了一個大方向，管理層傳達並指導，執行層輸出，一步一步分解任務直到任務量清晰、執行後得到產品結果。

　　第二種在重架構產品中使用的不少，例如一個給中國電信客服做的ToB產品，得先瞭解客服人員每天工作的任務流、操作流、所需模組集合，然後反向推算規整為一個一個功能模組，再反向推算形成一個系統。

　　最近我做重架構產品，第二種方法用的蠻多。是有點費腦子，但是嘿嘿，我研究生博弈論這門課是A+呢不怕不怕。lol

　　這兩種方式都有缺陷。

　　我舉一個近期的設計例子，是一個重架構產品，首先，產品的戰略層已經確認，換言之，從上到下是合理的思路;但是，產品過於複雜且功能特性多、合作部門跨度大，這時看上去從下到上才是正解。

　　問題就出現了。如果從上到下分解，到了底層功能特性太多且不合使用邏輯，就紊亂了。如果從下到上反向推算，功能特性有組合邏輯，但是到了頂層，產品靈魂又很難對上最開始戰略層制定的方向。

　　怎麼辦呢?再看一下這個圖：

　　我把戰略層的第一點，最高父節點，稱為大將;把底層眾多的功能特性稱為小兵。現在的問題是，大將下達指令，小兵淩亂;小兵自行組合，大將不能接受結果。所以我想，應該使用最高父節點和底層節點中間的那些點，我稱為隊長。隊長整理小兵，形成合力的隊伍，隊長對大將負責，在隊長層合力融合，最終完成軍隊的戰鬥力合成。

　　這就是我對平衡式使用方式的思考過程。從上到下不行，從下到上也不行，就從中間動手。我們把海量的功能特性與系統架構師確認好，然後通過使用者訪談對我們針對的目標使用者進行測試，讓他們對海量功能特性進行認知並分組。這時候，一個經過系統架構師和目標使用者驗證的中層結構就定好了。這時候“隊長”已經產生。此時，再思考戰略層對產品特質、靈魂的定位，順推合理的中層結構，這時，另一群“隊長”也產生了，他們是能實現戰略層(父節點)要求的。然後兩組“隊長”開始融合，從中間出發，對上對下各做調整和妥協，最後得到一個統一資訊架構。這個結果的重點是中層結構“隊長”。這個中層結構向上能滿足戰略層的要求，向下能滿足底層海量特性功能的實現。

　　問題解決了。

　　互動設計需要精進的一個點，就是解決複雜資訊結構。解決複雜資訊結構的過程和結果，會直接影響互動設計師的設計執行力和設計影響力。

　　二、自然結構(organic structures)

　　“自然結構不會遵循任何一致的模式。節點是逐一被串連起來的，同時這種結構沒有太強烈的分類概念。自然結構對於探索一系列關係不明確或一直在演變的主題是很合適的。但是自然結構沒有給使用者提供一個清晰的指示，從而讓使用者能感覺他們在結構中的哪個部分。如果你想要鼓勵自由探險的感覺，比如某些娛樂或教育網站，那自然結構可能會是個好的選擇;但是，如果你的使用者下次還需要依靠同樣的路徑，去找到同樣的內容，那麼這種結構就可能會把使用者的經曆變成一次挑戰。”

　　這樣的模式在現在的ToC產品越來越多(特別是遊戲娛樂產品)。它符合輕架構產品的瀏覽式形態。

　　有一種經典的區分使用者情境的維度是：任務式、瀏覽式。

　　任務式的特點：完成任務、快、準確、效率，例如查詢某個航班到達的時間。

　　瀏覽式的特點：片段、時間充裕、逛、發散、不聚焦、注意力吸引式，例如漫無目的地刷微博、看知乎。

　　自然結構很適合輕架構產品的瀏覽式形式。因為第一，重架構產品，ToB產品，如果使用者需要靠瀏覽靠猜來使用產品特性完成任務，那肯定結果是不好的，使用者會崩潰;第二，ToC產品一般就有兩種形態，如果不是任務式，那很有可能就是使用者在無聊，需要進入瀏覽式。

　　當然，完全自然結構的設計方式很少(不知道最近很火的秘密算不算)。

　　大部分ToC產品應該是任務式和瀏覽式並行的。所以自然結構，應該是綁定其他資訊結構來思考。

　　例如騰訊視頻。自然結構肯定是應該考慮綁定層級結構來思考。使用者進入視頻產品，可能的一種使用方式是，使用者心裡已經有一個明確的思路，找2014年美國電影看，所以使用者進入種類選擇，選擇電影，選擇美國電影，選擇2014年，然後進行瀏覽。這個可以算是先層級結構思考、後自然結構思考。

　　如果使用者是在家裡喝茶，想看看視頻，但是沒有任何目的，開啟了視頻產品，那他們就是進行瀏覽式操作，這個時候自然架構就產生價值。使用者在首頁進行無邏輯瀏覽，從首頁某個電視劇點入，看看詳情，不感興趣，從該電視劇的推薦點擊到下一個電視劇，然後不感興趣，然後從這個電視劇的主演想到他正在演出的一個電視真人秀，又跑去綜藝裡瀏覽。

　　每個產品對層級結構和自然結構的偏重是不同的。例如電商類產品，大部分人去天貓是有明確購買目的的，這個時候任務類操作會更重要;但是有沒有完全沒有購買目的，就是想去天貓花點錢或者找點折扣產品呢?肯定有，但是可能不如第一種使用者多。

　　所以在資訊架構設計中，我認為自然結構會是一個重要思考點，因為我們設計師要時刻記得，使用者不是理性的，他們很多時候的操作和想法會呈現隨機狀態。但是自然結構不是唯一的，必須有層級結構、線性結構、矩陣結構等其他資訊架構來配合和約束，才能讓這個產品的整體資訊架構完整、可用、有效。

　　三、線性結構(sequential structures)

　　“線性結構來自於你最熟悉的線下媒體。連貫的語言流程是最基本的資訊結構類型，而且處理它的裝置早已被深深地植入我們的大腦中了。書、文章、音像和錄影全部都被設計成一種線性體驗。在互連網中線性結構經常被用於小規模的結構，例如單篇的文章或單個專題;大規模的線性結構則被用於限制那些需要呈現的內容順序對於符合使用者需求非常關鍵的應用程式，比如教學資料。”

　　線性結構比較容易理解。更多呈現在協助文檔、產品故事講述等情境。就不多描述了。

　　這裡我想重點提一下就是線性結構是另外一種練習互動設計邏輯的方法。一個極端是複雜資訊架構(層級、自然、矩陣等)，另一個極端就是線性結構。如何用連貫的語言方式講述一個故事，但是不能進行跳轉和穿插，要一條線把思路講清楚，反而不是一件簡單的事情。

　　所以互動設計需要鍛煉兩個極端的資訊架構描述方式。一個是複雜資訊架構，充滿了層級、跳轉、補充、交叉;一種是極簡的線性架構，一根主線講清楚一個故事，甚至是複雜的故事。

　　四、矩陣結構(matrix structure)

　　“矩陣結構允許使用者在節點與節點之間沿著兩個或更多的“維度”移動。由於每一個使用者的需求都可以和矩陣中的一個“軸”聯絡在一起，因此矩陣結構通常能協助那些“帶著不同需求而來”的使用者，使他們能在相同內容中尋找各自想要的東西。舉個例子來說，如果你的某些使用者確實很想通過顏色來瀏覽產品，而其他人偏偏希望能通過產品的尺寸來瀏覽，那麼矩陣結構就可以同時容納這兩種不同的使用者。然而，如果你期望使用者把這個當成主要的導航工具，那麼超過三個維度矩陣可能就會出現問題。在四個或更多維度空間下，人腦基本上不可能很好地可視化這些移動。”

　　這個結構非常好理解。這裡想講的是，現在大部分設計團隊的KPI評估方式，就是矩陣結構。一方面，向業務線負責，以設計支撐產品商業成功;一方面，向設計線負責，以設計專業經驗支撐團隊專業影響力建設和技能成長建設。

　　設計師如何平衡這個矩陣結構管理方式，是設計師成長的關鍵點之一。

　　設計師做完一個產品，一定要回頭從資訊架構層開始往下想，這個產品資訊架構你做了什麼樣的創新、調整，產生了什麼價值。不要僅僅拘泥於做介面元素的規範、設計細節問題解決沉澱等。因為資訊架構，是互動設計大局觀的最好錘鍊基石。