經常看到網上有人問，產品經理要畫哪些圖，怎麼畫流程圖等關於畫圖的問題。

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

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

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

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

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

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

01

當我們畫圖時，是在畫什麼

1、探尋本源

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

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

那麼，什麼是 UML ？

UML（Unified Modeling Language）統一建模語言，是一種用來對軟體系統開發的產出進行視覺化、規範定義、構造和文件化的面向物件的標準建模語言。這是比較官方的定義。

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

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

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

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

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

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

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

這也是人們描述現實事物的方法。從 “ 靜 ” 的方面，描述事物的結構性特徵；從 “ 動 ” 的方面，要描述事物的行為性特徵。

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

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

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

2、畫圖的實質

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

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

產出的視覺化圖形，是後續產品規劃、研發、設計、測試，及最佳化迭代、問題排查等的重要依據。

3、本文思路

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

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

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

02

從靜態視角看需求

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

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

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

1、結構圖

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

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

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

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

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

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

1）功能結構圖

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

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

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

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

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

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

功能結構圖

2）資訊結構圖

資訊架構圖，跟功能結構圖，容易搞混。

其實，有所不同，資訊結構圖重點在 “ 資訊 ” 。也就是，從資訊的維度，將整個產品的資訊進行抽象、歸類，說明產品包括哪些資訊、欄位資料。

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

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

資訊結構圖

3）產品結構圖

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

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

就是在描述功能結構後，把對應功能模組有哪些資訊，這些資訊欄位的定義、規則、條件、型別都列出來即可。

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

2、用例圖

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

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

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

1）業務用例圖

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

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

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

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

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

業務用例圖

2）系統用例圖

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

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

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

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

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

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

系統用例圖

3、原型圖（無互動）

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

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

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

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

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

話費充值頁面原型

03

從動態視角看需求

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

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

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

1、流程圖

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

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

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

1）普通流程圖

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

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

案例需求中，從使用者感受到的充值過程，用一般的流程圖來梳理，可繪製如下。

使用者充值話費流程圖

2）泳道活動圖

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

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

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

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

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

話費充值泳道活動圖

2、時序圖

時序圖，用於描述產品為實現某一具體目標，多個參與物件之間按時間順序互動的過程。

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

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

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

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

話費充值時序圖

3、狀態圖

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

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

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

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

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

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

話費充值訂單狀態圖

04

原則與工具

1、基本原則

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

所以，為了保證產出質量和工作效率，還是要滿足以下基本原則：邏輯合理、清晰沒有疏漏可讀性強美觀

2、善用工具

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

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

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

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

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

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

05

回顧總結

總結一下，做產品為什麼要畫這些圖？

首先，得明白，為什麼要畫圖？

因為，畫圖，是需求分析的重要環節，是用視覺化的方式，對需求進行梳理和展示。能幫助我們梳理、分析需求，更好地理解和分析清楚需求能產出視覺化的需求描述，便於閱讀使用。

其次，得知道，為什麼畫這些圖？

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

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

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

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

結構圖：功能結構圖、資訊結構圖、產品結構圖用例圖：業務用例圖、系統用例圖原型圖（無互動）

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

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

06

寫在最後

寫完之餘，感受頗深。

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

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

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

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