文章大綱
一、 爲什麼要畫流程圖
二、流程圖基礎知識
三、 流程圖介紹與實戰
四、參考文章
一、 爲什麼要畫流程圖
流程圖是對過程、算法、流程的一種圖像表示，在技術設計、交流及商業簡報等領域有廣泛的應用。通常用一些圖框來表示各種類型的操作，在框內寫出各個步驟，然後用帶箭頭的線把它們連接起來，以表示執行的先後順序。用圖形表示算法，直觀形象，易於理解。有時候也被稱之爲輸入-輸出圖。顧名思義，就是用來直觀地描述一個工作過程的具體步驟，對於產品而言，使用流程圖可以實現高效率地與領導、客戶、開發人員、測試人員進行溝通。
二、流程圖基礎
1. 流程圖工具的選擇
專業的繪圖軟件
Microsoft Visio，最優秀的繪圖軟件，功能強大和易用性完美結合，還有數據庫、機械等流程圖，與Word、PPT等Office文檔兼容性很好，插入到這些文檔中後，能夠直接點擊打開編輯/保存；（類似軟件：Edraw、Dia、Smarcha）
SmartDraw，最流行的商業繪圖軟件，包含數百個示例，數千個符號和外形供你使用，充分滿足製作各類圖表的需要；
DiagramDesigner，是一款小巧免費的流程圖繪製軟件，速度飛快，功能豐富，支持中文，有模板庫，是一個開源軟件；
MsvDraw，是一款新的流程圖繪製軟件，新穎小巧，功能強大，可以方便繪製各種專業的流程圖;
其它：Concept Draw PRO、Embedded Vector Editor、PERT Chart EXPERT。
在線的繪圖軟件/網站
Tersus，是一款基於AJAX的在線繪圖工具，支持手繪以及任意圖表的製作；
Gliffy，支持中文，操作簡單，支持協同編輯，可直接導入Macromedia Freehand、Microsoft Visio，等進行編輯；（類似軟件：Draw Anywhere）
Lovelycharts，功能強大，支持拖拽等；
其它，Flowchart、Best4C、ProcessOn。
2. 流程圖規範
共識
雖然流程圖的類別沒有嚴格的分類標準，但對於其圖形表達已經有一套基本的共識。在介紹具體的流程圖前，我們先對常用的圖形標準達成共識：
流程圖尺度把握
（1）給業務人員看的“人人交互模式
對應去掉系統後，人和人之間的交互，此時忽略系統在其中做了什麼。以下面的流程圖爲例：
你發現我們的表述的意思是“用戶支付訂單->只有用戶支付完訂單後，客服才能確認訂單->客服確認訂單後物流才能來收貨”，這裏體現了人每做一步後，另外一個人才能做另一件事情，沒有體現系統在這其中專遞信息做了什麼，如“系統創建訂單->系統顯示訂單給客服” 等中轉過程。因此我們稱其爲人人交互模式的表達。這個維度上，可以讓業務人員聚焦於自己需要做什麼事情上。
從遞送發票這個環節看，我們也是這樣的邏輯“財務打印發票->打印完畢後物流才能寄送發票”，也體現了一個人人交互模式。
而這裏特殊的地方是是：
“用戶支付完訂單”，雖然是對系統的操作是人機交互了，但沒有這一步就不會進行發貨；
“用戶點擊確認收貨” ，沒有這一步，訂單就不算完成。因此也要在流程圖裏面體現。
（2）給研發看的用“人機交互模式”
注意人機交互級別的流程圖，主要涉及到人輸入什麼，系統會反饋什麼，但是有兩個原則需要注意。
原則一：一個頁面定義成一個操作，看下面的例子：
假設在商品詳情頁此時展示的是一件衣服，則可以選擇衣服數量，選擇衣服顏色和大小等操作，但流程圖的作用不是表達具體功能的，所以忽略這些操作。
一個頁面只表達一個操作，下面的頁面的第一個操作就是“用戶點擊確定”，概括爲“用戶選擇商品”。而後面的兩個頁面也可以概括成“用戶提交訂單”和“用戶支付訂單”。
另外不要寫畫成“用戶選擇商品->系統顯示訂單->用戶確認訂單->系統顯示支付界面->用戶支付訂單”，沒有錯但略顯囉嗦。
流程圖重點表達做了什麼事情，是不關心所有的功能。用流程圖表達功能也不是最佳方案。如果這個例子想表達的是頁面的功能，建議直接畫頁面流程圖即可，這個表達對研發更容易閱讀，或者用用例圖來表達功能合集表示功能之間的包含關係等，都是比這個更恰當的表達方式。
再如下圖，有的人說是否應該將其中的細節畫出來？如：判斷是否已經上架，判斷是否有庫存等，結論是不應該畫。
原則二：和後端服務器交互的定義成一個操作
具體看下面的流程圖：
此時當用戶進行登錄操作的時候，輸入完用戶名和密碼並點擊確定，此時APP需要詢問一下服務器：服務器大哥，請告訴我密碼是否正確？。系統會回答：密碼是正確的，或者密碼是錯誤的，或者這是一個用戶名沒有註冊過。
這些涉及到和服務器的交互，顯然不問服務器就不知道，則可以在流程圖裏體現出來。
注意此時忽略人和APP在一個頁面內的交互。如：如輸入手機號後提示手機號格式錯誤，你會發現就是一些簡單的前端邏輯判斷，還不如在原型頁面寫備註來的簡潔和高效。
下面這兩個流程圖都屬於過度表達了。
3. 如何一步步思考畫出流程圖？
這裏有兩個基本原則：
- 打通主流程：先粗後細，再加泳道；
- 完善細節：先加異常，再拆流程，再合併流程。
原則一， 打通主流程：先粗後細，再加泳道
第一步：先粗後細的思路
打通主流程意思是不考慮任何異常情況，就考慮正常完成訂單的流程。在上篇文章中就是按照這個方式完善了主流程。
我們當時分了三步，分別是：
- 完成很粗的主流程；
- 完善送貨流程細節；
- 完成寄送發票等細節。
這裏就體現了先粗後細的原則。
完成粗的主流程：
完善寄送發票等流程：
第二步：加泳道的方法
線粗後細完成後，這個過程中出現一個問題，即當有財務，物流和運營等多個角色來處理，每個角色不能很清晰的看到自己的業務怎麼辦？此時可以用泳道來解決，具體見下圖：
此時每個角色下面所對應的就是該角色所進行的動作，非常像游泳時的“泳道”。每個泳道對應的可以是：客服、物流，財務等角色。系統也可以算作一個角色，但應儘可能將其看做一個人，而不要拆分成前端和後端。
原則二，完善細節：先加異常，再拆流程，再合併流程
這樣算會否就算完成流程圖呢？還沒有，需要進一步完善。概括一下就是： 先加異常，再拆流程，再合併流程。我們一個一個來看：
第一步：加異常
上面的流程圖我們始終沒有考慮異常情況。此時可以從第一個動作一直到最後一個動作逐一梳理是否會有異常的加入。
如本例中，從前往後梳理依次是：用戶付款後要求退款怎麼辦？客服時候可以不發貨？用戶如果拒收貨物怎麼辦？用戶如果一直不點擊收貨按鈕怎麼辦？用戶如果買了以後要退貨怎麼辦？如果用戶輸錯了密碼怎麼辦？如果用戶不要發票怎麼辦？
這裏包括三類異常：不操作如何處理，反悔如何處理，錯誤操作怎麼處理？
此時對於用戶不要發票，我們如何處理？
此時對於“用戶如果一直不點擊收貨按鈕”這個做法，我們就考慮加入“系統自動確認收貨”這個流程了。
第二步：拆流程
列出逆流程後，通常就涉及到每個逆流程的完善。但是我們發現“用戶收貨後退貨”這個逆向流程比較複雜，包括：用戶提出退貨需求，商家同意，用戶寄送和商家退款等環節。則退貨流程就可以在其他流程圖裏面再畫，這就體現了拆流程的特點。
再如“用戶支付訂單”會存在支付成功，支付失敗，待支付等等流程也可以在其他流程圖裏面處理。
第三步：合併流程
我們看訂單寄送發票的流程包括 “財務打印發票，物流寄送發票”兩個步驟，可以抽象成寄送發票。對於財務人員當然要開發票，寫不寫不影響問題的理解。 在這一步重點在於，去掉本次流程圖不關心的內容。如果系統自動收貨不是你本次重點表達的內容，也可以去掉。
三、 流程圖介紹與實戰
流程圖是產品經理傳達需求的常用做法，PM經常會用到的流程圖包括：產品功能流程圖、業務流程圖、頁面流程圖等。
1. 產品業務流程圖（繪製人：產品經理）
定義
產品業務流程圖就是通過圖形化的表達形式，闡述產品在業務層面控制的圖表。產品業務流程圖通常作爲產品設計初期階段的工具使用，通過圖形化，能夠更清晰、直觀地傳達產品在業務層面的控制（如業務動作、方向、邏輯等信息）。
作用
業務流程圖通常用於介紹產品業務，如產品經理需要向老闆介紹產品業務時，用流程圖輔助講解的效果，相較於純語言或文字表達要好得多。
繪製業務流程圖的過程能夠幫助PM根據產品定位對產品業務進行設計、分析與優化。
實例
注：這裏我們以ofo小黃車爲例，粗略地繪製其業務流程圖、功能流程圖、頁面流程圖，希望能夠幫助理解
2. 產品功能流程圖（繪製人:產品經理）
定義
產品功能流程圖就是通過圖形化的表達形式，闡述產品在功能層面控制的圖表。產品功能流程圖通常作爲產品設計中期階段的工具使用，通過圖形化，能夠更清晰、直觀地傳達產品在功能層面的控制（如功能動作、方向、邏輯等信息）。
作用
功能流程圖通常用於介紹產品功能模塊的相互關係或某個功能模塊的具體組成，如產品經理需要向開發人員介紹某個新增功能模塊時，可以在原型圖宣講之前使用功能流程圖讓其對功能的輪廓和走向瞭然於胸。
繪製功能流程圖的過程能夠幫助PM確定產品的功能範圍同時避免不合理的功能使用邏輯。
實例
3. 產品頁面流程圖（繪製人:交互設計師、產品經理）
定義
產品頁面流程圖就是通過圖形化的表達形式，闡述產品在頁面層面控制的圖表。產品頁面流程圖通常作爲產品設計後期階段的工具使用，通過圖形化，能夠更清晰、直觀地傳達產品在頁面層面的控制（如頁面功能和信息、方向、邏輯等信息）。
作用
頁面流程圖通常用於介紹產品頁面元素及頁面之間的跳轉關係。
產品頁面流程圖一般由專門的交互設計師進行設計，其繪製過程能夠幫助交互設計師確定產品頁面之間合理自然的跳轉順序以及頁面本身的功能及信息構成。
實例
