起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識制作人人喜歡的流程圖，三步教會你繪制大廠流程圖（第二篇）
編輯導語：在產品設計流程中，流程圖的繪制有利于展示產品邏輯，而清晰的流程圖繪制更是有利于團隊與合作伙伴理解運行流程。在上篇文章里，作者闡述了繪制流程圖的要點、意義與常見問題，本文作者則繼續介紹如何繪制一份合理有效的流程圖，讓我們一起來看一下。
繼幫大家解決了如何繪制流程圖的難題后，本篇作者將幫助大家學習：如何繪制出研發喜歡看、運營看得懂的流程圖。
學習了上一篇“流程圖的大廠畫法”后，雖然能畫出來了。但經常發現畫的沒問題，研發部卻不看我們的流程圖，運營看不懂我們的流程圖。這是什么原因呢？
其次，就是總是丟三落四，想不全面被研發懟來懟去，如何做到思考全面呢？本篇解決這個問題。
這一篇是介紹“如何制作人人喜歡的流程圖”。
具體內容如下：
- 為什么你的流程圖別人不滿意？以一些例子來看研發和業務人員流程圖要看什么。
- 流程圖的尺度如何把握？能夠根據給研發還是給業務人員，來畫出尺度得當的流程圖。
- 如何一步步畫出不丟三落四的流程圖？理順你的思路，做事不再丟三落四，表達清晰順暢。
下面我們就進入正題。但如果看了下文，對流程圖的UML表達方法還不了解，則請移步第一篇《如何制作正確的流程圖？》
一、為什么你的流程圖別人不滿意？
首先看下面的兩張流程圖，以下流程圖如果給研發或業務人員看都是有問題的。
給業務人員的流程圖
給研發人員的流程圖
那為什么有問題，這里就要明白對方看流程圖的目的是什么？
- 業務人員：看了流程圖，好明確自己在其中做什么，或者對工作流程提出不同意見。
- 研發人員：看了流程圖，好進行相關的研發設計。
- 給自己：看了流程圖便于自己梳理邏輯，不需要給任何人看。
那么我們就以例子來看問題，相關人等對流程圖都有什么疑問呢？
1.? 業務人員對流程圖的不滿意
給業務人員看的流程圖
先回到我們上面兩個案例的第一個圖，如果這是一個給業務人員看的，對于業務人員只關心自己需要做什么。此時把“生成送貨單” 加入就極為不合適。
此時業務人員會一臉疑惑的說：“系統生成訂單？這個和我有什么關系嗎？我去送貨當然要送貨單了？”。這里發現畫了一些多余的內容。
另外補充一下，給業務人員的流程圖，研發也需要看，目的是為了理解整體業務，便于設計業務。
另外上面的流程圖邏輯上也出現了錯誤，具體請移步系列文章《第一篇：如何制作正確流程圖》的錯誤案例三。
2. 研發對流程圖的不滿意
再來看第二個圖，如果作為初學人員，畫一下給自己梳理邏輯顯然是合理的，這也就是我們說的第三類作用“流程圖畫給自己看”。但此時研發會一臉不耐煩的說：“來點干貨，不就是兩個頁面嗎？給個原型看看？我不關心你思考的過程”。
這時倒不如直接給出1-2張頁面流程圖更直接。在簡化的頁面流程圖里，體現主要功能和下一步的按鈕等內容。
上面兩個流程圖，一個就體現了給業務人員用的，一個就體現了給研發人員用的。那么流程圖應該怎么把握尺度呢？
二、流程圖的尺度該如何把握？
可以按照兩個尺度來畫流程圖，稱其為：給業務人員看的“人人交互模式” 和 給研發看的用“人機交互模式”。
下面我們分別表述。
1. 給業務人員看的“人人交互模式”
對應去掉系統后，人和人之間的交互，此時忽略系統在其中做了什么。以下面的流程圖為例：
你發現我們的表述的意思是“用戶支付訂單→只有用戶支付完訂單后，客服才能確認訂單→客服確認訂單后物流才能來收貨”。
這里體現了人每做一步后，另外一個人才能做另一件事情，沒有體現系統在這其中專遞信息做了什么，如“系統創建訂單→系統顯示訂單給客服” 等中轉過程。因此我們稱其為人人交互模式的表達。
這個維度上，可以讓業務人員聚焦于自己需要做什么事情上。
從遞送發票這個環節看，我們也是這樣的邏輯“財務打印發票→打印完畢后物流才能寄送發票”，也體現了一個人人交互模式。
而這里特殊的地方是：
- “用戶支付完訂單”，雖然是對系統的操作是人機交互了，但沒有這一步就不會進行發貨；
- “用戶點擊確認收貨”，沒有這一步，訂單就不算完成。因此也要在流程圖里面體現。
2. 給研發看的用“人機交互模式”
注意人機交互級別的流程圖，主要涉及到人輸入什么，系統會反饋什么，但是有兩個原則需要注意。
1）原則一：一個頁面定義成一個操作
看下面的例子：
假設在商品詳情頁此時展示的是一件衣服，則可以選擇衣服數量，選擇衣服顏色和大小等操作，但流程圖的作用不是表達具體功能的，所以忽略這些操作。
一個頁面只表達一個操作，下面的頁面的第一個操作就是“用戶點擊確定”，概括為“用戶選擇商品”。而后面的兩個頁面也可以概括成“用戶提交訂單”和“用戶支付訂單”。
另外不要寫畫成“用戶選擇商品→系統顯示訂單→用戶確認訂單→系統顯示支付界面→用戶支付訂單”，沒有錯但略顯啰嗦。
流程圖重點表達做了什么事情，是不關心所有的功能。用流程圖表達功能也不是最佳方案。
如果這個例子想表達的是頁面的功能，建議直接畫頁面流程圖即可，這個表達對研發更容易閱讀。或者用用例圖來表達功能合集表示功能之間的包含關系等，都是比這個更恰當的表達方式。
再如下圖，有的人說是否應該將其中的細節畫出來？如：判斷是否已經上架，判斷是否有庫存等。
結論是不應該畫。
流程圖如何表達細節？
這里也不符合一個頁面一個動作。這里的判斷是簡單的，還是建議直接在原型邊上寫邏輯即可這個流程圖研發是不太看的。但再次強調作為自己梳理邏輯可以做。
2）原則二：和后端服務器交互的定義成一個操作
具體看下面的流程圖：
和后端服務器交互的流程圖
此時當用戶進行登錄操作的時候，輸入完用戶名和密碼并點擊確定，此時APP需要詢問一下服務器：服務器大哥，請告訴我密碼是否正確？
系統會回答：密碼是正確的，或者密碼是錯誤的，或者這是一個用戶名沒有注冊過。
這些涉及到和服務器的交互，顯然不問服務器就不知道，則可以在流程圖里體現出來。
注意此時忽略人和APP在一個頁面內的交互。如：如輸入手機號后提示手機號格式錯誤，你會發現就是一些簡單的前端邏輯判斷，還不如在原型頁面寫備注來的簡潔和高效。
下面這兩個流程圖都屬于過度表達了。
過度表達的流程圖
過度表達的流程圖
3.? 尺度的總結
給業務和研發部門呈現時：用人人交互模式，忽略系統所做的工作。給研發部門呈現時：一個頁面一個動作，可體現和后端服務器交互的動作，而忽略掉簡單的前端交互。
了解了流程圖的尺度后，我們還要思考如何一步步畫出流程圖。其中給業務部門的流程圖是最常用的。我們下面就以給業務部門的流程圖為例進行講解。
三、如何一步步思考畫出流程圖？
這里有兩個基本原則：
- 打通主流程：先粗后細，再加泳道；
- 完善細節：先加異常，再拆流程，再合并流程。
我們分別表述。
1. 打通主流程：先粗后細，再加泳道
1）第一步：先粗后細的思路
打通主流程意思是不考慮任何異常情況，就考慮正常完成訂單的流程。在上篇文章中就是按照這個方式完善了主流程。
我們當時分了三步，分別是：
- 完成很粗的主流程；
- 完善送貨流程細節；
- 完成寄送發票等細節。
這里就體現了先粗后細的原則。
完成粗的主流程：
完善送貨流程：
完善寄送發票等流程：
2）第二步：加泳道的方法
線粗后細完成后，這個過程中出現一個問題，即當有財務、物流和運營等多個角色來處理，每個角色不能很清晰地看到自己的業務怎么辦？此時可以用泳道來解決。
具體見下圖：
加入泳道后的流程圖
此時每個角色下面所對應的就是該角色所進行的動作，非常像游泳時的“泳道”。每個泳道對應的可以是：客服、物流、財務等角色。系統也可以算作一個角色，但應盡可能將其看做一個人，而不要拆分成前端和后端。
2. 完善細節：先加異常，再拆流程，再合并流程
這樣算會否就算完成流程圖呢？還沒有，需要進一步完善。概括一下就是： 先加異常，再拆流程，再合并流程。我們一個一個來看。
1）第一步：加異常
上面的流程圖我們始終沒有考慮異常情況。此時可以從第一個動作一直到最后一個動作逐一梳理是否會有異常的加入。
如本例中，從前往后梳理依次是：用戶付款后要求退款怎么辦？客服時候可以不發貨？用戶如果拒收貨物怎么辦？用戶如果一直不點擊收貨按鈕怎么辦？用戶如果買了以后要退貨怎么辦？如果用戶輸錯了密碼怎么辦？如果用戶不要發票怎么辦？
這里包括三類異常：不操作如何處理、反悔如何處理、錯誤操作怎么處理？
此時對于用戶不要發票，我們如何處理？
此時對于“用戶如果一直不點擊收貨按鈕”這個做法，我們就考慮加入“系統自動確認收貨”這個流程了。
加入自動確認收貨
2）第二步：拆流程
列出逆流程后，通常就涉及到每個逆流程的完善。但是我們發現“用戶收貨后退貨”這個逆向流程比較復雜，包括：用戶提出退貨需求、商家同意、用戶寄送和商家退款等環節。則退貨流程就可以在其他流程圖里面再畫，這就體現了拆流程的特點。
再如“用戶支付訂單”會存在支付成功、支付失敗、待支付等等流程也可以在其他流程圖里面處理。
3）第三步：合并流程
我們看訂單寄送發票的流程包括 “財務打印發票，物流寄送發票”兩個步驟，可以抽象成寄送發票。
對于財務人員當然要開發票，寫不寫不影響問題的理解。在這一步重點在于，去掉本次流程圖不關心的內容。如果系統自動收貨不是你本次重點表達的內容，也可以去掉。
通常小白還會在流程圖加入如果用戶沒有登錄去引導登錄等判斷。在開始做練習的時候做都可以，但提交給研發則是沒有必要加入。
四、總結
本次介紹了三部分內容，分別是：
- 流程圖給誰看：重點闡述了給業務人員，研發人員和自己看三者的差異。
- 流程圖的尺度如何把握：重點強調了人人交互模型和人機交互模型，其中人機交互分為前端頁面交互和后端服務器端交互。
- 如何一步步畫出流程圖：介紹了首先打通主流程：先粗后細，再加泳道；再次完善細節：先加異常，再拆流程，再合并流程。
最后做一下說明，實際上流程圖沒有絕對正確的，核心在于給誰看，大家能夠看明白主要內容即可。所以需根據每次要重點闡述的內容來畫流程圖，并最終產出一個完備的原型圖才是最終目標。
作者：擎蒼，《“圖解”產品：產品經理業務設計與UML建?！纷髡?，公眾號：圖解產品設計
本文由 @擎蒼 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
您好，最后一步步畫流程圖那部分，可否添加上給研發看的流程圖呢？貌似講的只是業務流程？
產品經理用的流程圖是借鑒研發的UML來的，其實目前也沒有一個特別嚴格的標準。
流程圖主要關注你的對象和目的
掌握基本符號和原理靈活運用。
能不能把你認為正確的也給歸納一下，你就說錯的
代理解綁
總結一下：
用UML-活動圖來表達面向對象(活動圖）、面向過程（原傳統流程圖)的思維。
針對業務層面，即面向過程，重點描述人與人之間的交互，事情與事情的、過程與過程之間的流轉，而忽略系統的行為，但對于必要的系統行為，是允許存在的；
針對系統層面，即面向對象，重點關注人與系統之間的操作，當以面向對象的思維去畫圖時，顆粒度盡量抽象到頁面層級，即一個頁面表示一個操作，如果涉及到多角色，則應用泳道圖闡述，但系統層面的前、后端應盡量看作是一個角色；
不管是泳道圖（多角色），還是單角色，在這個過程中如果涉及到前后端交互&基本邏輯判斷，應直接在交互說明上表達，這樣能避免“過度表達”的情況（好處是圖簡潔，缺點顯而易見，這里視“看圖人”的要求）。
流程圖和活動圖目的完全相同，和網上主流的流程圖比起來，活動圖主要是多了并行等表達。這一點UML的創始人也是這么說的，簡單地說兩者就是一回事。
大家可關注微號：[匠心做好產品經理]，有更多干貨，如狀態圖等，還有簡歷模板可領取。
另外：1）活動圖和對象關系不大。2）流程圖中不要管系統內的流程，原因是產品經理是梳理業務，而不是梳理系統的實現，這是研發做的。常見的問題是把系統分成前后端，這就沒有必要。在一些情況下如果需要，可以加。但應在第一個流程圖做完的基礎上加，從外到內畫流程圖是個好習慣，這恰恰是用例圖的思想，也可以用在流程圖中。
哈哈，補充一下，作者說的沒錯。
我是研發出身，補充下我的見解，對應文章的內容：
1. 針對業務層面，即面向過程（人人交互），對應網上講的業務流程圖；
2. 針對系統層面，即面向對象（人機交互），對應的是網上講的功能流程圖/任務流程圖；
就如作者所言，名字怎么叫不重要，但重要的是思維能一致，大家懂這個講的是啥。
微信公主號咋個沒找到列～
工號修改，全網改為【圖解產品設計】
工號已改為【圖解產品設計】
現在正在寫更為全面的：流程圖、狀態圖、類圖和E-R圖，也包括功能和非功能的拆解等。有這方面內容需求和建議的，可向我咨詢。
催更催更～
看書“圖解產品”，已全網發售
人機交互的話，一些異常場景需要表現嗎，比如用戶拒絕收貨，不支付
要，畫流程圖非常有利于梳理異常情況
非常棒??
你好！請問加異常中加入自動確認收貨部分，系統確認收貨、用戶確認收貨為并行，但結束應該是只要其一做了確認收貨，就算結束。圖中的是并行開始合并結束，這樣并行和匯合沒有成對出現，有什么問題沒？
沒問題，并行匯合成對出現的情況就是點餐，菜同時做，但必須菜都上來了，你才結賬。 并行匯合不成對出現的情況就是打仗，幾路同時打，誰先打下來就算游戲結束。
請問原則二的第一步加異常中，用戶選擇不要發票，流程圖這樣畫最后用到匯合也就是說就算用戶不要發票還是得收到發票才能確認收貨嗎？
同樣的疑問，希望大佬看到后能解惑。
也能畫，就是麻煩。此時，不要發票則直接畫根線跳到送貨，避開并行（橫線），但這樣做就很麻煩，可文字說明。書“圖解產品”已經改寫三篇文章。
針對每個項目都要畫三份流程圖么？我都是畫一份給自己整理思路，然后把原型做好點用文字說明比較方便。
簡單流程不需要畫，復雜流程需要畫并提供給對方，便于對方理解其工作
太棒了
各抒己見。
怎么講？
右擎蒼 你翻譯右手牽著大黃狗，可見你給自己的定位
已改，弄錯了
好文
接地氣，學到東西
剛學交互，看了您的流程圖和其他文章的流程圖有點不同，希望幫忙解答一下：
1.其他文章中的流程圖橢圓表示的是起點和終點，您的文章中起點為實心圓，終點可以多個或一個；
2.活動的畫法是圓角矩形，看您的例子基本都是活動+判斷就完成了整個流程，沒有涉及到輸入輸出、過程等元素。而在維基百科定義的流程圖基本構成元素里沒找到這個“活動”；
請問他們不是一個東西嗎？ ? 希望大佬能快點產出第三篇
簡單地說就如語言不同一樣。表達同樣內容(流程圖)但語言不同。
同時網上的流程圖你找不到權威標準，即事實上怎么說都可以，也就談不到對錯。而活動圖有標準，并且有一系列書籍講。
請問有推薦的書籍嗎 ??
沒有，書和培訓都不講這些。
如果要看，有大象UML，但是比較難懂，因為是面向研發講的
正在弄一本，可以關注我，獲得內容
清晰、易懂、受益匪淺