一、一個不可避免的問題
某天，筆者在pmcaff上看到了一個問題：
公司有個後臺產品，產品主要是滿足內部員工的使用，但是產品主要是以堆砌功能為主，加上公司並沒有交互，導致兩個問題：第一個問題是雖然是能用，但有點難用。第二個問題是由於功能的堆砌，給人很雜亂的感覺。 目前想先從產品的信息架構入手，進行產品的梳理，推動它的優化。但是問題來了，信息架構梳理的方法是很成熟的，但是好像評判“好”和“不好”的標準都很理論。想請教下大家，你們怎麼看待什麼是“好”的信息架構？
在產品生涯中，我們應該不可避免都遇到需要優化甚至重構的後臺系統。
原因一般有：
前期項目太趕，導致沒有好好的先規劃再落地。
上一個負責該項目的產品經理經驗不足。
-
因業務突然轉變，原有的產品和信息架構無法很好的 支撐新業務轉變落地。
當我們接受到優化、重構等任務，深知這是一個吃力不討好的活兒。幹好了，收益不是特別大，因為本來業務也一直在用這個系統，只不過難用一點而已。沒幹好，老闆和項目組對你信心下降，對日後的工作開展和晉升都會有阻塞。
二、關鍵是能設計出好的信息架構
有時候我們不能直接拿任務梳理出解決方案，而是要把任務轉化為完成該任務所需要的技能，再讓技能的輸出轉化為解決方案。
優化或重構系統需要很多技能，其中涉及到設計落地相關最重要技能則是“能設計出好的信息架構”。
對於產品經理來說，信息架構是什麼：產品經理的工作需要設計業務架構、產品架構和信息架構。一個企業的業務架構決定了產品架構，產品架構決定了信息架構，是一個遞進的關係。
後臺，是直面用戶前端的信息系統，該系統的架構是否合理則決定了用戶對該系統的直接感知。產品經理需要為後臺設計出一個合適的信息架構，讓用戶覺得好用。
而一個好的信息架構，應該可以能低成本與其他系統建立連接。
你應該對信息架構還有許多疑問，我們接著往下看。
三、信息架構和其悖論
信息架構本身的含義是：是一種連接信息供需方，讓其按設計好的流程進行操作，形成任務閉環的工具。
假如我需要在圖書館找一本書籍，那麼我需要找到圖書館的書籍目錄總綱，在此基礎上根據書籍名稱或分類等篩選查找，直到找到書籍的對應位置。在這個場景下，書籍目錄總綱則是充當信息連接的工具，並且我需要藉助該工具，完成查找書籍的任務。
隨著時代的發展，信息量也不斷的增加，人們查找信息的速度趨向緩慢甚至0效率，故而針對不同的場景，設計出合理的信息架構，幫助人們完成任務，提高人們依靠信息輸入進而解決問題的效率，是信息架構這個工具最重要的使命。
但是，信息架構本身存在悖論：很難（幾乎為零）設計出完美的信息架構，因為所有的定義和優化對於任何人來說都不能是最完美最合適的。
1、對於運營人員來說，希望做完活動後，能馬上看到營銷效果數據，那我們是基於在營銷系統上實現“營銷效果數據查看功能”，還是把這些數據當做是企業的核心數據資產，統一放在數據中心處查看呢？還是兩邊都做？
2、對於資料管理人員來說，採購人員負責供應商資料和商品資料的新建維護，那這個資料是放在採購系統裡面還是系統資料中心統一管理處？
3、假設一張單據需要重做功能，該功能的按鈕文案通常叫“重做”。但產品經理考慮到單據的邏輯後，將文案定義為了“作廢並新增”，也許是一個更好的方案。
你認為的“信息”和我認為的“信息”真的是在同一層面上嗎？
即便面對同一事物，不同人基於各自所處的環境和思維層面不一致，總會導致存在認知和理解上的差異。
所以，用戶抱怨“系統不好用”、“功能太繁雜了”等原因，本質是因為不同的人對信息的理解都不一樣，我們沒辦法從根本上上解決這個問題，世界本來就是複雜的。
不過不要太悲觀，基於對信息架構悖論的認識，我們依舊可以給出一套行之有效的方案：找到該場景最合適的信息架構框架，並且能隨時迭代這個架構對人、對信息、對任何內外部要素的連接能力。
信息架構一直髮揮著連接信息、連接人的作用，只要能把信息架構的這個能力不斷提高，那麼這就是一個好的信息架構。
注重信息架構的連接能力，這樣在不同的階段，我們都可以設計出“好”的信息架構，為不同的用戶去提供一個好用的後臺系統（或者是任何系統）。
如果一個後臺十分龐大，但用戶依然很清晰後臺架構，並且覺得很合理，專業人士感到高效，小白不會迷失方向而能快速上手，這就是一個好的信息架構設計，因為這個信息架構很低成本就和不同的人群系統連接起來了。
希望到這裡可以解開你對信息架構是什麼，怎麼才算一個好的信息架構的疑問。
直到這裡依然是概念階段，我們來看看如何設計。
四、怎麼設計連接能力強的信息架構
要設計連接能力突出的信息架構，需要從情景、內容、用戶三方面去考慮完整。大部分情況下，我們都是直接按照自己的設計美感輸出優化方案，最終效果總是不盡人意。
4.1 考慮情景
一個項目是由戰略、文化、市場、技術、資源、政治和經濟環境各種組成。
理解公司的戰略目標，商業目標，目標的變化可能會影響：我們從一個進銷存系統變成一個ERP系統，客戶管理頁面迭代成一個CRM子系統。
理解所處行業、市場、商家的信息：如果是新興或科技行業，可以比較大膽超前的去設計架構，但如果是傳統行業，信息化程度本來不高，需要有漫長的發展週期，那麼架構需要保守，可用。
理解能提供的資源和技術上限：公司給予這個項目的資源和技術支持到什麼程度，如果是戰略級別項目，可能會配備頂級開發，最後迭代為一箇中臺項目。
理解其他如政治、經濟環境等因素可能會造成的影響：如果項目是十分受經濟波動和政治因素影響的，那麼也需要提前考慮會影響信息架構，避免犯重大錯誤，例如製藥的流程違規導致違法。
仔細看這些都是產品負責人所需要的技能，所以從另外一個角度來說，比較好的信息架構只有產品負責人能設計出來，其他人沒有辦法去做，一是沒有足夠的信息，二是自身技能還沒點滿。
4.2 考慮內容
內容是該信息架構相關的行業的所有信息。
內容所有權：不同信息的所有權所屬不同。例如優惠券的信息則屬於運營部門所有，但是活動效果卻是所有部門公有的，這裡面涉及到數據權限的設計、數據效果的展示工作。
內容屬性：內容屬於開放性還是非開放性的，屬於哪些維度，可維護還是不可維護等。很多後臺的操作都需要考慮到權限問題、操作閉環。
技術：關於數據庫、大數據、數據格式等體系知識。特別是對於後端產品經理來說，需要對數據庫知識、UML知識有一個瞭解。
數量：內容的數量有多少？需要放在哪裡才能存儲？客戶上傳的短視頻，企業到底要存儲多久呢，以後是否有法律風險需要調回查看？一個企業的備案信息，國家通常會保留很多年。
動態性：內容是如何變動的 ？變動的速度趨勢是怎麼樣？增長率有多少，不同的內容的生命週期是怎麼樣的。用戶的畫像是否會隨著數據和技術的發展，更加完善？用戶的畫像什麼時候需要更新，什麼時候需要重新評估 ，什麼時候需要丟棄？
4.3 考慮用戶
用戶即使業務的目標群體，不過多贅述。
受眾：用戶群體，一個龐大的系統，有一個主群體，然後有很多分散的小群體（部門）。C端的產品一開始可能只有一種目標群體，但隨著業務的拓展自然會瞄準更多的用戶群體。B端的系統是分別給一個企業不同的部門用的，不用的部門又有崗位的區分，每個群體絕對有很大差異。
任務：每個大群體、大部門、小組織、個體需要完成的任務流程。多考慮功能的閉環和異常流程，考慮這個工作完對個體有什麼影響，是否會讓他舒暢的完成每一次工作？考慮業務流程實現後對該企業有什麼影響，是否能帶來可量化的業務價值？
需求：要考慮真正的需求本質，搜索和查找不是目的，完成任務/工作閉環結果才是。用戶不在意對接的人工智能客服還是人工客服，能快速解決他的問題就可以了。
搜索和查找：大量的搜索和查找，怎麼樣才能優化效率，是否有完善的設計方法論？不同場景的搜索查找都有一定的設計方案，用戶也一定有自己的搜索習慣，系統是去迎合還是打破？
整體體驗：B端產品也有不同於C端產品需要的用戶體驗。產品體驗可以分為兩種：第一種我很懂你，你可以隨便進行怎麼做，整體過程感覺很好，但結果不一定保證（2C）。第二種是你只能按照我的要求做，但是我可以給一個很好的結果你（2B）。
不屬於你的用戶：考慮不屬於我們的用戶，即要考慮他們為什麼覺得不好用 ，覺得其他競爭對手的產品好用。
設計者應該明確上述三點的定義，並且把這三點連接起來，由此才能設計一個連接性強的系統。這需要大量技能組成和實踐經驗，所以設計信息架構這個技能並沒有那麼簡單。
不過對於大部分同學，先完善對信息架構的認知，再把認知轉化為思考，慢慢運用到實際工作中，已經可以產生比較大的幫助。
五、總結
1、在產品生涯中，我們總會遇到優化或重構系統的問題。這類型問題通常吃力不討好，特別是在大公司。
2、遇到棘手的任務時，需要把任務拆解成完成該任務所需的產品技能，快速習得該技能，輸出解決方案。
3、好的信息架構，應該可以能低成本與其他系統建立連接。但是信息架構存在悖論，本質是因為人與人之間認知差異造成的。即便沒辦法設計完美的信息架構，但是它能階段式的解決問題，這就足夠了。
4、在優化或者重構系統之前，先思考情景、內容、用戶，並且把三者連接起來，隨時記著信息架構最重要的是它的連接能力。
5、最重要的是：問題依舊存在，解決問題的工具也會存在，我們要接受不完美，但只要有效。
你當初是怎麼去優化那個“看著都煩”的後臺系統的呢？歡迎留言分享。
文章部分知識點由筆者閱讀《信息架構：超越 Web 設計》總結而成。
本文由作者@德拉克馬 在PMCAFF社區發佈，轉載請註明作者及出處。
PMCAFF社區主頁：https://s.pmcaff.com/p7dUA
閱讀更多 PMCAFF產品經理社區 的文章
