流程圖是產品經理必備的技能之一，但許多新手產品經理對其掌握程度有限。本文針對創業團隊和產品經理的實際需求，詳細介紹了四種常見的流程圖，並結合具體案例講解了它們的繪製要點和應用場景，供大家參考。
“Simplicity is the ultimate sophistication.
最好的流程，來自於最簡單的思考。”
——Leonardo da Vinci
唐納德·甘迺迪
這位曾是《科學》雜誌的主編。
如何繪製流程圖，是產品經理的一個基本功。
但仍然還有不少的新手產品經理，對此並不是很清楚。
今天就來簡單聊一聊這個問題，不囉嗦了，直接上內容。
並且也結合一下創業團隊的情況來提供一些建議。
希望能給大家帶來一些説明。
功能流程圖是最常見的一種流程圖。
它體現了產品經理對需求的歸納，並且能進行多方的“翻譯”。
也就是將業務的需求翻譯成了產品的需求，變成開發能看懂的“語言”去交付。
尤其是功能流程圖，是一個有利的溝通工具。
注意，這個例子是為了講解來使用的，僅僅只是個類比。
現在真實的產品註冊流程，其實都很複雜了。
比如我沒有加入一些特殊的情況，例如常用的第三方openid註冊的方式。
但這個例子已經足夠給大家做引導了。
功能流程圖其實並不複雜，基本上大家都可以看得懂，
以下幾個要點，可以更好的幫助初學者迅速掌握。
1.使用泳道圖
盡可能的使用泳道圖，也就是每一列都分屬於不同的職能。
當然你也可以使用橫向泳道。
2.使用分隔步驟
如果流程比較複雜的話，還可以用橫向的虛線來分隔流程。
當然，如果流程圖使用橫向的泳道，那就需要縱向的分隔線。
3.使用子流程
不要把流程圖畫的太複雜，要善於分解子流程。
如圖，符號就是圖上左右各有兩條豎線的方塊。
4.使用開始和結尾
這樣便於判斷流程的開始和結束。
如圖，符號就是橢圓。
5.一個流程只引出一條線
而且這條線上要有箭頭。
6.一個判斷可引出兩條線
而且這兩條線分別代表“是”和“否”，上面要有箭頭。
而且一張圖中的“是”和“否”的方向最好是一致的，如上可見，我把“是”都放在了下面，而“否”都放在了右邊。
7.線條要避免交叉
如圖，不過因為我堅持了原則5，所以還是出現了2個交叉。
但過多的交叉確實會影響閱讀，所以要盡量避免。
8.這是功能流程圖，不要帶交互資訊
要不然圖會變得非常的瑣碎，這個下一節會講。
產品經理所用到的功能流程圖技巧，一般都還是比較簡單的。
流程圖最早是在在軟體工程中使用的，會用到更複雜的方法，比如說包含有文檔、存儲數據等符號和功能。
不過在創業團隊中的產品經理，能掌握到如上7點，就足夠用了。
另外，功能流程並不僅僅只用在系統級別交互上。
如果從運營經理出發，也可以學習和掌握這套方法，按照此來繪製業務流程圖。
比如報銷流程，除了有系統參與的部分，還有人員自己人肉跑腿的部分，這些都屬於業務流程的一部分。
交互流程圖的核心需求，是把交互行為用邏輯鏈條的方式來表達，這樣可以科學性的避免歧義。
如果上面的功能流程圖可能和整個項目團隊來對話，那麼交互流程圖更多的是和前端交互設計師來對話。
這個例子也只是個類比，類比的是在註冊時，在輸入框中輸入電話號碼的交互。
這個小小的輸入框，現在也有比較成熟的交互解決方案，比如會判斷輸入的手機號是否真實等。
所以，大家理解就好。
這裡就不用多囉嗦了，要點其實和功能流程圖是一樣的，除了沒有泳道和分隔符這兩點，因為一般情況下不需要這麼刻板。
當然加上也可以。
但是！注意……但是。
如果是創業團隊，我實際上不太建議畫交互流程圖：
所以不如把人力資源節省下來，同時也要避免如上我所說的，別把交互細節過多的繪製到功能流程圖中。
那在什麼樣的情況下，需要使用交互流程圖呢？
一般大家叫頁面流程圖，但其實跟上述兩種流程圖非常不一樣。
並非表現抽象的概念，而表現的是實體。
並非表現有向量方向的流程，而更像是網狀關係圖。
這個例子也只是個類比，類比的是和註冊登錄相關的一組頁面。
當然了，現在主流產品的註冊模組也比較複雜了，這也是一個比較簡化的版本。
同樣，大家理解就好。
頁面流程圖最大的作用，就是重視頁面之間的關係，並且重視描述系統功能實現的路徑。
但要注意以下幾個要點：
1.想要表達什麼？
在我這個圖中，我表示的是頁面之間的連結關係，所以往往也有產品經理直接用高保真的UI圖來更好的進行表現。
另外，也可以在圖中標註各個頁面的功能清單，更好的進行邏輯化表達。
2.瞭解適用範圍
同樣，我也不建議一般情況下的產品創業團隊使用頁面流程圖，原因也是過於教條，意義也不大。
但是針對功能型的產品創業團隊，做如操作後台、管理功能等產品，還是會有一定意義的，但一般來說這種情況下頁面數量會非常多，之間的關係表達也過於網狀，需要做好模組切割。
談到時序圖之前，先聊聊數據流程圖。
其實產品經理一般很少用的數據流程圖，這也屬於軟體工程的範疇。
主要從數據流動的過程來表述業務的數據處理方式，分為數據流、加工、存儲和實體這四個部分。
具體的例子，大家可以自己去檢索。
這部分我的知識儲備也不足，待後續完善後再進行補充。
但我在此建議，如果僅針對2C產品經理，還是應該更多的學習時序圖。
時序圖在不少應用層面替代數據流程圖，已經成為一個小小的趨勢。
此圖來源於CSDN博主貝塔貝卡貝，我就直接拿來用了，講的也是和註冊相關的微信登錄方式。
這對開發人員是比較基礎的知識，但對於產品經理來說還是需要學習的。
產品經理往往不需要畫時序圖，但需要能看懂。
我簡單講解幾點：
1.物件：頭部/底部是物件，可以是使用者也可以是系統，一個數據流程都先從最左側的對象開始。
2.時間線：每個物件都會下拉一條時間線，注意所有物件從上到下的時間線的進度是一致的。
3.消息：
（1）在自身時間線內迴圈的消息，是自關聯消息，技術上是在一個對象內部來進行調用或處理。
（2）從左至右，在時間上產生一個消息，無論消息流轉多少圈，最終一定會返回最左側物件，整個流程要能走通。
（3）一般來說，在一個時序圖中，除了自關聯消息外，會要求向左和向右的消息數量相等。
……
本文由 @覓雲人 原創發佈於人人都是產品經理。未經作者許可，禁止轉載。
題圖來自 Unsplash，基於CC0協定。