一、功能結構圖
1定義
功能結構圖就是按照功能的從屬關係畫成的圖表，在該圖表中的每一個框都稱爲一個功能模塊。功能模塊可以根據具體情況分得大一點或小一點，分解得最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序。（百度定義）用通俗的話來說，功能結構圖就是以功能模塊爲類別，介紹模塊下其各功能組成的圖表。
2作用
- 產品概念設計的運用工具之一，能夠對不完全確定的設計問題或相當模糊的設計要求，以一種較爲簡潔和明確的方法表示。在繪製的過程中，能夠幫助PM思考並清晰產品的功能模塊及其功能組成；
- 梳理需求，以鳥瞰的方式對整個產品頁面中的功能結構形成一個直觀的認識，防止在產品需求轉化爲功能需求的過程中出現功能模塊和功能點缺失的現象。
3注意事項
在區分功能結構、信息結構圖、結構圖前，有一個重要的前提需要大家達成共識：軟件產品本身就是傳遞信息和提供功能的載體，完全絕對的信息類或功能類產品是不可能存的在，信息往往伴隨着功能，我們很難劃一條界限將兩者徹底分開。從某種意義上，信息傳遞甚至就是軟件產品最主要的核心功能。鑑於此，通常我們默認地把信息展示功能獨立了出來，作爲信息架構的一部分去思考，在產品功能結構時不考慮信息展示功能。
這裏舉一個信息與功能糾纏的例子更好理解，如微信的個人信息模塊（如下圖），“名字”字段在這裏既是信息又提供着修改設置的功能。
所以我們不難理解許多功能結構圖中出現了信息結構的要素，但由於功能結構圖的使用目的（即上文中的作用）要求我們專注於產品功能這個維度，在功能結構圖中我們最好儘量減少信息結構要素出現的可能性。
就用上面功能與信息糾纏的例子來說，在其功能結構圖中許多朋友會直接用“名字”來表示其功能點，畫圖人可能本人清楚，但看圖人就會產生疑惑：這個“名字”到底是指提供可查看名字的功能還是可查看並修改名字的功能。
在這裏介紹一個小訣竅，形容一個功能點時建議多采用“動詞+名詞”的語言描述形式，這種方式不僅信息傳達更加準確而且可以避免讀者不必要的困惑。如上面的例子中我們就可以把“名字”改爲“設置名字”或“查看並設置名字”來描述功能點。
4如何繪製功能結構圖
在實際應用時，產品功能結構圖通常在以下2種情況下繪製：
- 對未完成的產品在設計階段繪製，確定產品功能結構；
- 對已完成的某個版本的產品繪製，用於分析並傳遞該產品的功能結構；
（一）在產品的設計階段，如何挖掘並確定功能結構圖中的主功能模塊呢？
首先主功能模塊應該是產品在完整業務流程中的各個核心功能模塊，我們可通過業務流程中所涉及到的功能需求去提煉出主功能模塊，提煉完成後再通過業務流程走查一次，看是否有遺漏的主功能模塊。
舉個例子，假設我們參與了微信的早期功能設計，其產品初期定位是一款移動社交軟件，那麼其對應的核心業務可以簡化爲
這樣我們就很容易得出產品設計階段微信的主功能模塊，如下：
結合下面現有版本的微信功能結構圖對比一下，經過上百次迭代，其主功能結構幾乎沒有發生變化，我們不得不佩服其功能結構的拓展性；
當通過業務流程將主功能模塊確定下來後，再根據業務需求對其進行功能的詳細設計即可，在此就不再展開了。
2.對於已確定產品來說如何繪製功能結構圖呢？
對一款已確定產品繪製功能結構圖，最快捷的方法便是參考產品的Tab功能模塊找出產品主功能模塊，然後按照層級歸屬關係詳敘該功能模塊提供的下一級功能模塊或功能，如有必要，其顆粒度可一直細化到功能操作的描述程度。
那上圖“微信功能結構圖（V6.5.21）”的主功能模塊爲什麼不是“微信”、“通訊錄”、“發現”、“我”這四大標籤功能模塊？
在這裏作者希望傳達一個概念，結構圖中的主功能模塊不一定就是Tab中的標籤功能模塊，許多時候產品受限於移動端的空間限制，不得不把功能分爲3到4個Tab中，這是一種務實的妥協。當然正常情況下以Tab標籤名作爲主功能模塊的做法沒有錯，只是當產品功能複雜時，產品功能結構圖採用這種劃分有點粗糙。而繪製已確定產品的功能結構圖能夠幫助我們去挖掘這個產品的核心功能模塊，梳理產品的功能架構。我們建議作圖人可以嘗試脫離Tab標籤用自己的語言去挖掘並描述主功能模塊。
這樣說來我們就可以隨意將標籤功能模塊中的次級功能模塊劃分出來作爲主功能模塊嗎？
其實也不是，一款不管多複雜的應用其主功能模塊的劃分數量都不能太多（5-9個爲佳），一般情況下當對產品功能結構進行分析後，我們仍然會採用Tab功能模塊作爲主功能模塊然後對其下屬的功能模塊進行整理。只有當我們認爲某個次級功能模塊在業務上太過重要且產品價值較高時，我們纔可以將其劃分出來作爲一個單獨的主功能模塊。
這裏介紹一個小祕訣，當一個次級功能模塊反覆出現在不同的Tab功能模塊中的時候，我們就可以考慮將其拆分出來作爲主功能模塊，因爲這個時候意味着這個次級功能模塊在產品的業務流程中來說十分重要，而且這也可以讓我們的產品功能結構圖更加簡潔清楚。如上面“微信功能結構圖（V6.5.21）”中的搜索模塊就同時出現在了Tab中的微信功能模塊和通訊錄功能模塊。
最後如何確定功能結構圖中的顆粒度呢？
功能結構圖中的顆粒程度需要根據具體應用場景來定，由畫圖人根據需要自行把控即可。比如說在產品設計的過程中，功能結構的建立是設計者的設計思維由發散趨向於收斂的過程，剛開始的顆粒度一般比較大，可能僅涉及到某個功能模塊，隨着設計的不斷推進，功能結構圖的顆粒度會不斷細化，最終可以拆分至某個具體的功能操作。這裏作者將“微信模塊-個人對話”功能模塊作了細化，僅供參考：
二、信息結構圖
1、定義
指脫離產品的實際頁面，將產品的數據抽象出來，組合分類的圖表。
2、作用
- 幫助PM梳理複雜內容的信息組成，避免信息內容在展示過程中出現遺漏、混亂、重複；
- 作爲開發工程師建立數據庫的參考依據；
信息結構圖的繪製通常晚於功能結構圖，往往是在產品設計階段的概念化過程中，在產品功能框架已確定、功能結構已完善好的情況下才對產品信息結構進行分析設計。
在這裏，我們需要強調的是脫離實際頁面這個概念，在一些產品相關文章中，我們會看到作者將信息結構圖完全按照頁面的邏輯順序來進行分類組合，嚴格意義上來說，這種圖表不是一份合格的信息結構圖。
我們用微信的個人信息模塊舉例，如下圖所示：
其結構信息圖在這部分的繪製就需要脫離產品的實際頁面，如下：
最後需要強調的是：信息結構圖主要適用於產品信息構成比較複雜需要考慮優化的情況，如內容型產品（博客、web門戶網站等），產品的信息結構對於用戶體驗就十分重要，需要用信息結構圖作爲工具進行分析思考。
這裏作者簡單繪製了一下微信的信息結構圖作爲參考
三、結構圖
相較於功能結構圖和信息結構圖，產品結構圖的定義就很混亂和模糊了，爲什麼會出現這種情況呢？
一方面產品結構圖從文字理解上來說就容易讓人困惑：產品信息結構圖、產品功能結構圖不都可以簡稱爲產品結構圖嘛。
另一方面現有網上流傳的競品分析文檔、產品體驗文檔、PRD文檔有不少是由產品新人模仿前輩流傳出來的文檔模板來寫的。但讓人尷尬的是，有部分同學沒有進行細緻深入地瞭解。經常在一篇文章中，前面說是產品的功能結構圖，結果圖中是產品功能有，產品信息要素也有，沒有理解功能結構圖的定義。而後來的初學者又從這些文章中去了解學習產品功能結構圖、產品信息結構圖，導致惡性循環；
最重要的原因是：對於產品結構圖，產品從業人員這個羣體自身都還沒有達成共識啊。作者在網上搜了搜相關文章，對於產品結構圖大家的主要理解有3種：
- 大部分產品人認爲：產品結構圖即產品功能結構圖的簡稱，可能在產品沒有強調信息結構的概念時，有部分PM開始簡稱產品功能結構圖爲產品結構圖，之後便默認了這種稱呼，當出現產品信息結構圖後，概念就產生了混淆；
- 一部分產品人認爲：產品結構圖是綜合展示產品信息和功能邏輯的圖表；
- 少部分產品人認爲：產品結構圖就是產品信息架構圖。
在這裏，作者更認同第2種觀念：
產品結構圖是綜合展示產品信息和功能邏輯的圖表，簡單說產品結構圖就是產品原型的簡化表達。它能夠在前期的需求評審中或其他類似場景中作爲產品原型的替代，因爲產品結構圖相較於產品原型，其實現成本低，能夠快速對產品功能結構進行增、刪、改操作，減少PM在這個過程中的實現成本。
產品結構圖就是通過信息架構設計，將功能和信息以一種合理自然的邏輯，把功能結構圖和信息結構圖中的內容放入產品中的每一個頁面的結果。而現在許多PRD、競品分析中提到的信息結構圖、功能結構圖其實大多數都是同時含有功能和信息元素的簡化版產品結構圖。如下圖所示：
總結
在一款產品的設計過程中，功能結構圖是必須的，信息結構圖視產品和PM自身而定，通常我們初步確定了產品功能結構圖（產品功能框架）之後纔開始繪製產品信息結構圖。
在產品設計流程中，產品功能結構圖是產品概念化階段的初期輸出，產品結構圖是產品概念化的尾期階段輸出物，當產品結構圖完成後，我們對產品的基本模樣在心理就有了一個輪廓。同時以產品結構圖作爲繪製原型的依據，可以避免我們在產品設計中邊畫邊改，跳進死掐細節，不見森林的陷阱。