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