畫圖之前，我們一定要知道：為什么要畫圖？因為，畫圖是需求分析的重要環節，是用可視化的方式，對需求進行梳理和展示，把需求描述清楚，才能保證想法落地變成產品。

經?？吹骄W上有人問，產品經理要畫哪些圖，怎么畫流程圖等關于畫圖的問題。

確實，畫圖是產品經理必備的硬核技能。然而，畫圖又不僅僅是畫幾個圖而已。

做產品沒有統一、標準的規范指導，容易讓人為了畫圖而畫圖。

甚至，在很多外行看來，感覺產品經理就是個畫圖的。

還有人戲稱，去大廠當產品經理，就是個畫圖仔。

幸好，我從最初做項目，就學著用 UML 進行需求分析。受益于此，我漸漸體會到，畫圖背后的邏輯和意義。

趁這段時間，從畫圖入手，用自己的理解，總結自己做產品的方法。

一、當我們畫圖時，是在畫什么

1. 探尋本源

在需求分析領域，談到畫圖，不能不提 UML 。

早在?IT?軟件時代，UML 就是一套非常好用的需求分析、系統分析設計的工具和方法。

那么，什么是 UML ？

UML（Unified Modeling Language）統一建模語言，是一種用來對軟件系統開發的產出進行可視化、規范定義、構造和文檔化的面向對象的標準建模語言。

——這是比較官方的定義。

我理解：它是用一套規范的可視化圖形，及建模方法，來描述軟件系統的分析、設計等各個階段，最終形成可視化、文檔化的產出。

作為一門語言，UML 在建模過程使用的基本圖形元素，就是它的 “詞匯” ，如用例、參與者、類等；而這些元素間的使用規則，好比 “語法” ，如用例圖、活動圖便是在這種 “語法” 指導下繪制的視圖。

學習一門語言，既要學習其 “詞匯” ，也要掌握其 “語法” 的運用，將 “詞匯” 合理組織起來，才能編寫足以 “傳情達意” 的 “文章” 。

UML 中，通過元素、視圖建立起來的模型，正是這樣一種可準確描述需求，又便于用開發思維去理解的 “文章” 。

UML 不僅提供了一套工具，還提供了一套思想和方法。

學工具，只能讓我們知其然；掌握該工具背后的思想和方法，才能讓我們知其所以然、活學活用。

UML 中，將可視化視圖分為 “ 靜態視圖 ” 和 “ 動態視圖 ” 。從“ 靜 ”和“ 動 ”兩個維度，來描述軟件系統。

這也是人們描述現實事物的方法。

• 從 “ 靜 ” 的方面，描述事物的結構性特征；
• 從 “ 動 ” 的方面，要描述事物的行為性特征。

一靜一動相結合，便能把事物全面、準確地描述清楚。

這讓我明白，做產品需求分析，也是對需求進行描述和表達。

使用這種方法，從靜態、動態兩個視角維度去分析和描述需求，就有了指導思想，能提高準確性和效率。

2. 畫圖的實質

這就不難理解，當我們畫圖時，一方面是在借助工具，對業務、需求、場景等進行梳理；一方面是在對需求、產品進行描述，并輸出可視化的材料，供相關人員，閱讀使用。

因此，畫圖，是需求分析的重要組成部分，是用可視化的方式，對需求進行梳理和展示。

需求理解和描述清楚了，才能真正把想法落地變成產品。

同時，產出的可視化圖形，是后續產品規劃、研發、設計、測試，及優化迭代、問題排查等的重要依據。

3. 本文思路

UML 中的圖形、視圖、建模方法等知識內容很多，要深入學習，推薦《 大象：Thinking in UML 》一書。

本文，結合在產品工作用到的內容，及自己的理解、體會，先從整體進行總結，建立一個整體的認知框架，后續再具體深入。

為了方便理解，我結合在資訊、充值等方面的經驗，虛構了一個小型 APP 的前端需求，作為案例來分析。從靜態、動態兩個維度，總結在產品工作中常用的視圖。

二、從靜態視角看需求

從靜態的視角去分析需求，是用靜態視圖，來描述產品的結構性特征，這些結構決定了產品是由什么組成、能做什么、長什么樣的。

在 UML 中，靜態視圖包括用例圖、類圖、包圖。類圖與包圖，在產品層面較少使用，開發層面更為需要。

結合實際工作，總結產品的靜態視圖有：結構圖、用例圖、無交互的原型圖。

1. 結構圖

結構圖，顧名思義就是描述、展示產品的基本結構、框架。它能清晰展示產品有哪些模塊、功能或系統組成，它們之間的層級、從屬等結構關系是怎樣的。

這在需求分析的初始階段，就要明確。

好比，建一棟樓，需要有建設藍圖，得先知道樓要建多高、地基要挖多深、面積多大、蓋多少層等基本的框架信息。

結構圖，像一棟樓的框架，那么一旦確立，就很難改，除非推倒重來。所以，一開始一定要搞清楚，避免挖坑。

當然，在基本框架下，隨著對需求的不斷深挖，各模塊、功能、系統之間的結構、層級、從屬關系，會更加清晰，結構圖也要細化、完善。

根據使用情況，結構圖大致可分為：功能結構圖、信息結構圖、產品結構圖。

1）功能結構圖

功能結構圖，就是描述產品都有哪些功能，層級和歸屬關系是怎樣的。

這在產品工作中，經常用到。大部分人做產品，都知道在規劃產品時，要畫功能結構圖。

現在用案例來看看這些圖是怎么畫的。

這個虛構 APP 的需求是：要做一個 APP ，給用戶提供電商優惠活動信息、手機話費充值，后續會加更多功能，發展用戶體系等。

一般經過需求調研和確認，腦海里就要有個大概的框架，這個 APP 給什么人用的、由哪些功能組成。

這個需求，我只能先腦補需求調研和確認的過程，然后得出這個產品大概要有：首頁聚合展示、優惠活動、話費充值、個人中心，這四個大的功能模塊。

功能結構圖

2）信息結構圖

信息架構圖，跟功能結構圖，容易搞混。

其實，有所不同，信息結構圖重點在 “ 信息 ” 。也就是，從信息的維度，將整個產品的信息進行抽象、歸類，說明產品包括哪些信息、字段數據。

這有點類似，UML 中的類圖。在產品層面，更多是要把產品里面的信息進行整理、歸類、描述清楚，特別是信息的類型、條件、規則。比如，標題字數上限、圖片尺寸等。

案例中的需求進行抽象，可以得出如下簡單的信息結構圖。

信息結構圖

3）產品結構圖

產品結構圖，網上說法不一，這本來就沒什么標準，關鍵是看怎么理解、怎么用，能把需求準確、清晰地描述出來即可。

個人理解，產品結構圖，就是「 功能結構圖 」與「 信息結構圖 」的結合。

就是在描述功能結構后，把對應功能模塊有哪些信息，這些信息字段的定義、規則、條件、類型都列出來即可。

這種做法，更為常用。這個圖畫出來內容比較多，因為篇（太）幅（懶）關系，這里就不再畫，可以自行腦補下。

2. 用例圖

用例圖，采用參與者和用例來展現產品的功能性需求，是 UML 中一種很重要的視圖。

在 UML 中，將用例圖，分為業務用例圖和系統用例圖。

除了畫圖，還要寫用例規約，以描述說明用例，包括對用例的描述、參與者、前后置條件、基本流程等，一般用表格形式比較清晰。

1）業務用例圖

業務用例圖，是從業務的視角，通過業務建模，對業務進行描述。

這里說的業務，是在還沒有新系統或產品前，業務是如何進行的。

UML 使用業務用例圖，進行業務建模，旨在把業務描述清楚，發現業務問題和難點，這樣的新系統才能更好的融入業務去解決問題。

簡單的需求，很少畫業務用例圖；如面對比較復雜、有規模的需求，建議最好用這個思路進行分析，可以更好地發現業務問題，以保證產品需求不跑偏。

案例需求中，就話費充值這個業務，可畫成業務用例圖如下。

業務用例圖

2）系統用例圖

系統用例圖，是對有新系統或產品后，業務又是如何進行的，進行建模描述。它是對業務用例進行分析得到的，是系統的開發范圍。

簡單看來，「 系統用例圖」與「 功能結構圖」很類似。

功能結構圖，只是從產品或系統層面，描述都有哪些功能。

系統用例圖，則是從使用者的角度，描述對應用戶能使用產品做什么。這樣的好處，是讓我們時刻以用戶為中心，思考產品和功能。

好多人，在做產品時，經常做著做著就忘了用戶是誰、產品或功能是給誰用的。使用系統用例圖，可以幫我們避免這一點。

以下為案例需求的系統用例圖。

系統用例圖

3. 原型圖（無交互）

原型圖，是產品經理最熟悉不過的，也是最常用的。甚至，有不少人，以為做產品就是畫原型圖，一接到需求，巴不得馬上打開 Axure 畫圖。

眾所周知，原型圖，是產品表現層面的 Demo ，描繪產品的界面長什么樣，功能如何設計、擺放，有哪些內容。

好比，建一棟大樓，需要設計每一層樓的布局，都有哪些房間、大小怎樣，到具體每一間房的格局，什么地方設置門、在什么位置安窗戶等。

一般來說，無交互的原型圖，屬于結構圖的范疇。在工作中，為了提高效率，很少畫交互型的原型，除非像大廠有專門的交互設計師。

畫原型，除了要準確把握需求，還涉及一些人機交互、視覺設計的知識。這里不具體展開。案例中的話費充值功能，簡單繪制原型參考如下。

話費充值頁面原型

三、從動態視角看需求

從動態的視角去分析需求，則用動態視圖，來描述產品的行為性特征，這些特征決定了產品是怎樣運行的。

在 UML 中，動態視圖包括活動圖、時序圖、協作圖、狀態圖。協作圖，在產品層面較少使用?；顒訄D，就是常用的流程圖。

結合實際工作，總結產品的動態視圖有：流程圖、時序圖、狀態圖。

1. 流程圖

流程圖，是描述為完成某個目標，需要以什么順序做哪些動作；能直觀描述實現目標過程的具體步驟。在很多領域，被廣泛使用。

梳理、繪制流程圖的過程，也是一種流程化的思考。

UML 中，流程圖，也叫活動圖；另外，還有泳道活動圖。產品上，都經常使用。

1）普通流程圖

普通的流程圖，就是在描述產品的具體功能，在具體場景下，是怎么一步步實現的運轉過程。

普通流程圖中，包括了多個不同對象執行的動作事件，只能大致描述過程；無法將整個過程中，參與的各個對象體現出來。

案例需求中，從用戶感受到的充值過程，用普通的流程圖來梳理，可繪制如下。

用戶充值話費流程圖

2）泳道活動圖

泳道活動圖，用來梳理、描述有多個對象參與的流程，對象可以是人，也可以是系統。

泳道活動圖，在活動圖的基礎上，引入了泳道，像游泳比賽的運動員只能在其泳道中比賽一樣，規定每個對象的動作只能畫在其對應區域。

這樣，可以很好地體現整個過程參與的多個對象所做的動作和順序。

同樣是用戶充值話費的過程，在產品層面，至少有用戶、APP、管理后臺、話費供應商（這跟每個公司的業務和系統情況有關，但基本邏輯類似。）的參與才完成。

因此，用泳道活動圖來描述，最合適不過。為了避免示例圖過于復雜，此處僅畫出正常流程，并未包括異常分支。

話費充值泳道活動圖

2. 時序圖

時序圖，用于描述產品為實現某一具體目標，多個參與對象之間按時間順序交互的過程。

時序圖，與泳道活動圖類似。不同的是：時序圖更強調對象在交互過程中消息事件的發生順序。

有時為了了解系統性能，或優化體驗，要統計某些交互的時長，用時序圖，就很方便定義和描述。

用時序圖來梳理多個系統間的交互過程，特別好用，我最常使用。時序圖畫得好，泳道活動圖不畫都沒關系。

同樣用戶充值話費過程，用時序圖來梳理，可以對比下與泳道活動圖的區別。

話費充值時序圖

3. 狀態圖

狀態圖，用于描述產品為完成某個目標，某個對象的狀態變化和流轉過程。狀態，是對象執行或等待某個事件的條件。

常見的，有電商的訂單狀態、快遞物流狀態、支付狀態等。

系統中對象的狀態細化和明確，對監控系統的處理過程，和事后問題排查有很大幫助。

狀態圖非常重要，又很容易被忽略。以前填過很多坑，就是產品沒定義好狀態，結果開發按自己想象補上了，事后發現問題，處理起來很麻煩。

如案例中，如今的話費充值，雖然到賬時間很快，但訂單在系統的流轉過程，也有各種狀態的變化。

下面以此為例，看看一個比較完整的狀態圖，可以注意下其與流程圖的區別。

話費充值訂單狀態圖

四、原則與工具

1. 基本原則

畫圖，雖說沒有標準答案，但畢竟，產出的可視化圖形是后續工作的重要依據，也要給各環節的人閱讀使用。

所以，為了保證產出質量和工作效率，還是要滿足以下基本原則：

• 邏輯合理、清晰
• 沒有疏漏
• 可讀性強
• 美觀

2. 善用工具

畫圖、分析過程，可用的工具很多，只要功能滿足我們的需要，用起來順手即可。

另外，一定要善于利用工具，讓工具為我們所用，可找準一兩個工具，用好它，能大大提高效率。

比如，Axure 就非常強大，不僅畫原型圖，大部分圖都可用它完成。

甚至，還能用來寫需求文檔，這樣輸出的文檔相對統一，便于管理和閱讀。

其他常用的，有 Visio ，及專門畫思維導圖的 MindManager、XMind 等。

其實，只要掌握了方法，哪怕是用紙和筆，照樣能描述清楚。

五、回顧總結

總結一下：做產品為什么要畫這些圖？

首先得明白：為什么要畫圖？

因為，畫圖是需求分析的重要環節，是用可視化的方式，對需求進行梳理和展示，把需求描述清楚，才能保證想法落地變成產品。

• 能幫助我們梳理、分析需求，更好地理解和分析清楚需求
• 能產出可視化的需求描述，便于閱讀使用

其次得知道：為什么畫這些圖？

因為，畫圖有一定的指導思想和方法，能提高準確性和效率。

UML 提供了很好的思想和方法，可以從產品的靜態和動態兩個視角進行描述。

由此，有了靜態和動態兩種視圖，每個視圖有對應的圖形，供不同情況使用。

1）靜態視圖，描述產品的結構，決定產品是由什么組成、能做什么、長什么樣的。包括：

• 結構圖：功能結構圖、信息結構圖、產品結構圖
• 用例圖：業務用例圖、系統用例圖
• 原型圖（無交互）

2）動態視圖，描述產品的行為，決定了產品是怎樣運行的，包括：

• 流程圖：普通流程圖、泳道活動圖
• 時序圖
• 狀態圖

六、寫在最后

寫完之余，感受頗深。

原本只想大概總結下，不料職業病又犯了——為了總結，把整個分析過程的思路重新捋了一遍，把每個環節的分析視圖畫了一遍。

雖然嚴重影響進度，卻感覺體會又加深了。

平時分享，可能幾句話就能講清楚的內容，用文字記錄并表達出來，卻是刪刪改改，終不能滿意。

篇幅關系，很多內容未能很好展開，每個人對文字的理解也不同。

況且，個人的理解和思路，也并非標準答案；只是通過自己的總結，拋磚引玉，提供一些參考，愿您有所啟發。

感謝閱讀！

參考資料：

大象：Thinking in UML》

《人人都是產品經理》

本文由 @四月 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議