繼幫大家解決了如何繪製流程圖的難題後，本篇作者將幫助大家學習：如何繪製出研發喜歡看、運營看得懂的流程圖。
學習了上一篇“流程圖的大廠畫法”後，雖然能畫出來了。但經常發現畫的沒問題，研發部卻不看我們的流程圖，運營看不懂我們的流程圖。這是什麼原因呢？
其次，就是總是丟三落四，想不全面被研發懟來懟去，如何做到思考全面呢？本篇解決這個問題。
這一篇是介紹“如何製作人人喜歡的流程圖”。
具體內容如下：
- 為什麼你的流程圖別人不滿意？以一些例子來看研發和業務人員流程圖要看什麼。
- 流程圖的尺度如何把握？能夠根據給研發還是給業務人員，來畫出尺度得當的流程圖。
- 如何一步步畫出不丟三落四的流程圖？理順你的思路，做事不再丟三落四，表達清晰順暢。
下面我們就進入正題。但如果看了下文，對流程圖的UML表達方法還不瞭解，則請移步第一篇《如何製作正確的流程圖？》
一、為什麼你的流程圖別人不滿意？
首先看下面的兩張流程圖，以下流程圖如果給研發或業務人員看都是有問題的。
給業務人員的流程圖
給研發人員的流程圖
那為什麼有問題，這裡就要明白對方看流程圖的目的是什麼？
1. 業務人員：看了流程圖，好明確自己在其中做什麼，或者對工作流程提出不同意見。
2. 研發人員：看了流程圖，好進行相關的研發設計。
3. 給自己：看了流程圖便於自己梳理邏輯，不需要給任何人看。
那麼我們就以例子來看問題，相關人等對流程圖都有什麼疑問呢？
1. 業務人員對流程圖的不滿意
給業務人員看的流程圖
先回到我們上面兩個案例的第一個圖，如果這是一個給業務人員看的，對於業務人員只關心自己需要做什麼。此時把“生成送貨單” 加入就極為不合適。
此時業務人員會一臉疑惑的說：
“系統生成訂單？這個和我有什麼關係嗎？我去送貨當然要送貨單了？”。這裡發現畫了一些多餘的內容。另外補充一下，給業務人員的流程圖，研發也需要看，目的是為了理解整體業務，便於設計業務。
另外上面的流程圖邏輯上也出現了錯誤，具體請移步系列文章《第一篇：如何製作正確流程圖》的錯誤案例三。
2. 研發對流程圖的不滿意
再來看第二個圖，如果作為初學人員，畫一下給自己梳理邏輯顯然是合理的，這也就是我們說的第三類作用“流程圖畫給自己看”。但此時研發會一臉不耐煩的說：“來點乾貨，不就是兩個頁面嗎？給個原型看看？我不關心你思考的過程”。
這時倒不如直接給出1-2張頁面流程圖更直接。在簡化的頁面流程圖裡，體現主要功能和下一步的按鈕等內容。
上面兩個流程圖，一個就體現了給業務人員用的，一個就體現了給研發人員用的。那麼流程圖應該怎麼把握尺度呢？
二、流程圖的尺度該如何把握？
可以按照兩個尺度來畫流程圖，稱其為：給業務人員看的“人人交互模式” 和 給研發看的用“人機交互模式”。
下面我們分別表述：
1. 給業務人員看的“人人交互模式”
對應去掉系統後，人和人之間的交互，此時
忽略系統在其中做了什麼。以下面的流程圖為例：
你發現我們的表述的意思是“用戶支付訂單->只有用戶支付完訂單後，客服才能確認訂單->客服確認訂單後物流才能來收貨”，這裡體現了人每做一步後，另外一個人才能做另一件事情，沒有體現系統在這其中專遞信息做了什麼，如“系統創建訂單->系統顯示訂單給客服” 等中轉過程。因此我們稱其為人人交互模式的表達。這個維度上，可以讓業務人員聚焦於自己需要做什麼事情上。
從遞送發票這個環節看，我們也是這樣的邏輯“財務打印發票->打印完畢後物流才能寄送發票”，也體現了一個人人交互模式。
而這裡特殊的地方是是：
- “用戶支付完訂單”，雖然是對系統的操作是人機交互了，但沒有這一步就不會進行發貨；
- “用戶點擊確認收貨” ，沒有這一步，訂單就不算完成。因此也要在流程圖裡面體現。
2. 給研發看的用“人機交互模式”
注意人機交互級別的流程圖，主要涉及到人輸入什麼，系統會反饋什麼，但是有兩個原則需要注意。
原則一：一個頁面定義成一個操作。
看下面的例子：
假設在商品詳情頁此時展示的是一件衣服，則可以選擇衣服數量，選擇衣服顏色和大小等操作，但流程圖的作用不是表達具體功能的，所以忽略這些操作。
一個頁面只表達一個操作，下面的頁面的第一個操作就是“用戶點擊確定”，概括為“用戶選擇商品”。而後面的兩個頁面也可以概括成“用戶提交訂單”和“用戶支付訂單”。
另外不要寫畫成“用戶選擇商品->系統顯示訂單->用戶確認訂單->系統顯示支付界面->用戶支付訂單”，沒有錯但略顯囉嗦。
流程圖重點表達做了什麼事情，是不關心所有的功能。用流程圖表達功能也不是最佳方案。如果這個例子想表達的是頁面的功能，建議直接畫頁面流程圖即可，這個表達對研發更容易閱讀，或者用用例圖來表達功能合集表示功能之間的包含關係等，都是比這個更恰當的表達方式。
再如下圖，有的人說是否應該將其中的細節畫出來？如：判斷是否已經上架，判斷是否有庫存等。
結論是不應該畫。
流程圖如何表達細節？
這裡也不符合一個頁面一個動作。這裡的判斷是簡單的，還是建議直接在原型邊上寫邏輯即可這個流程圖研發是不太看的。但再次強調作為自己梳理邏輯可以做。
原則二：和後端服務器交互的定義成一個操作
具體看下面的流程圖：
和後端服務器交互的流程圖
此時當用戶進行登錄操作的時候，輸入完用戶名和密碼並點擊確定，此時APP需要詢問一下服務器：服務器大哥，請告訴我密碼是否正確？。系統會回答：密碼是正確的，或者密碼是錯誤的，或者這是一個用戶名沒有註冊過 。
這些涉及到和服務器的交互，顯然不問服務器就不知道，則可以在流程圖裡體現出來。
注意此時忽略人和APP在一個頁面內的交互。如：如輸入手機號後提示手機號格式錯誤，你會發現就是一些簡單的前端邏輯判斷，還不如在原型頁面寫備註來的簡潔和高效。
下面這兩個流程圖都屬於過度表達了。
過度表達的流程圖
過度表達的流程圖
3. 尺度的總結
給業務和研發部門呈現時：用人人交互模式，忽略系統所做的工作。給研發部門呈現時：一個頁面一個動作，可體現和後端服務器交互的動作，而忽略掉簡單的前端交互。
瞭解了流程圖的尺度後，我們還要思考如何一步步畫出流程圖。其中給業務部門的流程圖是最常用的。我們下面就以給業務部門的流程圖為例進行講解。
三、如何一步步思考畫出流程圖？
這裡有兩個基本原則：
1. 打通主流程：先粗後細，再加泳道；
2. 完善細節：先加異常，再拆流程，再合併流程。
我們分別表述：
原則一， 打通主流程：先粗後細，再加泳道
第一步：先粗後細的思路
打通主流程意思是不考慮任何異常情況，就考慮正常完成訂單的流程。在上篇文章中就是按照這個方式完善了主流程。
我們當時分了三步，分別是：
1. 完成很粗的主流程；
2. 完善送貨流程細節；
3. 完成寄送發票等細節。
這裡就體現了先粗後細的原則。
完成粗的主流程：
完善送貨流程：
完善寄送發票等流程：
第二步：加泳道的方法
線粗後細完成後，這個過程中出現一個問題，即當有財務，物流和運營等多個角色來處理，每個角色不能很清晰的看到自己的業務怎麼辦？此時可以用泳道來解決。
具體見下圖：
加入泳道後的流程圖
此時每個角色下面所對應的就是該角色所進行的動作，非常像游泳時的“泳道”。每個泳道對應的可以是：客服、物流，財務等角色。系統也可以算作一個角色，但應儘可能將其看做一個人，而不要拆分成前端和後端。
原則二，完善細節：先加異常，再拆流程，再合併流程
這樣算會否就算完成流程圖呢？還沒有，需要進一步完善。概括一下就是： 先加異常，再拆流程，再合併流程。我們一個一個來看：
第一步：加異常
上面的流程圖我們始終沒有考慮異常情況。此時可以從第一個動作一直到最後一個動作逐一梳理是否會有異常的加入。
如本例中，從前往後梳理依次是：用戶付款後要求退款怎麼辦？客服時候可以不發貨？用戶如果拒收貨物怎麼辦？用戶如果一直不點擊收貨按鈕怎麼辦？用戶如果買了以後要退貨怎麼辦？如果用戶輸錯了密碼怎麼辦？如果用戶不要發票怎麼辦？
這裡包括三類異常：不操作如何處理，反悔如何處理，錯誤操作怎麼處理？
此時對於用戶不要發票，我們如何處理？
此時對於“用戶如果一直不點擊收貨按鈕”這個做法，我們就考慮加入“系統自動確認收貨”這個流程了。
加入自動確認收貨
第二步：拆流程
列出逆流程後，通常就涉及到每個逆流程的完善。但是我們發現“用戶收貨後退貨”這個逆向流程比較複雜，包括：用戶提出退貨需求，商家同意，用戶寄送和商家退款等環節。則退貨流程就可以在其他流程圖裡面再畫，這就體現了拆流程的特點。
再如“用戶支付訂單”會存在支付成功，支付失敗，待支付等等流程也可以在其他流程圖裡面處理。
第三步：合併流程
我們看訂單寄送發票的流程包括 “財務打印發票，物流寄送發票”兩個步驟，可以抽象成寄送發票。對於財務人員當然要開發票，寫不寫不影響問題的理解。 在這一步重點在於，去掉本次流程圖不關心的內容。如果系統自動收貨不是你本次重點表達的內容，也可以去掉。
通常小白還會在流程圖加入如果用戶沒有登錄去引導登錄等判斷。在開始做練習的時候做都可以，但提交給研發則是沒有必要加入。
四、總結
本次介紹了三部分內容，分別是：
1. 流程圖給誰看：重點闡述了給業務人員，研發人員和自己看三者的差異。
2. 流程圖的尺度如何把握：重點強調了人人交互模型和人機交互模型，其中人機交互分為前端頁面交互和後端服務器端交互。
3. 如何一步步畫出流程圖：介紹了首先打通主流程：先粗後細，再加泳道；再次完善細節：先加異常，再拆流程，再合併流程。
最後做一下說明，實際上流程圖沒有絕對正確的，核心在於給誰看，大家能夠看明白主要內容即可。所以需根據每次要重點闡述的內容來畫流程圖，並最終產出一個完備的原型圖才是最終目標。
作者：擎蒼（微信公眾號：引爆產品思維），產品狗一枚，10年產品和運營經驗，曾負責上市公司的互聯網團隊組建和運營，曾在多個垂直領域頭部公司做產品狗。“擎蒼”出自蘇軾詞 “老夫聊發少年狂，左牽黃，右擎蒼。” , 是說左手舉著蒼鷹，右手牽著大黃狗。
本文由 @引爆產品思維 原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議
閱讀更多 人人都是產品經理 的文章
