一張圖講清楚產品架構，手把手教你畫產品框架圖
什麼是產品架構圖
產品架構圖是產品經理用來表達自己產品設計機制的一張概念圖：
761505660292_.pic_hd.jpg
它將視覺化的具象產品功能，抽象成資訊化、模組化、層次清晰的架構，並通過不同分層的互動關係、功能模組的組合、資料和資訊的流轉，來傳遞產品的業務流程、商業模式和設計思路。
由於產品架構圖通常用於比較複雜的產品專案中，目前介紹產品架構圖的相關書籍和資料極少（尤其是入門級別的資料很少提及），卻是設計複雜產品時不可或缺的文件之一。
沒有資料的探索過程漫長且沒有方向，在終於有所沉澱後，我花了四周寫下了這篇總結，希望可以為你繪製產品框架圖時提供簡明的參考。
為什麼要畫
梳理自己對產品方向的判斷：****
思考這張圖如何設計的過程，也是幫助你梳理“半年內自己的產品該往何處去、需求應該如何分期和落地、和其他產品的依賴&競爭關係是什麼、未來的可拓展性在哪裡”等問題的過程。
為技術&運營的輸出形成支撐：
當這張圖被設計出來後，按照產品架構圖的結構和路徑，專案的里程碑（RoadMap）就可以被清晰的拆解出來，同時專案成員也可以根據這張架構圖產出運營計劃、技術系統架構方案等強依賴產品方向的方案。
讓他人視覺化的理解你的產品架構：
能較為清晰簡單的呈現自己的思路、明確自己的產品邊界、指明發展的方向，常用於在專案規劃或專案總結中進行演示，幫助不瞭解你的產品的人快速的建立對你的產品結構、功能、複雜度的認知。
何時需要畫
建議在複雜專案開始前寫：
當你要開始設計一個系統性、完整的需求時，如果跳過畫產品架構圖的步驟，直接開始畫原型、寫PRD、kick off，就很容易發生“改了又改”、“做了一版需求然後又推翻”的情況。
但“種一棵樹最好的時間是十年前，其次是現在”：
如果你的專案已經進行到一半，自己卻從未產出過這張圖，那麼就從此刻開始，按照下文的步驟嘗試為自己的產品產出一張產品架構圖吧。
如何畫
之前我們分享了 ofollow,noindex">【AR最全乾貨及資料】設計AR產品，你一定要看的總結 ，你可能對AR相關的背景知識已經有所瞭解。為了分享的延續性，我們來做一個大膽的假設*：
假設你是 微信-掃碼功能 的產品經理，有一天老闆把你叫到辦公室，一番鼓勵後拍著你的肩對你說：
“蘋果釋出會看了沒？蘋果這麼重視對AR能力的支援，我們微信也要趕緊把AR功能做起來。這是個Allen（張小龍）很重視的專案，你回去好好設計一下，明天來跟我過方案。記住，要能夠一炮打響，全民參與喔！”
啊，張小龍級別的專案啊！明天就要出方案，怎麼辦 ？
畫前準備
列出問題域
在需求初期，產品經理得到的往往只是一句比較模糊的需求描述，它們可能來自於老闆、運營或使用者。
直接把這句話作為核心產品功能是不恰當的，合理的做法是先把這個產品所有的問題域列清楚。
“問題域”是指自己的產品能夠解決的所有問題的空間集合。從核心需求出發，將所有當前需要解決、未來可能要解決的問題放入產品框架的範圍，能夠幫助你的產品架構圖擁有更高的可拓展性，在後續具備迭代和優化的空間。
以微信AR的需求為例，問題域是這樣一個集合：
651505660228_.pic_hd.jpg
詳細操作步驟：
1. 找到收到的需求中，跟產品形態、產品目標相關的詞句，去列出“XX的流程會是什麼樣”、“XX該怎麼達成”之類的問題，直到如果這些問題解決，能夠實現核心需求的方向和業務目標。
2. 去逐次尋找這些問題需求被解決的過程中，是否有其他要先解決掉的問題、或者其他跟業務相關的問題能夠被解決/改善。
3. 按照層級去羅列出所有的問題，並附上自己的初步回答，從而形成一個初步的、自己的產品能夠解決的“問題域”。
確定產品方向
在經過問題域的羅列後，你應該能夠得到一個模糊的產品方向和功能範圍。把這些問題域的答案抽象總結成一個確定的產品需求。
以微信AR的需求為例，根據問題域，我們發現需求不只是掃碼元件增加AR識別能力這麼簡單，整個需求裡需要引入廣告主的角色，並且需要和廣點通、騰訊開放平臺等團隊合作。最終得到的產品方向描述是這樣的:
661505660233_.pic_hd.jpg
詳細操作步驟：
問題域的環節非常發散，這一步需要回歸基礎，把模糊的需求補充、拓展和翻譯成一個在商業模式和使用者體驗上能夠形成閉環的產品需求。
1. 核心需求確定：我的產品核心解決的是哪批使用者、哪個使用者需求？
2. 產品目標：如果以一個數字指標衡量我的產品，它應該是什麼？
3.使用者場景：核心需求基本的產品形態、使用者使用的路徑是怎樣的？
清晰的業務流程
這一步需要根據核心產品需求和問題域的答案，畫出簡單的業務流程。業務流程是產品設計中常見的圖表，繪製方法就不再多做說明。
以微信AR的需求為例，從廣告主準備AR互動，到使用者在前臺使用攝像頭參與互動，整個業務流程如下:
671505660241_.pic_hd.jpg
著手繪製
搭建基礎框架
基礎的產品框架脫胎於業務流程，但相比業務流程，更加註重產品功能的列舉、功能模組之間的分界。
詳細操作步驟：
1. 對照業務流程，根據自己設想的產品機制、基本產品形態和使用者的使用路徑，列出需要的頁面&功能&模組等前後端邏輯。
791505660329_.pic_hd.jpg
- 將剛剛得到的多個流程圖中所有功能類似或者範圍有包含關係的機制/功能放在一起，以模組化的形式形成一張簡單的矩陣圖。
681505660249_.pic_hd.jpg
3. 將明顯是同一個產品範圍、同一組產品功能的模組放在同一層級，得到一個基礎的產品框架。
691505660257_.pic_hd.jpg
明確架構分層
一個具備前後臺關係的產品架構圖至少分為三層：使用者感知層（在何種場景下通過何種方式觸達使用者）、功能模組層（通過哪些功能模組實現產品的核心功能、和哪些外部平臺功能有信息互動）、資料層（產品的資料從哪裡來、產品的資料沉澱到何處去）。
在上一步進行簡單分層後，我們已經得到一個初步框架，但是難免會有分層不明確的問題。此時需要按照兩種維度來處理架構圖的層級：不同資訊層級的邊界、同一層級內模組和模組的邊界。
1. 處理不同資訊層級的邊界：
架構圖的層級表達的其實是資訊之間的流轉關係，不同資訊層級之間一定是有邏輯關係的。
其中使用者感知層和資料層通常可以簡化為一層（使用者端的功能表達往往邏輯簡單、資料的來源問題則不是自己產品的核心功能），而功能模組層則需要按照自己產品的邏輯去將功能模組層內的主要模組變成新的層級。
701505660266_.pic_hd.jpg
- 處理同一層級內子模組的邊界：
各層次之間雖然相關，但同一層次內的子模組之間一定是互相獨立、界限分明的（常常對應著不同的開發團隊和系統應用）。將解決不同問題的功能拆分成兩個子模組，做到一個問題只在同一層解決，避免牽一髮而動全身的情況出現。
721505660280_.pic_hd.jpg
3. 明確產品間的邊界：
產品邊界對於開發設計系統架構、業務間的合作模式都非常重要。用不同顏色標識清楚產品框架中，各個部分所屬產品的邊界，通常其中屬於自己團隊的部分用亮色表示。
741505660285_.pic_hd.jpg
加入資訊流轉機制
產品架構圖在表達產品的核心功能外，也應該體現資訊流動的路徑：當前層級資料的互動形成產品功能，產品功能又產生新的資料，從而推動下一層級的功能運轉起來。
如果當前產品的主要使用角色只有一個，則只需要用箭頭標明模組間資訊流動的方式即可。如果當前產品會涉及的主要角色比較多，則需要用不同顏色的線條將他們和各個模組之間的資訊互動關係外化出來。
761505660292_.pic_hd.jpg
最終檢查
一張好的產品架構圖，應該具備以下特點。
-
清晰的模組功能邊界
-
功能經過抽象，做到標準化、互相獨立
-
上下游產品功能邊界清晰，架構分層明確合理
-
具備迭代優化的能力
記得不斷根據你的產品的發展情況來更新產品架構圖，每次修改的過程對提升產品架構能力的幫助非常巨大。
1. 本文案例「微信要做AR功能」為虛構背景，功能拆分也僅做了最簡單的示意，不代表微信或其他公司AR功能產品設計的真實思路。如與真實情況雷同，說明我的推理能力超強，哈哈哈哈。
2. 產品框架圖相關的知識大部分來自阿里各位產品前輩的言傳身教，十分感激。如果你按照教程繪製自己的產品框架圖時遇到任何問題，我很樂意和你一起探討。
- 關聯閱讀：