在做產品設計時，會碰到非常多的業務流程，當我們需要跟開發解釋一個相對復雜的流程時，一個清晰的流程圖，便非常重要了。如何寫出一個清晰的流程圖呢？本文作者對此進行了分析，一起來看一下吧。

我們做產品設計的時候，會碰到非常多的業務流程，有簡單的，有復雜的，有單作業的，也有多作業的，當我們碰到需要跟開發解釋一個相對復雜的流程時，無論多么詳盡的表述，都遠不如一個清晰的流程圖來得有用。

如果一個業務流程你認為它復雜到無法用流程圖來表達，那多半你也無法用文字來表達。

有些文科出身的產品經理，對文字的敏感度遠超圖形，所以他們能用非常詳細的文字去描述一個流程的各個細節，但是如果你讓他們畫一個流程圖出來的時候，卻沒人能看得懂，如果你剛好是這樣的人，希望這篇文章對你有幫助。

一、認識流程圖

在繪制流程圖之前，需要先認識流程圖上的不同圖形代表了什么意思，以便你在繪制流程圖時可以正確使用它們。

一般用【橢圓形】表示流程的開始或結束節點，用【矩形】表示流程的常規節點，用【菱形】表示流程的判斷節點，節點與節點之間，通過【箭頭】進行連接。繪制的時候可以考慮給不同的圖形加上不同的顏色，這樣辨識度更高。

這樣的約定使流程圖的繪制者和閱讀者更容易達成共識，也使繪制的流程圖更具易讀性。

二、單作業流程圖

這是最簡單的一種流程圖形式，它只是系統中、甚至只是某個系統功能模塊中的流程；它只描述一個用戶的動作，或者只是描述一個功能模塊的運作邏輯。

比如我們可以來繪制一個最簡單的用戶登錄操作流程圖：

上圖是從用戶操作的角度，描述用戶完成一個業務操作的流程，這種流程圖，稱為【業務流程圖】。

我們再來繪制一個登錄校驗的流程圖：

上圖是從系統角度，描述一個功能的處理邏輯，這種流程圖，稱為【系統流程圖】或【功能流程圖】。

我們甚至可以對輸入手機號這個操作單獨繪制它的校驗流程圖：

通過以上幾個簡單的流程圖，我們來總結一下一個合格的流程圖應該怎么畫：

1、用正確的圖形表達對應的節點，節點文字簡潔清晰描述執行的動作，必要時可增加注釋。比如上圖校驗手機號對前3位數字的判斷，由于條件比較多，如果將所有可能的前3位數字全部寫出來，流程圖就太過臃腫，像這種情況，只需要簡單舉個例子或加個注釋說明，讓開發知道這里是要進行什么判斷即可，至于詳細的判斷規則，應該詳細記錄在需求文檔中。

2、同一個判斷節點，判斷結果控制在3個以內，2個最佳，如果判斷條件比較多，盡可能分多個判斷節點，每個節點只處理一個判斷條件。如果一個判斷條件有2個結果，那么兩個判斷條件放在一起就可能大于4個結果。

3、線條盡可能少交叉和重疊。

4、盡可能合并相同作用的流程節點。這樣可以使流程圖更加簡潔，但要注意，如果兩個節點的作用不相同，一定不要使用相同或相似的節點文案。

5、按主線流程從上到下繪制，支線流程從左往右延伸。人的閱讀習慣是從上到下，從左到右。

6、如果一個流程過于復雜，可以將其中可獨立的子流程單獨繪制成流程圖。比如上述例子中，將登錄的主流程和登錄中輸入手機號校驗的子流程分別繪制兩個單獨的流程圖，這樣更便于開發理解，如果混在一個流程圖中，會讓人覺得看起來要處理的邏輯太多，主流程和子流程交叉進行，看圖的人會覺得未免過于復雜難懂。

根據上述結論，我們來看一個極端的反面例子：

從上面的例子中，我們可以知道這個流程圖有以下問題：

1、全部的節點都用錯了圖形。

2、一個判斷節點同時進行多個條件判斷，判斷結果太多，流程混亂。

3、流程線條重疊，影響閱讀。

4、關于是否11位數字是一個單獨的判斷條件，只需要輸出一個錯誤提示結果即可，太多提示顯得流程過分冗余。

5、流程“左右開弓”，閱讀時容易感到無所適從。

三、多作業流程圖

多作業流程圖就要復雜得多，它可能涉及多個角色，也可能涉及多個系統，甚至可能同時涉及多個角色和多個系統，接下來將逐一舉例說明。

在這之前，我們需要先認識一個新的圖形——【泳道圖】。

顧名思義，泳道圖有多個泳道，每條泳道可以代表一個角色或一個系統，這樣我們就可以在不同的泳道中表達多角色或多系統之間的協作流程。

舉一個多角色協作的例子，假設 OA 辦公系統中請假的主要流程是這樣的：員工請假→上級主管審批→人事經理審批→總經理審批。全部審批完成后請假才能生效，如果有其中一人拒絕，就不再將流程提交給下一個審批人。我們來繪制一下這個流程圖：

每一條縱向的泳道代表一個角色，按照審批順序從左向右排列，然后把每個角色的流程畫在對應的泳道內。

多系統的流程也是相同的畫法，如果是多角色多系統同時存在呢？

還是上面的例子，我們假設考勤是個單獨的小程序，員工通過考勤小程序請假，審批者通過 OA 系統審批，這個時候就涉及多系統多角色的協作。我們上面畫的是縱向泳道圖，這個時候我們只要引入橫向泳道圖來表示多個系統就可以了：

1. 流程優化

一個流程圖好不好，不只是看它是否畫得清晰易懂，也不只是看它畫得是否美觀簡潔，還要看它表達的邏輯是否合理以及是否最優。

上圖是大多數平臺注冊時需要填寫的字段，首先我們針對上圖這些注冊條件，繪制出一個注冊流程中校驗手機號是否已注冊的流程圖：

這個流程圖畫的沒有問題，在邏輯上也是成立的，但它是否就是合理的或最優的呢？我們來分析一下。

如果用戶按主線流程最終注冊成功，這個流程是沒有問題的，但如果用戶的手機號之前已經注冊過，對用戶而言，這個時候用戶已經輸入了一堆的信息，你才告訴用戶注冊不了，用戶會覺得反感，甚至惱怒，對平臺而言，發送驗證碼的短信費用，本是一筆可以避免的支出。

因此，我們可以對這個流程進行優化，首先在用戶輸入手機號之后，系統先查詢手機號是否已注冊，如果已注冊，這時就可以馬上提醒用戶：

如果用戶不理會提示，繼續往下填寫注冊信息，在發送驗證碼的時候，如果手機號已注冊，此時發送驗證碼給用戶是沒有意義的，所以在發送驗證碼時，需再次進行手機號是否已經注冊的校驗：

通過這樣的流程優化，可以達到降本增效的目的。

降本：降低成本。優化后的流程，當用戶看到手機號已注冊后，就不會繼續往下輸入，降低了用戶輸入后續信息的時間成本；手機號已注冊不發送驗證碼，減少短信費用，降低平臺的經濟成本。

增效：增加效率。優化后的流程，當用戶輸入手機號之后，如果手機號已注冊，用戶就可以馬上轉去登錄，提前中斷沒有必要繼續往下進行的注冊流程，縮短整個操作的時間，提升操作效率。

一個流程如果太長，我們在規劃流程的時候，需要注意跳出流程的節點。

比如上述注冊流程圖，我們可以像下方這樣，發現手機號不是11位數字之后，仍然往下走，等所有判斷條件執行完之后，將所有的錯誤信息一次性報給用戶：

這種方式對用戶來說體驗是比較好的，可以一次性知道所有錯誤并修正，但有時候我們的系統流程很長，每一步都需要做大量的判斷，耗費大量的時間，那我們會采用另外一種方式，就是提前中斷，跳出流程，如下，當判斷到用戶的手機號已經不是11位數字，就不再往下判斷，直接報出錯誤提示：

優化后讓流程變得更加簡單，但也意味著繪制的流程圖會更加復雜，因為要考慮更多的流程場景，因此，優化流程才是真正考驗產品經理功底的工作。

我們再來看看上述的考勤流程可以怎么進行優化。

我們仔細分析一下，就會發現考勤的流程還涉及其他的場景。

第一種場景：提交請假申請的人本身就是部門負責人，在系統中沒有直屬的上級主管。這種場景下，如果一個人本身就是上級主管，那么提交之后，上級主管這一級就默認審批通過，直接提交給人事經理審批：

第二種場景：假設人事經理的直屬上級是總經理，人事經理請假的時候，流程怎么走？這種場景流程其實沒有變，只是出現了特殊的情況，就是請假人剛好是審批人，同時上級是直接審批人，又是最終審批人，這種情況下，我們還是按流程來走，只是遇到相同審批人的時候，默認審批通過即可：

實際上流程一個都沒少，只是因為角色重疊，所以兩個角色完成了4個角色的流程。雖然流程簡化，審批自動通過，但在設計系統的時候，即使是自動通過的審批節點，在系統中也需要進行記錄。

最后我想說，在做產品設計時，不要濫用流程圖，不要什么邏輯一上來就畫流程圖，有些邏輯很簡單，一兩句話就能說明白，就沒必要畫流程圖，流程圖看多了，也容易疲勞。

*本文示例流程圖均進行一定程度簡化，僅為說明原理，不代表實際業務，請注意分辨。