各種結構介紹圖解（一文說清楚3種結構圖）

2023-10-04 02:08:18 2

在畫原型之前，功能設計是一個很關鍵的步驟。在這個步驟中，需要對功能進行拆解，梳理其邏輯和流程，梳理功能結構和產品邏輯。這其中，除了常用的流程圖之外，各種結構圖也是各位產品經理需要經常繪製的圖表之一。這篇文章，作者分享了三種結構圖的繪製方法，希望能對大家有所幫助。
需求的分析、梳理、溝通、討論與表達，是產品經理每天在做的、耗費很多精力的事情。如何更有效、更精準地完成這些工作是產品經理的必修課。
圖，作為一種比文字更直觀、更真實的表達方式，可感知性非常強，在產品經理的工具箱中佔據著重要地位。
俗話說：有圖有真相，一圖勝千言。
今天我們就來看看，與產品經理的工作密切相關的3種結構圖：功能結構圖、信息結構圖、產品結構圖。
一、功能結構圖
功能結構圖在百度中的定義是：功能結構圖就是按照功能的從屬關係畫成的圖表，在該圖表中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分得大一點或小一點，分解的最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序。
用通俗的話來說，功能結構圖就是以功能模塊為類別，介紹模塊下其各功能組成的圖表。功能結構圖一般不涉及具體的欄位信息，只強調功能的邏輯關係。
功能結構圖主要用於新產品/新功能的概念創意階段或者對競品拆解/已有產品整理而進行繪製。它主要幫助產品經理基於對業務的理解進行功能的梳理，為下一步產品架構設計、撰寫需求文檔、繪製產品原型圖提供基礎。
具體來說，功能結構圖的作用有：
產品概念設計的運用工具之一。在繪製的過程中，能夠幫助產品經理思考並清晰產品的功能模塊及其功能組成。梳理需求。以鳥瞰的方式對整個產品的功能結構形成一個直觀的認識，防止在業務需求轉化為功能需求的過程中出現功能模塊和功能點缺失的現象。
繪製功能結構圖最重要的前提是對業務的深入理解，只有對業務有了足夠清晰的認識，才有可能繪製出合適的功能結構圖。
有人說，功能結構圖主要就看都有哪些Tab，由此逐步深入展開，最終整理形成功能結構圖。
還有人進一步補充說，當一個次級功能模塊反覆出現在不同的Tab功能模塊中的時候，我們就可以考慮將其拆分出來作為主功能模塊。
但實際上，無論是我們要著手一個新產品/新功能的相關工作，還是對競品產品/功能進行拆解分析，首先要明白一點：功能結構圖是產品經理開啟上帝視角站在業務角度鳥瞰產品功能體系的機會。
這裡需要重點關注的是「業務角度」。
產品/功能，均是從業務中來，是實現業務邏輯/商業規則的介質。作為體現這一介質的全局性文檔，繪製功能結構圖當然是站在業務角度來進行梳理，而不是站在產品角度，所以上面提到的功能結構圖主要看Tab等說法都是不恰當的，方向反了，或者說因果反了。
鳥瞰，是對基於業務而得來的功能體系的鳥瞰，不是對產品體系的鳥瞰。在這一點上，我們常常不經意地犯錯。
當拿到一項新產品/新功能的產品工作時，不是從梳理業務開始，而是常常一上來就開始分Tab。這樣做輕則導致返回來修改工作量增大延誤時間，重則帶偏了產品方向使產品找不到目標用戶。
對於新產品/新功能相關的工作，我們尚且如此，而對於競品的拆解/已有產品的整理而需要繪製功能結構圖時，就更加容易從已有的產品出發了。
實際上，對於競品拆解/已有產品整理，我們可以從已有產品出發去了解產品，按照產品結構梳理產品功能去理解業務，而最終還是要在全面掌握了業務邏輯/商業規則以後再重新站在業務角度來梳理出功能結構圖。
在這個過程中，從產品結構開始著手是幫助我們快速理解業務的一種方法而已，切不可當成了最終結果。
前面我們提到「合適的」功能結構圖，那麼我們如何來判斷繪製的功能結構圖是否合適呢？
一般來說，除非公司和產品有重大戰略上的調整，否則其主要功能模塊不會發生變化，常常是一些分支上的增減。這樣的功能結構圖擴展性很強，能夠在一段比較長的時間內適應發展的需要。
但如果是不合適的功能結構圖，遇到的最大的問題是主要功能模塊或次一級重要功能模塊的重大調整，常常在經歷了一個比較短的時間內就感覺到功能結構框架已經不適應發展的需要了。
這種情況其實是一開始就沒有想清楚業務的重點、優先級是什麼。
繪製功能結構圖時我們該如何掌握顆粒度呢？
一般主要功能模塊不宜太多，以免分不清主次，以5~9個為佳。
不管多複雜的產品都可以提取出最重要的幾個部分，以時刻指導我們應該將最重要的時間與精力放在哪裡，告訴用戶我們提供的最重要的產品與服務是什麼。
從主要功能模塊上，經驗豐富的產品經理一眼就能看出這個產品的調性、方向與主賽道。而層級上，2~3級為宜。
功能結構圖的繪製是產品經理的思維由發散趨向於收斂的過程，剛開始的顆粒度一般比較大，可能僅涉及到某個功能模塊，隨著工作的不斷推進，功能結構圖的顆粒度會不斷細化，最終可以拆分至某個具體的功能操作。層級上最好控制在3級以內，再細分下去的意義不大，功能結構圖的主要目的還是從整體上描繪出整個功能體系。
二、信息結構圖
我們所處信息社會中，有著強烈的信息爆炸感受。對於一款網際網路產品來說，也包含了非常多的信息。
網際網路產品大體上可以分為工具型和內容型（一款產品不是絕對的屬於某一類，如微信，即時通訊可以看作是溝通工具，而朋友圈可以看作是社交內容）。對於內容型產品來說，信息會更加多樣和繁雜。但無論是哪一種，從本質上來講，網際網路產品都是關於「信息」的產品。
而信息是有結構的。
每個人在撰寫簡歷時，其實就是把個人相關的信息整理成結構化信息的過程。
每個人的簡歷上大致會包含姓名、性別、民族、籍貫、出生年月、身份證號碼、聯繫方式、工作單位、工作時間、職位、收入情況、離職原因、畢業院校、學習時間、所學專業、獲得證書等信息。
這麼多信息，如果一一就這樣羅列在這裡，會顯得非常繁雜。
但我們可以將其梳理成以下分組，看起來就會輕鬆很多：
基本信息（姓名、性別、民族、籍貫、出生年月、身份證號碼、聯繫方式）；工作經歷（工作單位、工作時間、職位、收入情況、離職原因）；教育經歷（畢業院校、學習時間、所學專業、獲得證書）。
將信息進行結構化梳理後，會更清晰、更有條理。
而且我們可以從中發現，以上信息是對「一個人」這個對象的結構化信息描述。
信息結構圖就是將業務中的對象按照如上的方式梳理而成的結構化信息圖譜：
在繪製信息結構圖時我們需要注意：信息結構圖和頁面以及交互是沒有關係的。
有些產品經理在繪製信息結構圖時就完全按照頁面結構將信息逐級羅列出來，這是完全錯誤的。如前面功能結構圖是站在業務角度鳥瞰功能體系一樣，信息結構圖也是站在業務角度鳥瞰信息體系。
信息結構圖中同一個對象的信息出現在多個頁面是非常常見的事情。
如前面提到的個人簡歷，在招聘官使用招聘網站時，姓名、性別、年齡、職位、工作時間等關鍵信息既會出現在候選人的列表頁，也會出現在候選人的詳情頁，還會出現在搜索結果頁等等。實際上，凡是與這個對象相關的所有頁面都會用到信息結構圖中關於這個對象的部分/全部信息。
因此，我們可以看到，信息是跨頁面、跨功能的。
信息結構圖有點類似編程中的數據表結構設計，揭示了需要哪些數據，這些數據需要有怎樣的元素組成，才能達到每個功能模塊需要展現的內容表達。如果說功能結構圖是產品的功能抽象，那麼信息結構圖則是產品的數據抽象。
俗話說巧婦難為無米之炊，「炊」是功能，「米」是信息。有米，才能炊。用戶每一次使用產品，都是功能和信息的結合。用戶瀏覽信息然後執行動作或者執行了某個動作以後獲得了信息再進行瀏覽。
那麼我們為什麼要繪製信息結構圖呢？
是因為我們的腦容量是有限的，且信息是跨頁面、跨功能的。
如果一個對象只關聯一個頁面，那麼我們可以很輕鬆地完成方案設計，且不會出現信息遺漏、混亂。
可是這樣的情況是屬於少數，大部分情況是一個對象與多個頁面相關聯，這時對象的信息往往也比較豐富。
在腦容量有限的條件下，如果我們僅憑著記憶，一個頁面一個頁面地畫原型，最後很可能會出現信息遺漏和混亂，做出來的產品方案自然漏洞百出。
這時，信息結構圖就是產品經理的一個重要利器。
有了它，在設計具體的頁面、交互、功能時，我們只需要對照著信息結構圖，通過對用戶使用場景的分析，從信息結構圖中，選擇每個頁面和交互需要使用的信息，並完成詳細的原型設計，即可高效、邏輯清晰、無遺漏地完成產品方案設計。
信息結構圖除了能助力產品經理本身的工作以外，還可以給開發人員進行資料庫表結構設計提供參考。
在信息方面，產品經理關注的是業務中都涉及到哪些對象，每個對象都有哪些信息。而開發人員關注的是實現方式，需要設計一個什麼樣的技術架構、有哪些數據表、表結構是什麼樣的、如果後續欄位需要擴展怎麼辦等等。
如果沒有信息結構圖，當開發人員拿到一份完整的產品方案後，需要自己從功能、頁面、交互中抽象出若干個「對象」，再將對象涉及到的信息欄位窮舉出來，最後再根據數據表設計的要求，加上一些特有的欄位，完成數據表的設計。
如果有信息結構圖，那麼開發人員就可以快速了解以上信息。
當然，信息結構圖的這個意義是附帶出來的，產品經理完全不必要為了開發人員著想而在不必要的情況下去繪製信息結構圖，畢竟開發人員很擅長對數據的抽取，效率可能更高。
三、產品結構圖
在開始說產品結構圖之前我們必須要清醒地認識到一點：前面的所有內容都還沒有涉及到產品設計，也就是說還都是站在業務角度進行的一系列工作，這時連產品的影子都還沒見到呢。從產品結構圖開始，才會開始產品經理的產品設計之旅。
產品結構圖是綜合展示產品信息和功能邏輯的圖表，是將功能和信息進行有機結合，按照一定層次和邏輯關係形成的產品雛形。
之所以說是雛形，也是因為這時還不能看清全部細節。
簡單說，產品結構圖就是產品原型的簡化表達。
產品結構圖是將功能和信息以一種合理自然的邏輯，把功能結構圖和信息結構圖中的內容放入產品中的每一個頁面的結果，是產品概念化設計的結尾階段的產物。
有人認為產品結構圖就是在功能結構圖基礎上將信息結構圖中的信息添加進去，認為產品結構圖=功能結構圖信息結構圖。
本人不贊同這種說法。
既然作為產品原型的簡化表達，那麼必然已經經過了產品設計，而功能結構圖和信息結構圖都還是在業務層面，簡單的疊加並不能直接產生產品結構圖。
實際上，產品結構圖是產品經理從業務層面落地到產品層面的一個重要過程。經過這個過程後，可以看到產品的主要頁面結構和基礎信息，能看出產品的基本輪廓。
既然後續還需要做產品原型，並且看起來產品原型必不可少，那麼產品結構圖的作用是什麼呢？
產品結構圖在前期的需求評審中或其他類似場景中可以作為產品原型的替代——因為產品結構圖相較於產品原型，其實現成本低，能夠快速對產品功能結構進行增、刪、改操作，減少產品經理在這個過程中的實現成本；同時可指導產品原型製作，以產品結構圖作為繪製產品原型的依據，可以避免我們在產品設計中邊畫邊改，跳進只見細節不見森林的陷阱。
除此之外，產品結構圖也是產品和研發溝通的橋梁，便於研發初期評估開發計劃。
現在小結一下：
很多產品經理都說，這3個都是結構圖，容易混淆，怎麼能夠更加容易區分、加深理解呢？
其實很簡單，既然後面的「結構圖」三個字是一樣的，那麼重點肯定在前面兩個字上。
功能結構圖，關鍵詞是功能，是功能的結構化表達；信息結構圖，關鍵詞是信息，是信息的結構化表達；產品結構圖，關鍵詞是產品，是產品的結構化表達。這裡的產品就是產品經理天天口中說的產品啦。
這樣一想，是不是瞬間就清晰了呢？
四、如何繪製
細心的讀者會發現，上面洋洋灑灑說了那麼多，卻沒有說這些圖都如何來進行繪製，下面進行統一說明。放在一起說的原因是：它們之間有比較強的關聯性。實際上，繪製它們的順序是：功能結構圖->信息結構圖->產品結構圖。
首先繪製功能結構圖。
要繪製功能結構圖，那我們必須要知道有哪些功能。而因為功能是業務的承載方式，所以我們必須要詳細的了解業務。針對每個場景，梳理業務流程，通過抽象關鍵業務節點或操作來劃分功能模塊。
羅列出業務閉環中所需要的功能點，找出從屬關係與層次，粒度從粗到細，最終繪製出功能結構圖。命名上可以採用「動詞名詞」的方式。
功能結構圖的最小顆粒，要根據實際情況來把握。若功能非常複雜，拆分到一定的顆粒度即可，並不一定要拆分到最小顆粒。參見前文。
功能結構圖繪製完之後開始繪製信息結構圖。
在繪製信息結構圖時，需要思考一個問題：在所有場景中，涉及到了哪些對象？
信息結構圖是描述對象的，首先我們需要分析並抽象出對象。
一個功能可能會涉及多一個對象，也可能會涉及到多個對象。這些對象是構成這個功能的信息內容。
明確了對象以後，接下來就要梳理出描述這個對象都需要哪些欄位。
這裡我們需要注意的是：描述一個對象的欄位可能有很多，但並不是所有欄位都要繪製到信息結構圖中，只有業務和功能需要的欄位才需要被包含進去。
梳理欄位時，既不能缺失某些欄位，又不能包含冗餘欄位。
對於目前暫時用不上但是未來需要的欄位，是需要被包含進去的。
有了功能結構圖和信息結構圖，我們就可以基於此繪製產品結構圖了。繪製產品結構圖我們需要站在全局角度將功能進行分類、分層，抽象出產品框架。
這個產品框架很重要，好的產品框架擴展性很強。觀察微信你就會發現，微信經過這麼多年的發展、這麼多版本的迭代，它的產品框架基本沒有怎麼變過。
明確了產品框架以後，就可以在每個需要體現內容數據的節點，添加所需要的數據描述。
至於交互動作的細節不用體現在產品結構圖中，比如頁面布局細節、交互手勢、動畫效果等，屬於互動設計的範疇。
繪製產品結構圖時，你就要想像這是你產品的最終形態，每個頁面要有哪些功能和數據，類似於開發做的不同靜態頁面，展現在你面前的就是產品的雛形了。
一個產品/需求從創意、構想到最終輸出給設計、開發，不一定會用到上面所說的全部類型的圖，視情況選擇使用即可。如果產品比較簡單或者是經驗豐富的產品經理，在高層沒有提出相關匯報需求的情況下，有些圖常常可以省略。
除此以外，有些圖是產品經理工作過程本身的中間產物，一般情況下不會進行輸出，而且為了更加節省時間提高效率，產品經理常常也會用白紙和筆進行手繪，並不會用工具整理成文檔。
所有的圖都是工具而已，要靈活運用，只要能對你的工作產生正面積極的作用就可以用，不必為了留存而留存，千萬不要被工具所框住、所限制。
作者：厚厚，多年網際網路和傳統企業的跨界產品經理；厚厚的語和文
本文由 @厚厚原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自 Unsplash，基於 CC0 協議
,