㈠ 產品入門，如何繪制產品功能結構圖和產品信息結構圖
下面是筆者通過實踐和資料整理對這兩個結構圖進行定義區分，並輔以實際demo分析闡釋：
一般在實際工作中，一個產品需求從創意、構想到最終輸出給設計、開發，不一定會用到這兩種圖，視情況選擇使用。如要有要求先輸出產品方案時，還是建議繪制「產品功能結構圖」和「產兄散品信息結構圖」，方便直觀地讓開發人員了解該產品的架構，同時自己參照結構圖繪制產品原型時也避免模塊早塵仿和功能的遺漏。
一、產品功能結構圖
作用 ：梳理產品架構功能點。
說明 ：我們繪制產品功能結構圖一般是在原型繪制前，所以大多不以頁面為模塊去羅列，而是以功能劃分模塊，以產品的主要功能及其他圍繞主要功能而展開的下級功能點進行羅列。
一般做競品分析時會倒推已經成型的產品來練手，此時需要反復使用軟體，列出其主要功能，涉及的功能細節需要不斷測試得出。
在自己構想一個新的產品時，也需要大量使用同類或者有借鑒意義的產品，在繪制功能結構圖的過陸纖程要結合過往或者同類產品經驗羅列功能模塊、細化功能點。
功能和信息的概念有時比較模糊，如果想要更清晰的讓自己的表達更清晰可以採用「動詞+名詞」的形式對功能點命名，比如：登錄/注冊賬號；查看/取消收藏等。
操作過程 ：
我們在繪制功能結構圖之前，要先梳理主要功能邏輯，下面是筆者參照B站功能模塊拆解的主要功能：
在主要功能的基礎上添加下級功能和細節點，產品功能結構圖就繪制出來啦！
如下圖：
二、產品信息結構圖
作用： 梳理系統頁面的模塊功能顯示信息，是繪制原型的基礎，信息結構圖類似數據表結構設計，揭示了需要哪些數據，這些數據需要有怎樣的元素組成，才能達到每個功能模塊需要展現的內容表達。如果說功能結構圖是產品的功能抽象，那麼信息結構圖則是產品的數據抽象。
說明： 產品信息結構圖羅列了產品需要的信息欄位，是在我們繪制原型前構想如何布局頁面信息的依據。在C端產品中對產品信息頁尤其重要，為避免原型繪制時遺漏，此時需要繪制產品信息結構圖窮盡頁面內容。信息結構圖中同一個對象的信息出現在多個頁面是非常常見的事情。
例如個人簡歷，在招聘官使用招聘網站時，姓名、性別、年齡、職位、工作時間等關鍵信息既會出現在候選人的列表頁，也會出現在候選人的詳情頁，還會出現在搜索結果頁等等。
操作過程 ：
結合功能點，對設想的功能進行主頁面布局。
根據需求調研、競品調研報告、結合自己的產品經驗確定具體功能模塊布局:
總結 ：
1.功能結構圖，關鍵詞是功能，是功能的結構化表達；
2.信息結構圖，關鍵詞是信息，是信息的結構化表達；
互動作的細節不用體現在產品功能結構圖和產品信息架構圖中，比如頁面布局細節、交互手勢、動畫效果等，屬於交互設計的范疇。
繪制產品結構圖時，你就要想像這是你產品的最終形態，每個頁面要有哪些功能和數據，類似於開發做的不同靜態頁面，展現在你面前的就是產品的雛形了。
㈡ 互聯網的「產品結構圖」應該如何繪制
這位兄弟想問的可能是信息架構，科普一下： （Information Architecture），簡稱IA，來源於早期IT軟體開發的架構設計，現在互聯網時代多用於對網站、產品在開發前的結構設計，能夠給高層或產品經理帶來最直觀的未來既視感，也可提供給架構師們參考和進行下一步工作分解等。教程和圖示網上一找一大堆，方法多種多樣，因人、公司、業務而異，復雜程度參差不齊，不一定最專業的就是最適合你或你的團隊的，所以無法給出具體教程，這里我簡單介紹個小方法供參考： 1.確定你要做的產品的所有功能將所有功能一一列在紙上，確定產品的核心功能（這屬於設計方法了，這里不鋪開講目標導向），並以核心功能為主，將每個功能要實現的目標和可能的業務邏輯大概羅列在下面。 2.確定產品的模塊一個或多個功能可能會組成一個模塊，便於架構師、設計師、開發工程師等幾乎所有干係人理解，更便於用戶使用，將功能用線條跟模塊進行組合。 3.確定子模塊或子功能某些大功能或大模塊可能會由多個子功能\模塊組成，將他們依次用線條連起來，需要注意是將主模塊、子模塊\功能依優先順序或從屬關系畫成樹狀圖。需要注意的是，某些子功能可能和其他模塊進行交互，或多入口，或各種各樣的業務流，沒錯，都把他們用線條連起來，無非就是換個顏色的線條（通常會帶箭頭）。可以用Mindmanager或OmniGraffle等，工具不限，ppt也可以做到。 4.大功告成接下來你就得到了你產品的第一版IA（之所以說第一版就是因為肯定要迭代）。 沒錯，就這么簡單，這就是IA的製作方法，只是其中會涉及到很多設計方法論如目標導向，會涉及到用戶使用場景，還有Taskflow、Pageflow等，這些都是擴展知識點。 另外最重要的一點，這個IA不是一次完成就ok了，應該是個閉環，每次的討論、評審，或戰略變更、業務變更，市場情況變化，產品經理和公司高管肯定會對產品做調整。 當然IA的製作方法多種多樣，一定要結合自己公司業務特點、團隊合作方式等，定製出最適合自己的方式，才能起到作用。 希望能幫到你。
㈢ 產品設計-(3)產品結構
基於前期的需求分析以及市場競品分析等為依據，將各個需求點以某種邏輯系統化的組織起來所形成的立體結構。
基於該結構，可以順利的引導用戶行為或將各類信息進行順暢的流轉。
產品結構圖是綜合展示產品信息和功能邏輯的圖表，簡單說產品結構圖就是一種將產品原型以機構化的方式展現的圖表，結構內容也如同產品原型一樣，從頻道到頁面，在細化頁面功能和元素。產品結構圖是產品經理設計原型之前的一種思路梳理的方式，通過產品結構圖可以對產品結構一目瞭然，也方便思考。一般使用思維導圖工具。
如：微信產品結構圖
小結：我們做的產品結構的構建，就是把原本無序的各個需求點以某種結構的方式展現出來。產品結構圖實際上就是一種結構化的產品原型。這樣做的目的就是梳理產品結構邏輯，更清晰知道產品有幾個頻道，頻道下面有沒有子頻道或者有多少頁面，這些頁面又有哪些功能模塊，這些功能模塊又有哪些元素。
1.人民了解產品的第一印象，結構是否清晰也代表著用戶理解的難易度。
2.產品結構的穩固與否，也代表著在增加和減少功能模塊時的難易程度。
微信的結構tab一直沒有改變，結構比較穩固。
思考：我們應該以什麼維度去設計產品的結構？用戶需求？功能相關性？定位？戰略？
《用戶體驗要素》講解了幾個典型的信息架構模型：層級結構、自認結構、矩陣結構、線性結構。
1.層級結構
書中描述：在層級結構中，節點與其他相關節點之間存在父級/子級的關系。子節點代表著更狹義的概念，從屬於代表著更廣義類別的父節點。不是每個節點都有子節點，但是每個節點都有一個父節點，一直往上直到整個結構的父節點。層級關系的概念對於用戶來說非常容易理解，同時軟體也是傾向於層級的工作方式，因此這種類型的結構是最常見的。
特點：結構清晰易懂、有較高的操作效率、擴展性強。
在使用層級結構時，需要注意層級的深淺和寬窄。 寬而淺的產品架構和窄而深的產品架構，各有優勢和劣勢，具體使用哪一種產品架構，關鍵是要結合自身產品的定位、業務特性和用戶特徵及使用場景來進行取捨和判斷。
產品結構設計時，理論上不要超過3層。
2.自然結構
書中描述：自然結構不會遵循任何一致的模式。節點是逐一被連接起來的，同時這種結構沒有太強烈的分類概念。自然結構對於探索一系列關系不明確或一直在演變的主題是很合適的。但是自然結構沒有給用戶提供一個清晰的指示，從而讓用戶能感覺他們在結構中的哪個部分。
如果你想要鼓勵自由探險的感覺，比如某些娛樂或教育網站，那自然結構可能會是個好的選擇；但是，如果你的用戶下次還需要依靠同樣的路徑，去找到同樣的內容，那麼這種結構就可能會把用戶的經歷變成一次挑戰。
特點：鼓勵人們探索、提高產品趣味性、常見在游戲、咨詢類產品
3.線性結構
書中描述：線性結構來自於你最熟悉的線下媒體。連貫的語言流程是最基本的信息結構類型，而且處理它的裝置早已被深深地植入我們的大腦中了。書、文章、音像和錄像全部都被設計成一種線性的體驗。
在互聯網中線性結構經常被用於小規模的結構，例如單篇的文章或單個專題；大規模的線性結構則被用於限制那些需要呈現的內容順序對於符合用戶需求非常關鍵的應用程序，比如教學資料。
特點：如同看電影一般，一個場景向一個場景推進；引導用戶跟著走，目的性較強。
4.矩陣結構
書中描述： 矩陣結構允許用戶在節點與節點之間沿著兩個或更多的「維度」移動。由於每一個用戶的需求都可以和矩陣中的一個「軸」聯系在一起，因此矩陣結構通常能幫助那些「帶著不同需求而來」的用戶，使他們能在相同內容中尋找各自想要的東西。
舉個例子來說，如果你的某些用戶確實很想通過顏色來瀏覽產品，而其他人偏偏希望能通過產品的尺寸來瀏覽，那麼矩陣結構就可以同時容納這兩種不同的用戶。 然而，如果你期望用戶把這個當成主要的導航工具，那麼超過三個維度的矩陣可能就會出現問題。在四個或更多維度的空間下，人腦基本上不可能很好地可視化這些移動。
特點：可以同時滿足不同用戶；承載的信息更多；
小結： 具體使用哪一種產品架構，關鍵是要結合自身產品的定位、業務特性和用戶特徵及使用場景進行判斷。
一個好的產品結構所需的要素： 1.與產品目標和用戶需求相對應 2.具有一定的可擴展性 3.層級深度適合 4.用戶理解
㈣ 一張圖講清楚產品架構，手把手教你畫產品框架圖
什麼是產品架構圖
產品架構圖是產品經理用來表達自己產品設計機制的一張概念圖：
它將可視化的具象產品功能，抽象成信息化、模塊化、層次清晰的架構，並通過不同分層的交互關系、功能模塊的組合、數據和信息的流轉，來傳遞產品的業務流程、商業模式和設計思路。
由於產品架構圖通常用於比較復雜的產品項目中，目前介紹產品架構圖的相關書籍和資料極少（尤其是入門級別的資料很少提及），卻是設計復雜產品時不可或缺的文檔之一。
沒有資料的探索過程漫長且沒有方向，在終於有所沉澱後，我花了四周寫下了這篇總結，希望可以為你繪制產品框架圖時提供簡明的參考。
為什麼要畫
梳理自己對產品方向的判斷：
思考這張圖如何設計的過程，也是幫助你梳理「半年內自己的產品該往何處去、需求應該如何分期和落地、和其他產品的依賴&競爭關系是什麼、未來的可拓展性在哪裡」等問題的過程。
為技術&運營的輸出形成支撐：
當這張圖被設計出來後，按照產品架構圖的結構和路徑，項目的里程碑（RoadMap）就可以被清晰的拆解出來，同時項目成員也可以根據這張架構圖產出運營計劃、技術系統架構方案等強依賴產品方向的方案。
讓他人可視化的理解你的產品架構：
能較為清晰簡單的呈現自己的思路、明確自己的產品邊界、指明發展的方向，常用於在項目規劃或項目總結中進行演示，幫助不了解你的產品的人快速的建立對你的產品結構、功能、復雜度的認知。
何時需要畫
建議在復雜項目開始前寫：
當你要開始設計一個系統性、完整的需求時，如果跳過畫產品架構圖的步驟，直接開始畫原型、寫PRD、kick off，就很容易發生「改了又改」、「做了一版需求然後又推翻」的情況。
但「種一棵樹最好的時間是十年前，其次是現在」：
如果你的項目已經進行到一半，自己卻從未產出過這張圖，那麼就從此刻開始，按照下文的步驟嘗試為自己的產品產出一張產品架構圖吧。
如何畫
之前我們分享了【AR最全乾貨及資料】設計AR產品，你一定要看的總結 ，你可能對AR相關的背景知識已經有所了解。為了分享的延續性，我們來做一個大膽的假設*：
假設你是 微信-掃碼功能 的產品經理，有一天老闆把你叫到辦公室，一番鼓勵後拍著你的肩對你說：
「蘋果發布會看了沒？蘋果這么重視對AR能力的支持，我們微信也要趕緊把AR功能做起來。這是個Allen（張小龍）很重視的項目，你回去好好設計一下，明天來跟我過方案。記住，要能夠一炮打響，全民參與喔！」
啊，張小龍級別的項目啊！明天就要出方案，怎麼辦 ？
畫前准備
列出問題域
在需求初期，產品經理得到的往往只是一句比較模糊的需求描述，它們可能來自於老闆、運營或用戶。
直接把這句話作為核心產品功能是不恰當的，合理的做法是先把這個產品所有的問題域列清楚。
「問題域」是指自己的產品能夠解決的所有問題的空間集合。從核心需求出發，將所有當前需要解決、未來可能要解決的問題放入產品框架的范圍，能夠幫助你的產品架構圖擁有更高的可拓展性，在後續具備迭代和優化的空間。
以微信AR的需求為例，問題域是這樣一個集合：
詳細操作步驟：
1. 找到收到的需求中，跟產品形態、產品目標相關的詞句，去列出「XX的流程會是什麼樣」、「XX該怎麼達成」之類的問題，直到如果這些問題解決，能夠實現核心需求的方向和業務目標。
2. 去逐次尋找這些問題需求被解決的過程中，是否有其他要先解決掉的問題、或者其他跟業務相關的問題能夠被解決/改善。
3. 按照層級去羅列出所有的問題，並附上自己的初步回答，從而形成一個初步的、自己的產品能夠解決的「問題域」。
確定產品方向
在經過問題域的羅列後，你應該能夠得到一個模糊的產品方向和功能范圍。把這些問題域的答案抽象總結成一個確定的產品需求。
以微信AR的需求為例，根據問題域，我們發現需求不只是掃碼組件增加AR識別能力這么簡單，整個需求里需要引入廣告主的角色，並且需要和廣點通、騰訊開放平台等團隊合作。最終得到的產品方向描述是這樣的:
詳細操作步驟：
問題域的環節非常發散，這一步需要回歸基礎，把模糊的需求補充、拓展和翻譯成一個在商業模式和用戶體驗上能夠形成閉環的產品需求。
1. 核心需求確定：我的產品核心解決的是哪批用戶、哪個用戶需求？
2. 產品目標：如果以一個數字指標衡量我的產品，它應該是什麼？
3.用戶場景：核心需求基本的產品形態、用戶使用的路徑是怎樣的？
清晰的業務流程
這一步需要根據核心產品需求和問題域的答案，畫出簡單的業務流程。業務流程是產品設計中常見的圖表，繪制方法就不再多做說明。
以微信AR的需求為例，從廣告主准備AR互動，到用戶在前台使用攝像頭參與互動，整個業務流程如下:
著手繪制
搭建基礎框架
基礎的產品框架脫胎於業務流程，但相比業務流程，更加註重產品功能的枚舉、功能模塊之間的分界。
詳細操作步驟：
1. 對照業務流程，根據自己設想的產品機制、基本產品形態和用戶的使用路徑，列出需要的頁面&功能&模塊等前後端邏輯。
2. 將剛剛得到的多個流程圖中所有功能類似或者范圍有包含關系的機制/功能放在一起，以模塊化的形式形成一張簡單的矩陣圖。
3. 將明顯是同一個產品范圍、同一組產品功能的模塊放在同一層級，得到一個基礎的產品框架。
明確架構分層
一個具備前後台關系的產品架構圖至少分為三層：用戶感知層（在何種場景下通過何種方式觸達用戶）、功能模塊層（通過哪些功能模塊實現產品的核心功能、和哪些外部平台功能有信息交互）、數據層（產品的數據從哪裡來、產品的數據沉澱到何處去）。
在上一步進行簡單分層後，我們已經得到一個初步框架，但是難免會有分層不明確的問題。此時需要按照兩種維度來處理架構圖的層級：不同信息層級的邊界、同一層級內模塊和模塊的邊界。
1. 處理不同信息層級的邊界：
架構圖的層級表達的其實是信息之間的流轉關系，不同信息層級之間一定是有邏輯關系的。
其中用戶感知層和數據層通常可以簡化為一層（用戶端的功能表達往往邏輯簡單、數據的來源問題則不是自己產品的核心功能），而功能模塊層則需要按照自己產品的邏輯去將功能模塊層內的主要模塊變成新的層級。
2. 處理同一層級內子模塊的邊界：
各層次之間雖然相關，但同一層次內的子模塊之間一定是互相獨立、界限分明的（常常對應著不同的開發團隊和系統應用）。將解決不同問題的功能拆分成兩個子模塊，做到一個問題只在同一層解決，避免牽一發而動全身的情況出現。
3. 明確產品間的邊界：
產品邊界對於開發設計系統架構、業務間的合作模式都非常重要。用不同顏色標識清楚產品框架中，各個部分所屬產品的邊界，通常其中屬於自己團隊的部分用亮色表示。
加入信息流轉機制
產品架構圖在表達產品的核心功能外，也應該體現信息流動的路徑：當前層級數據的交互形成產品功能，產品功能又產生新的數據，從而推動下一層級的功能運轉起來。
如果當前產品的主要使用角色只有一個，則只需要用箭頭標明模塊間信息流動的方式即可。如果當前產品會涉及的主要角色比較多，則需要用不同顏色的線條將他們和各個模塊之間的信息交互關系外化出來。
最終檢查
一張好的產品架構圖，應該具備以下特點。
清晰的模塊功能邊界
功能經過抽象，做到標准化、互相獨立
上下游產品功能邊界清晰，架構分層明確合理
具備迭代優化的能力
記得不斷根據你的產品的發展情況來更新產品架構圖，每次修改的過程對提升產品架構能力的幫助非常巨大。
————————————————
原文地址：https://blog.csdn.net/pmcaff2008/article/details/78111282